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

私は物理シミュレーションを開発していますが、プログラミングが初めてなので、大規模なプログラムを作成するときに問題が発生し続けます（主にメモリの問題）。動的メモリの割り当てと削除（新規/削除など）については知っていますが、プログラムをどのように構成するかについて、より良いアプローチが必要です。 非常に大きなサンプリングレートで、数日間実行されている実験をシミュレートしているとしましょう。10億個のサンプルをシミュレートし、それらを実行する必要があります。 非常に単純化されたバージョンとして、プログラムは電圧V [i]を取り、それらを5で合計すると言います。 すなわち、NewV [0] = V [0] + V [1] + V [2] + V [3] + V [4] NewV [1] = V [1] + V [2] + V [3] + V [4] + V [5] 次に、NewV [2] = V [2] + V [3] + V [4] + …

20 c++  data  memory  array  dynamic 

何か気がかりなことに気づきました。std::stringaをパラメーターとして受け入れるメソッドを作成するたびに、未定義の動作に自分自身を開放しました。 たとえば、これ... void myMethod(const std::string& s) { /* Do something with s. */ } ...このように呼び出すことができます... char* s = 0; myMethod(s); ...そしてそれを防ぐために私ができることは何もありません（私は知っています）。 だから私の質問は次のとおりです。誰かがこれからどのように身を守るのでしょうか？ 頭に浮かぶ唯一のアプローチは、次のstd::stringように、パラメータとしてを受け入れるメソッドの2つのバージョンを常に記述することです。 void myMethod(const std::string& s) { /* Do something. */ } void myMethod(char* s) { if (s == 0) { throw std::exception("Null passed."); } else { myMethod(string(s)); } …

20 c++ 

CおよびC ++では、mainメソッドは、argv [0]の配列の最初の位置にファイル名を保持します。ただし、Javaでは、ファイル名はargs文字列配列に含まれません。 これには実用的な理由がありますか？これにより、コマンドライン引数を1ベースではなく0ベースで反復処理することを理解していますが、利点はありますか？ファイル名は役に立たないとみなされましたか？

20 java  c++  c 

たとえば、次のコードがあります。 auto z = [](int x) -> int { if (x > 0) { switch (x) { case 2: return 5; case 3: return 6; default: return 1; } } return 0; }; そして、後でこれを数回呼び出します。asmコードでは、ラムダを使用した外部呼び出しが表示されます。メタプログラミングで勝つかもしれませんが、asmのデバッグとパフォーマンスで負けるのですか？パフォーマンスとデバッグの単純さを確実にするために、最新の言語機能、マクロ、およびその他のメタプログラミングの側面を避ける必要がありますか？

20 c++  programming-practices  functional-programming  meta-programming 

私は最近auto、C ++ 11で、コンパイラが型を推測する必要のある変数をマークするためにキーワードを選択した理由を疑問に思いました。 auto x = 1; 以来 var 他のプログラミング言語（C＃、Scala、JavaScriptなど）でより一般的なようです。 autoブレークの下位互換性の新しいセマンティクスを理解している限り（これはめったに使用されませんでしたが、C ++の以前のリビジョンでは異なる意味を持ちました。たとえばここを参照） 選択する特別な理由があるかどうかauto（var他のキーワードが有利かどうか）を尋ねたかったのです。C ++ 11標準がリリースされる前に、この問題について具体的な議論はありましたか？ また、レガシーC ++コードをC ++ 11コンパイラで再コンパイルするときに注意すべき非互換性はありますか？

20 c++  c++11  type-systems 

私は初心者レベルのC ++プログラマですが、言語の概念はかなりよく理解しています。SDLやOpenGLなどの外部C ++ライブラリを学習し始めたとき、驚いたことに、C ++の概念をまったく使用していないことがわかりました。 たとえば、SDLもOpenGLもクラスや例外を使用せず、関数とエラーコードを優先します。OpenGLでは、glVertex2fのような関数を見てきました。これは、入力として2つのfloat変数を取り、おそらくテンプレートとしてはより良いでしょう。さらに、これらのライブラリは時々marcosを使用しますが、マクロの使用が悪いことは一般的な合意のようです。 全体として、C ++スタイルよりもCスタイルで記述されているようです。しかし、それらはまったく互換性のない言語ですよね？ 問題は、なぜ現代のライブラリは、それが書かれている言語の利点を使用しないのかということです。

20 c++  object-oriented  libraries  opengl 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 4年前に閉鎖されました。 ヘッダーファイルは、クラス内のすべての関数とデータメンバーの「概要」を提供するため、C ++ソースファイルを参照するときに役立ちます。他の多くの言語（Ruby、Python、Javaなど）にこのような機能がないのはなぜですか？これは、C ++の冗長性が役立つ領域ですか？

20 c++ 

WindowsのWikipediaページには、Windowsがブートローダーとタスクスイッチャー用にAssemblyで、カーネルルーチン用にC と C ++で記述されていることが記載されています。 IIRC、あなたがからC ++の関数を呼び出すことができるextern "C"「Dブロック。カーネル関数にCを使用して、純粋なCアプリがそれらを使用できるようにすることができます（printfなど）が、それらをextern "C "ブロックにラップすることができるのであれば、なぜCでコードを書くのですか？

20 c++  c  language-choice  kernel 

TL; DR 優れた有用なテストを書くのは難しく、C ++でのコストは高くなります。経験豊富な開発者は、何をいつテストするかについての論理的根拠を共有できますか？ 長い話 私はチーム全体でテスト駆動開発を行っていましたが、実際にはうまくいきませんでした。多くのテストがありますが、実際のバグやリグレッションがあるケースをカバーすることはないようです-通常、ユニットが相互作用しているときに発生し、孤立した動作からではありません。 これは多くの場合、ユニットレベルでテストするのが非常に難しいため、TDDの実行を停止し（開発を実際にスピードアップするコンポーネントを除く）、代わりに統合テストの対象範囲を増やすためにより多くの時間を費やしました。小規模なユニットテストは実際のバグをキャッチすることはなく、基本的にメンテナンスオーバーヘッドにすぎませんでしたが、統合テストは本当に努力する価値がありました。 今、私は新しいプロジェクトを継承しましたが、それをテストする方法を知りたいと思っています。ネイティブのC ++ / OpenGLアプリケーションであるため、統合テストは実際にはオプションではありません。しかし、C ++でのユニットテストはJavaよりも少し難しく（明示的にものを作成する必要がありますvirtual）、プログラムはオブジェクト指向ではないため、いくつかのものをモック/スタブすることはできません。 テストを書くためにいくつかのテストを書くためだけに、すべてを引き裂いてオブジェクト指向化したいとは思いません。だから私はあなたに尋ねています：それは何のためにテストを書くべきですか？例えば： 頻繁に変更する予定の関数/クラス 手動でテストするのがより難しい関数/クラス？ すでにテストが簡単な関数/クラス？ 敬意を表するいくつかのC ++コードベースを調べて、テストがどのように行われるかを確認し始めました。今はChromiumのソースコードを調べていますが、コードからテストの理論的根拠を抽出するのは難しいと感じています。人気のあるC ++ユーザー（委員会、本の著者、Google、Facebook、Microsoftなど）がこれにどのようにアプローチしているかについて、良い例や投稿がある場合は、さらに役立つでしょう。 更新 これを書いて以来、私はこのサイトとウェブを探索しました。良いものを見つけました： 単体テストを行わないのはいつが適切ですか？ /programming/109432/what-not-to-test-when-it-comes-to-unit-testing http://junit.sourceforge.net/doc/faq/faq.htm#best 悲しいことに、これらはすべてJava / C＃中心です。Java / C＃で多くのテストを作成することは大きな問題ではないため、通常は利益がコストを上回ります。 しかし、上で書いたように、C ++ではより困難です。特に、コードベースがそれほどオブジェクト指向でない場合は、ユニットテストのカバレッジを良好にするために、物事をひどく混乱させる必要があります。例えば、私が継承したアプリケーションにGraphicsは、OpenGLの上にある薄層の名前空間があります。すべてのエンティティをテストするには、すべてのエンティティがその機能を直接使用するため、これをインターフェイスとクラスに変換し、すべてのエンティティに挿入する必要があります。それはほんの一例です。 したがって、この質問に答えるとき、テストを書くためにかなり大きな投資をしなければならないことに注意してください。

20 c++  unit-testing  tdd  integration-tests 

3 のルール（新しいc ++標準の5のルール）の状態： デストラクタ、コピーコンストラクタ、またはコピー割り当て演算子のいずれかを明示的に宣言する必要がある場合は、おそらく3つすべてを明示的に宣言する必要があります。 しかし、一方で、マーティンの「クリーンコード」は、すべての空のコンストラクターとデストラクターを削除することを推奨しています（293ページ、G12：Clutter）。 実装されていないデフォルトのコンストラクタはどのような用途に使用されますか？役目を果たすのは、意味のないアーティファクトでコードを混乱させることです。 だから、これらの2つの反対意見をどのように扱うのですか？空のコンストラクタ/デストラクタを実際に実装する必要がありますか？ 次の例は、まさに私が意味することを示しています。 #include <iostream> #include <memory> struct A { A( const int value ) : v( new int( value ) ) {} ~A(){} A( const A & other ) : v( new int( *other.v ) ) {} A& operator=( const A & other ) …

20 c++  clean-code  rule-of-three 

auto特にforループでキーワードを使用することの長所と短所は何ですか？ for(std::vector<T>::iterator it = x.begin(); it != x.end(); it++ ) { it->something(); } for(std::map<T>::iterator it = x.begin(); it != x.end(); it++ ) { it->second->something(); } for(auto it = x.begin(); it != x.end(); it++ ) { it->?? } マップのイテレータがあるのか、オブジェクトのプロパティを使用するのfirstか、secondまたは単にプロパティに直接アクセスするのかがわからない場合に、イテレータがあるかどうかがわからないようです。 これは、キーワードを使用するかどうかに関するC＃の議論を思い出させますvar。私がこれまでに得ている印象は、C ++の世界autoでvarは、C＃の世界よりも少ない戦いで人々がキーワードを採用する準備ができているということです。私にとって最初の本能は、変数の型を知りたいので、その変数に対して実行できる操作を知ることができるということです。

20 c++  c++11 

私は人々が信じる環境にとどまっています： Javaジェネリックは、実際のコーディングではなく、ライブラリの書き込み専用に使用される機能です。 C ++はオブジェクト指向プログラミング言語です。templateオプションで回避可能な機能です ただし、これらの人々は、汎用プログラミング（STL、Javaコンテナーなど）を使用して作成されたライブラリーに大きく依存しています。templatesまたはを使用してコードを記述する場合generics、コードレビューアはそれを拒否する可能性が高く、「適切/理解可能/エレガント」な方法でそれを記述するようコメントします。 このような考え方は、通常のプログラマーから上級管理職まで適用できます。90％の時間、これらの人々はロビー活動をしているため、逃げ道はありません。 それらを説明する最良の方法（のどを切らない）、OOと汎用プログラミングの両方を同時に構成するコードを記述する実際的なアプローチは何ですか？

20 java  c++  templates  generics 

予備メモ さまざまな種類のテストの違いについては説明しませんが、これらのサイトには既にいくつかの質問があります。 私はそこに何を取るだろうと、それは言う：単位は、「アプリケーションの最小単離ユニットテスト」の意味でのテストこの質問は、実際に由来します 分離の問題 プログラムの最小の分離可能な単位は何ですか。さて、私が見ているように、それは（非常に？）あなたがコーディングしている言語に依存します。 Micheal Feathersは縫い目の概念について語っています：[WEwLC、p31] シームは、その場所で編集せずにプログラムの動作を変更できる場所です。 そして、詳細に立ち入ることなく、私は、ユニットテストのコンテキストで、あなたの「テスト」があなたの「ユニット」とインターフェースできるプログラムの場所であると理解しています。 例 特にC ++の単体テストでは、テスト対象のコードから、特定の問題に対して厳密に要求される継ぎ目を追加する必要があります。 例： 非仮想実装で十分な仮想インターフェースを追加する 分割-generalizing（？）-テストを追加しやすくするための（さらに小さな）クラス 単一の実行可能プロジェクトを、一見「独立した」ライブラリに分割し、テストのためにそれらを独立してコンパイルしやすくするために「ちょうど」。 質問 同じことを願ういくつかのバージョンを試してみましょう。 ユニットテストでアプリケーションのコードを構造化する必要があるのは、ユニットテストに「のみ」有益であるか、実際にはアプリケーション構造に有益ですか。 必要とされるコードの一般化は、それがユニット・テスト可能な何のために有用にすることですが、ユニットテスト？ 単体テストを追加すると、不必要に一般化されますか？ シェイプユニットテストは、コードに「常に」強制することも、問題の領域から見た一般的なコードの良い形ですか。 コードを使用する2番目の場所が必要になるまで/必要になるまで一般化しないと言った経験則を覚えています。単体テストでは、コードを使用する2番目の場所、つまり単体テストが常にあります。それで、この理由は一般化するのに十分ですか？

20 c++  unit-testing  tdd  generalization 

ここで何が尋ねられているかを伝えるのは難しいです。この質問は曖昧、曖昧、不完全、過度に広範、または修辞的であり、現在の形式では合理的に答えることができません。この質問を明確にして、再開できるようにするには、ヘルプセンターに アクセスしてください。 8年前に閉鎖されました。 この質問はして移行され、それがソフトウェア工学スタック所に答えることができるので、スタックオーバーフローから。 8年前に移行され ました。 現在のプロジェクトアーキテクチャを開発し、独自に開発を開始しました（次のようなものに到達しますrevision 40）。 シンプルな地下鉄ルーティングフレームワークを開発しており、私の設計は非常によくできているようです- いくつかのメインモデル、対応するビュー、メインロジック、データ構造が「あるべき」ようにモデル化され、レンダリングから完全に分離され、アルゴリズム部分も実装されましたメインモデルとは別に、少数の交差点がありました。 私は、その設計をスケーラブルで、カスタマイズ可能で、実装が容易で、主に「ブラックボックスの相互作用」に基づいて相互作用し、非常に素晴らしいと呼びます。 さて、何が行われたか： 対応するインターフェースの実装を開始し、便利なライブラリを移植し、アプリケーションの一部の実装スタブを作成しました。 コーディングスタイルとそのコーディングスタイルの使用例（自分の記述コード）を説明したドキュメントがありました。 コード（スマートポインターでラップ）などC++を含む、多かれ少なかれ最新の開発手法の使用を強制しましたno-delete。 具体的なインターフェイス実装の目的と、その使用方法を文書化しました。 単体テスト（ほとんどの場合、「実際の」コードがあまり多くないため統合テスト）と、すべてのコア抽象化のための一連のモック。 私は12日間休みました。 現在何がありますか（プロジェクトはチームの他の4人のメンバーによって開発されました）： すべてのプロジェクトの上に3種類のコーディングスタイル（私は推測する、それらの2つが同じスタイルを使用することに同意した:)、同じことが私たちの抽象化の命名にも適用される（例えばCommonPathData.h、SubwaySchemeStructures.h）基本的にはいくつかのデータ構造を宣言し、ヘッダーです。 最近実装された部品のドキュメントの絶対的な不足。 私が最近呼び出すことができるものsingle-purpose-abstractionは、少なくとも2つの異なるタイプのイベントを処理し、他の部分と密接に結合しています。 使用されるインターフェイスの半分には、メンバー変数が含まれるようになりました(sic!)。 ほぼすべての場所での生のポインターの使用。 " (Rev.57) They are unnecessary for this project"のため、ユニットテストは無効です。 ... （おそらくすべてではない）。 コミット履歴は、私の設計が過剰であると解釈され、人々がそれを個人用自転車と再実装されたホイールと組み合わせ始め、コードチャンクの統合に問題があったことを示しています。 さて、プロジェクトはまだやらなければならないことのほんの一部をしているだけで、深刻な統合の問題があります。メモリリークがあると思います。 この場合にできることはありますか？ 私はすべての努力が利益をもたらさなかったことに気づきましたが、締め切りはもうすぐであり、私たちは何かをしなければなりません。誰かが同様の状況にありましたか？ 基本的には、プロジェクトの良い（まあ、できる限りのことをすべてやった）ことは良いことになると思いましたが、間違っていることは理解しています。

20 c++  project-management  refactoring  teamwork 

私はC ++でコーディングしなければならないプログラミングコンテストの準備をしていますが、それは短時間で動作するコードを作成することです。たとえば、マクロを使用して最小2つのintを取得するか、memsetsを使用して配列を初期化することができます（ただし、ここでは使用しないでください）。 これは、実際の仕事で使用するためにどのようなコーディング技術が存在するのかという質問につながりますか？

20 c++