タグ付けされた質問 「c++」

最近、関数へのオプションのパラメーターの最適な順序を見つけようとしているときに、このブログの投稿と、C ++のPythonのような機能のヘッダーを提供するGitHubリポジトリを偶然見つけましたkwargs。結局使ったわけではないのですが、強く型付けされた言語でこれがいいのか疑問に思っています。しばらくPythonで作業していkwargsて、プロジェクト内の-のような機能の概念が非常に魅力的であることがわかります。そのオブジェクト/関数の多くには多数のオプションパラメーター（残念ながら回避できない）があり、コンストラクターの長いリストが生成されるためです。 1つまたは2つのパラメータが異なり、はるかに簡潔/ DRY風にすることができます。 このようなことを他の人が経験したとしたら、どうですか。避けるべきですか？ガイドラインはありますか？潜在的な問題/落とし穴は何ですか？

8 c++  python 

Javaガベージコレクションは、ヒープ上のデッドオブジェクトを処理しますが、時々世界を凍結します。C ++ではdelete、作成したオブジェクトをそのライフサイクルの最後に破棄するために呼び出す必要があります。 これdeleteは、非凍結環境に支払うには非常に低価格のようです。関連deleteするすべてのキーワードを配置することは、機械的な作業です。新しいブランチが特定のオブジェクトを使用しなくなったら、コードを移動して削除を実行するスクリプトを作成できます。 では、ガベージコレクションのJavaビルドインとC ++ diyモデルの賛否両論は何ですか。 C ++対Javaスレッドを開始したくありません。私の質問は違います。 この全体的なGCのことは、「単純に、作成したオブジェクトを削除することを忘れないでください。専用のGCは必要ありません。それとも、「C ++でオブジェクトを破棄するのは本当にトリッキーです。私の時間の20％をそれに費やしますが、それでもメモリリークは一般的な場所です」

8 java  c++  garbage-collection 

C ++で物理シミュレーションプログラムを書いています。私はOOPとC ++の初心者です。 私のプログラムでは、入力ファイルのデータに基づいていくつかのオブジェクトを初期化する必要があります。 たとえば、架空の入力ファイル： # Wind turbine input file: number_of_blades = 2 hub_height = 120 # Airfoil data: airfoil1 = { chord = 2, shape = naca0012} airfoil2 = { chord = 3, shape = naca0016} この例では、TurbineクラスとAirfoilクラスがあるとします。翼オブジェクトは翼弦と形状を知る必要があり、タービンオブジェクトは翼の高さと数を知る必要があります。 各オブジェクトが入力ファイルから自分自身を構築できるように、これを行う必要がありますか？ 例えば： class Turbine { public: Turbine(File input_file); // reads input file …

8 design  object-oriented  c++  architecture  single-responsibility 

アーロノートの質問への回答に応じて： すべての静的メソッドを使用することはできませんか？ 静的メソッドに使用されるメモリは少なくありませんか？各オブジェクトインスタンスは、非静的メンバー関数の独自の実行可能バージョンを持ち歩いているように見えます。 OOの設計が不十分であっても、静的メソッドの呼び出しにどのくらいのオーバーヘッドが関係していても、将来の頭痛の種であっても、実行時に使用するメモリが少なくないのではないでしょうか。 次に例を示します。 ゼロで初期化されたオブジェクトのベクトルを作成します。各オブジェクトには、1つのデータ（9つのdoubleで構成される三角形）が含まれています。各オブジェクトは、.stlファイルから読み取られたデータから順に読み込まれます。必要な静的メソッドは1つだけです。適切なOO設計では、データを直接処理するメソッドを各オブジェクトに配布する必要があります。標準のOOソリューションは次のとおりです。 foreach(obj in vec) { obj.readFromFile(fileName); } 各objはreadFromFile、データとともにのコンパイル済みコードを保持します！ この場合、パフォーマンスよりもメモリの方が問題であり、制約されたシステムには大量のデータがあります。 ソリューション： 名前空間メソッド（C ++には最適ですが、Javaでは不可能） objのクラスの1つの静的メソッド。実行可能コードは、実行時に1か所に保持されます。メソッドを呼び出すための小さなオーバーヘッドがあります。 objの派生元の親クラスreadFromFile。プライベートメソッドが含まれます。コールとsuper.callPrivateMethod()その呼び出しreadFromFile。乱雑ですが、各オブジェクトのメモリオーバーヘッドが多少あります。 readFromFileobjのスコープ外に実装するため、vecのクラスまたは呼び出し元のクラスに実装します。私の意見では、これはデータのカプセル化を壊します。 大量のデータの場合、三角形ごとに1つの明示的なオブジェクトを使用するのは最善の方法ではないことに気づきました。これは単なる例です。

8 java  object-oriented  c++  static-methods 

スローデストラクタを備えた型と、それを値で受け取る関数があるとします。 その操作は、基本的な例外保証よりも優れたものを提供できますか？ または別の方法で定式化すると、操作にコミットアンドロールバックセマンティクスがあるかどうかを判断するときに、値によって渡された引数の破棄を無視できますか？ #include <cstdlib> struct X { ~X() noexcept(0) { if(rand()%6 == 0) throw 0; } // some state }; void update(database db, X arg) noexcept; X x; update(db, x); 個人的には、ウィキペディアの定義に基づく 強力な例外安全性、コミットまたはロールバックセマンティクスとも呼ばれます：操作は失敗する可能性がありますが、失敗した操作には副作用がないことが保証されているため、すべてのデータは元の値を保持します 関数自体がスローすることさえできないとしてもupdate、強く例外セーフであると説明することは有用ではないと私は思います。 私は私の現在の理解の愚かさを私に示してくれる人、あるいはもっと良い議論をしてくれれば幸いです。

8 c++  exceptions  exception-handling  error-handling 

私はC ++で大規模なソフトウェア開発をするのが初めてで、デザインの側面について疑問に思っていました。 私はこの質問を読んでいて、全体として、定数の定義やその他の些細な問題を乗り越えたら、C ++ヘッダーファイルは単なるAPI定義だと思いました。 それらは、他のプログラマー（または他のモジュールからの自分）が使用できるもの（クラス、パブリック関数）を定義しますが、プライベートクラスまたは関数を定義することはできません。それは、ヘッダーファイルが抽象化（インターフェイス...）を定義し、ソースファイルがそれを実装するようなものです。ソースファイルがコンパイルされると、実装の詳細は隠され、モジュールが実行できることを定義する公開されているヘッダーが残ります。 ヘッダーとソースファイルの分離に関するこの見方は、通常の説明よりもはるかに理解しやすく、理解しやすいと感じXXXました。未公開のソースファイル？」 ヘッダーファイルのメンタルモデルはおおよそ正しいですか？私は何を取りこぼしたか ？

8 design  c++  file-structure  headers 

他のオブジェクトを集約するオブジェクトを作成する場合、パススルー関数を使用して内部オブジェクトへのインターフェイスを公開するのではなく、内部オブジェクトへのアクセスを許可したいと思います。 たとえば、2つのオブジェクトがあるとします。 class Engine; using EnginePtr = unique_ptr<Engine>; class Engine { public: Engine( int size ) : mySize( 1 ) { setSize( size ); } int getSize() const { return mySize; } void setSize( const int size ) { mySize = size; } void doStuff() const { /* do stuff …

8 object-oriented  c++  encapsulation 

クラスが所有するオブジェクトの構築を別の関数に委任したい場合があります。何かのようなもの Vertex* new_vertex(const Options& options) { // do stuff... return new Vertex(...); } この関数は、を所有するクラス内でのみ使用することを目的としていVertexます。明らかに、この関数はメモリリークを引き起こす混乱を引き起こす可能性があるため、できるだけ明確にしたいと思います。そのような関数の命名規則はありますか？

8 c++  coding-standards 

OpenGLを使用してC ++でゲームを作成しています。 知らない人のために、OpenGL APIを使用して、などの多くの呼び出しをglGenBuffers行いますglCreateShader。これらの戻り値の型は、GLuint作成したものに対する一意の識別子です。作成されるものはGPUメモリ上に存在します。 GPUメモリが制限されている場合があることを考えると、複数のオブジェクトで使用されるときに同じものを2つ作成したくない場合があります。 たとえば、シェーダー。あなたは、シェーダプログラムをリンクして、あなたが持っていますGLuint。シェーダーを使い終わったら、呼び出す必要がありますglDeleteShader（またはそれに影響を与える何か）。 ここで、次のような浅いクラス階層があるとします。 class WorldEntity { public: /* ... */ protected: ShaderProgram* shader; /* ... */ }; class CarEntity : public WorldEntity { /* ... */ }; class PersonEntity: public WorldEntity { /* ... */ }; 私が今まで見たどのコードでも、すべてのコンストラクターにShaderProgram*渡して、に格納する必要がありWorldEntityます。ShaderProgramは、GLuintOpenGLコンテキストでの現在のシェーダー状態へののバインディングと、シェーダーを使用するために必要な他のいくつかの役立つことをカプセル化する私のクラスです。 私がこれで持っている問題は： を構築するために必要な多くのパラメーターがありますWorldEntity（メッシュ、シェーダー、多数のテクスチャーなどがあると考えてください。これらはすべて共有できるため、ポインターとして渡されます） どのような作成されたWorldEntityかを知る必要性をShaderProgramそれが必要 これはおそらく、異なるエンティティに渡すもののインスタンスを知っているある種のgulp EntityManagerクラスを必要としますShaderProgram。 つまりManager、クラスが必要なインスタンスEntityManagerとともにに自分自身を登録する必要があるかShaderProgram、switch新しいWorldEntity派生型ごとに更新する必要がある、マネージャの大物が必要なためです。 私が最初に考えたのは作成することでしたShaderManager（私は管理者が不良である、知っている）私はへの参照やポインタで渡すというクラスをWorldEntityので、彼らは何でも作成することができますクラスShaderProgramを経由して、彼らが望むShaderManagerとShaderManager、既存のトラックに保つことができShaderProgram、それができるよう、秒すでに存在するものを返すか、必要に応じて新しいものを作成します。 （私ShaderProgramはShaderProgramsの実際のソースコードのファイル名のハッシュを介してsを保存できます） だから今： …

8 design-patterns  c++  game-development  opengl 

私はJavaでのかなり基本的なプログラミング経験があり、C ++とPythonを試しました。Javaでは理にかなっていますが、C ++で記述した基本的なプログラムはWindowsとOS Xで問題なく動作しました。ソースファイルを他のコンピューターに送信し、コンパイルして実行することができました。プログラムはかなり基本的なもので、主に私がC ++を学ぶためにやってきた基本的なオブジェクト指向のものだけです。 もちろん、どのマシンでもC ++プログラムをコンパイルして問題なく実行することはできません。それはどの時点で起こりますか？プラットフォームはどのレベルの複雑さで問題になり始め、プログラムはどこでも実行されませんか？プラットフォーム固有のライブラリを使用するときですか？クロスプラットフォームライブラリを使用するだけで、プログラムをC ++でクロスプラットフォームにできますか？ 私は自分でこれを理解しようとしましたが、見つけたものはすべて頭を悩ませるか、単に質問に答えないかのどちらかです。多くの場合、エミュレーターや、クロスプラットフォームの言語を尋ねる人々がいます。

8 c++  cross-platform 

私は独学のプログラマーです。私は約1.5年前にプログラミングを始めました。今、私は学校でプログラミングクラスを始めました。プログラミングクラスは1/2年間ありましたが、今はもう半分あります。 クラスでは、C ++でプログラミングする方法を学びます（これは、始める前に、私がすでにかなりよく使用することを知っていた言語です）。 このクラスでは何の問題もありませんでしたが、明確な解決策を見つけることができなかった問題が繰り返し発生しています。 問題は次のようになります（疑似コード）： do something if something failed: handle the error try something (line 1) again else: we are done! これはC ++の例です このコードはユーザーに数値の入力を求め、入力が有効になるまで入力を続けます。cin.fail()入力が無効かどうかを確認するために使用します。ときcin.fail()であるtrue私が呼び出す必要がありますcin.clear()し、cin.ignore()ストリームからの入力を取得し続けることができるように。 このコードはをチェックしないことを知っていますEOF。私たちが書いたプログラムは、そうすることを期待されていません。 これが私が学校での課題の1つでコードを書いた方法です。 for (;;) { cout << ": "; cin >> input; if (cin.fail()) { cin.clear(); cin.ignore(512, '\n'); continue; } break; } 私の先生は、私はこれを使うべきではないbreakとcontinue言っていました。彼は代わりにレギュラーwhileかdo ... whileループを使うべきだと提案しました。 …

8 c++  coding-style  loops  io  imperative-programming 

ここにシナリオがあります： libA.soとlibB.soは両方とも同じSTLに静的にリンクします。 libA.soには、std :: stringを返すパブリックAPIがあります。 libB.soはこの関数を呼び出し、文字列のコピーを受け取ります。 文字列のlibB.soのコピーがスコープ外になると、文字列のデストラクタが呼び出されます。 コピーされた文字列を解放しようとするアプリケーションセグメントフォールト。 このように静的にリンクすることは悪いことを他の場所で読んだことがありますが、なぜそれが悪いのかをもっと理解したいと思います。上記のシーケンスがクラッシュする理由を誰かが説明できますか？

8 c++  libraries  stl  static-linking 

CでもC ++でも、CまたはC ++標準に従って動作が定義されていないこの不正なプログラムは興味深いと思います。 #include <stdio.h> int foo() { int a; const int b = a; a = 555; return b; } void bar() { int x = 123; int y = 456; } int main() { bar(); const int n1 = foo(); const int n2 = foo(); const int n3 …

8 c++  c  undefined-behavior 

休業。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善してみませんか？この投稿を編集して、事実と引用で回答できるように質問を更新してください。 6年前休業。 CおよびC ++アプリケーションに関する最新の傾向、および最新とは最新の年を意味するため、がstd::allocator実際よりも頻繁に使用されることを期待していました。 現代のアプリケーションは通常、マルチスレッド化されているか、それらの形式で並行性があり、特にゲームやマルチメディアアプリケーションなどの一部の分野では、大量のメモリを管理します。そのため、通常の高額な割り当て/割り当て解除のコストが上昇し、古いアプリケーションよりもパフォーマンスに影響を与えます。 しかし、std::allocators によるこの種のメモリ管理は一般的ではないため、私が知っている1つのライブラリを数えることすらできません。つまり、標準化されたメモリ管理方法に関する理論的根拠を使用しています。 std::allocator人気がないのには本当の理由がありますか？技術的な理由？

8 c++  memory  c++11  allocation 

私はJavaの値型の提案を読んでいて、この文に出くわしました。「オブジェクトIDは可変性をサポートするためだけに機能し、オブジェクトの状態は変更できますが、同じ組み込みオブジェクトのままです。」 （仮にではあるが）私が理解していることから、オブジェクトIDは、変数がメモリ内の他の場所にあるオブジェクト（JavaまたはC＃のヒープでインスタンス化されたオブジェクトなど）へのポインタまたは参照として機能するという考えです。では、これはオブジェクトの可変性とどう関係しているのでしょうか？これは、たとえば、C ++でスタックにインスタンス化されたオブジェクトが不変であることを意味しますか？ここのリンクが表示されません。

8 java  c++  object-oriented  memory  immutability