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

ISO / ANSIがC ++をバイナリレベルで標準化していないのはなぜですか？C ++には多くの移植性の問題がありますが、これはバイナリレベルでの標準化の欠如によるものです。 Don Boxが書いています（彼の本Essential COMの章COM As A Better C ++から引用） C ++と移植性 C ++クラスをDLLとして配布することを決定すると、C ++ の基本的な弱点の 1つ、つまりバイナリレベルでの標準化の欠如に直面します。ISO / ANSI C ++ドラフトワーキングペーパーは、どのプログラムをコンパイルし、それらを実行することのセマンティック効果をコード化しようとしますが、C ++のバイナリランタイムモデルの標準化は試みません。この問題が初めて明らかになるのは、クライアントがFastString DLLのビルドに使用した環境以外の C ++開発環境からFastString DLLのインポートライブラリにリンクしようとしたときです。 このようなバイナリ標準化の欠如により多くの利点または損失がありますか？

14 c++  dll  ansi  iso 

この質問から、別の質問があります... クリス・ソーヤーがアセンブラーでジェットコースターの大部分を書くのにどのくらいの時間とどのような複雑さが関係していたでしょうか？ この質問を特定して分類するために、私は興味があります。 クリスが自分でゲームを書くのにかかったと推定されるおおよその工数（推測）または、アセンブラーのコーディング時間の比率のおよその割合を指定して、C / C ++ですべてを記述します。 アセンブラーをよく知っているプログラマーは、これをこのような低レベルの言語抽象化のための過度に複雑なタスクと考えていますか？パフォーマンス上のメリットは別として、これはChrisが持っている異常な自然の能力なのでしょうか、それともその程度の学習に値するスキルセットなのでしょうか？複雑さ/パフォーマンスのことはアセンブラーを習得する価値があると（書くために）考えているのか、それともアセンブラーで自然に発達したスキルをたくさん持っている場合（おそらくハードウェアの操作から） / hardware drivers / electronics / etc）。

14 programming-languages  c++  complexity  game-development 

非自明なC ++ const関連の重複を避けるために、const_castは機能するが、非constを返すプライベートconst関数は機能しない場合がありますか？ Scott MeyersのEffective C ++ item 3では、const_castと静的キャストを組み合わせることで、コードの重複を避けるための効果的で安全な方法を提案しています。 const void* Bar::bar(int i) const { ... return variableResultingFromNonTrivialDotDotDotCode; } void* Bar::bar(int i) { return const_cast<void*>(static_cast<const Bar*>(this)->bar(i)); } マイヤーズは、const関数にnon-const関数を呼び出すことは危険であると説明しています。 以下のコードは反例を示しています。 マイヤーズの提案に反して、静的キャストと組み合わせたconst_castは危険な場合があります 時々const関数がnon-constを呼び出すことはそれほど危険ではありません const_castを使用して両方の方法で潜在的に有用なコンパイラエラーを隠すことがあります。 const_castを避け、const以外のメンバーを返すconst constメンバーを追加することも別のオプションです コードの重複を回避するconst_cast戦略のいずれかが適切なプラクティスと見なされていますか？代わりにプライベートメソッド戦略を好むでしょうか？const_castは機能するが、プライベートメソッドは機能しない場合がありますか？複製以外に他のオプションはありますか？ const_cast戦略に関する私の懸念は、コードが記述されたときに正しい場合でも、メンテナンス中にコードが不正確になり、const_castが有用なコンパイラエラーを隠す可能性があることです。一般的なプライベート関数の方が一般に安全なようです。 class Foo { public: Foo(const LongLived& constLongLived, LongLived& mutableLongLived) : mConstLongLived(constLongLived), mMutableLongLived(mutableLongLived) {} // …

14 c++  dry  const 

これが概念的に言語を破る特定の理由、またはこれが技術的に実行不可能である特定の理由がありますか？ 使用法はnew演算子を使用します。 編集：私は「新しいオペレーター」と「新しいオペレーター」をまっすぐに取得することへの希望をあきらめ、率直になります。 問題のポイントは、なぜコンストラクターが特別なのかということです。もちろん、言語仕様は合法であるが必ずしも道徳的ではないことを教えてくれることに留意してください。通常、合法とは、言語の他の部分と論理的に一致するもの、単純で簡潔なもの、コンパイラーが実装できるものによって通知されます。これらの要因を評価する際の標準化委員会の考えられる理論的根拠は、意図的で興味深いものです。したがって、質問です。

14 c++ 

コードにいくつかのタイプの出力メッセージが必要だとしましょう。それらの1つはDEBUG、コードがデバッグモードでコンパイルされたときにのみ出力されます。 通常私は #ifdef DEBUG std::cout << "Debug message" << std::endl; #endif これはかなり面倒で、多くの場所で使用するのは面倒です。 コードスニペットのマクロを定義することをお勧めします。このように使用しますか？ MSG_DEBUG("Debug message") または、マクロなしでそれを処理する他のよりエレガントな方法はありますか？異なるプロジェクトで両方の言語を使用しているため、CとC ++の両方で可能なソリューションに興味があります。

13 c++  c  macros 

（フレームワークによれば）クロスプラットフォームであると想定されている、初期のC ++プロジェクトの1つを終えていました。ライブラリはすべてクロスプラットフォームであるため、OSXビルドを「後で」実行するのは簡単だと思い、プロジェクトをWindowsとVisual Studioで完全に開発しました。これは事実ではないことが判明しましたが、「Windowsコード」が正しく実行されず、修正すべきコンパイルエラーがいくつかありました。 コードがすべてのプラットフォームと互換性があることを事前に保証するために、どのような手法が存在しますか？すべてのプラットフォームを同時に開発し、新しいプラットフォームバージョンを次々に開発するのではなく、新しい機能が追加されたときに、すべてのプラットフォームに対して同時にコードをテストしますか？（*） ツールに依存するのではなく、使用するツールに関係なく、クロスプラットフォームの互換性を支援する「開発プロセス」ではなく、具体的にアドバイスを探します。上記の（*）のように。 具体的には、WDL-OL（https://github.com/olilarkin/wdl-ol）といくつかのクロスプラットフォームDSPライブラリを使用してVSTプラグインを開発しています。WDL-OLプロジェクトにはVSプロジェクトとXcodeプロジェクトの両方がセットアップされていますが、問題はライブラリーに起因し、コンパイラーの違いに起因すると推測します。

13 c++  development-process  cross-platform 

ずっと前にC ++を学んだとき、C ++のポイントの一部は、ループに「ループ不変式」があるように、クラスにもオブジェクトの存続期間に関連する不変式があることを強く強調しました。オブジェクトが生きている限り。コンストラクターによって確立され、メソッドによって保持されるべきもの。カプセル化/アクセス制御は、不変条件を強制するのに役立ちます。RAIIは、このアイデアでできることの1つです。 C ++ 11以降、ムーブセマンティクスがあります。移動をサポートするクラスの場合、オブジェクトからの移動はその寿命を正式に終了することはありません-移動は「有効な」状態のままにすることになっています。 クラスの設計において、クラスの不変式が移動元までしか保持されないように設計するのは悪い習慣ですか？または、高速化できるようになれば大丈夫です。 具体的にするために、コピー不可だが移動可能なリソースタイプがあるとします。 class opaque { opaque(const opaque &) = delete; public: opaque(opaque &&); ... void mysterious(); void mysterious(int); void mysterious(std::vector<std::string>); }; そして、何らかの理由で、おそらく既存のディスパッチシステムで使用できるように、このオブジェクトのコピー可能なラッパーを作成する必要があります。 class copyable_opaque { std::shared_ptr<opaque> o_; copyable_opaque() = delete; public: explicit copyable_opaque(opaque _o) : o_(std::make_shared<opaque>(std::move(_o))) {} void operator()() { o_->mysterious(); } void operator()(int …

13 c++  object-oriented-design  c++11  invariants 

典型的なC ++コードは次のとおりです。 foo.hpp #pragma once class Foo { public: void f(); void g(); ... }; foo.cpp #include "foo.hpp" namespace { const int kUpperX = 111; const int kAlternativeX = 222; bool match(int x) { return x < kUpperX || x == kAlternativeX; } } // namespace void Foo::f() { ... …

13 c++  unit-testing 

ここでは特にC ++とBjarne Stroustrupの命名規則に言及しますが、原則として、人々はあちこちで他の言語にも多少似たルールを使用しているのを見てきました。 そのため、基本的な考え方は、コードを読み取りながら標準タイプとユーザー定義タイプを区別できるようにすることです。たとえば、Bjarne Stroustrupは、 タイプの最初の大文字（例：SquareおよびGraph） それを考慮して C ++言語と標準ライブラリは大文字を使用しません 上記の目標を達成できます。 しかし、なぜそうする必要があるのでしょうか？標準型とユーザー定義型を区別する目的は何ですか？ 私はそのことに関するBjarne Stroustrupの推論を見つけることができませんでした。さらに、私自身は正反対に考えています。：DI知っています、「Stroustrupに異議を唱えるのは誰ですか？」しかし、listen、たとえば演算子のオーバーロードなどのC ++言語機能の束は、ユーザー定義型に標準型と同様のレベルの構文サポートを許可する目的に役立ちます。そして、これはすべて異なる命名規則に困惑しています... PS言うまでもなく、1つの単語でクラスに名前を付けるのに十分ではなく、アンダースコアで区切られた大文字で始まる単語はあまりにも異質に見えます。

13 c++  naming-standards 

メンバメソッドを備えた完全なモジュールにできるクラスではなく、c ++構造体を使用してデータ構造を定義することがよくあります。今、私たちはそれらが両方とも同じであることがわかります（大まかに言って）。 構造体をデータのみのエンティティとして頻繁に使用/処理するという事実は、デフォルトのコンストラクタも追加しないという衝動を引き起こします。しかし、コンストラクターは常に優れており、物事を単純化し、エラーを排除するのに役立ちます。 デフォルトのコンストラクタをデータ構造に追加すると、眉をひそめますか？ 他の基準が満たされている場合、デフォルトコンストラクターを実装すると、構造体は非POD（プレーンな古いデータ型）になりますか？ 物事を視野に入れるために、簡単な例を考えてみましょうが、実際には構造体ははるかに大きくなります。 struct method { char name[32]; float temperature; int duration; }; メソッドを作成するたびに、値を設定するのを忘れた場合、（控えめに言っても）心配する必要があります。temperatureメソッドを設定してシステムに適用するのを忘れてしまったことを想像してください。このメソッドはランダムに高い値になり、混乱を引き起こします。または、設定するのを忘れたためduration、メソッドが未知の高期間にわたって適用されます。 オブジェクトを保証するコンストラクタを実装するのではなく、毎回オブジェクトを初期化する責任を負うべきなのはなぜですか？

13 c++  object-oriented  programming-practices 

私はすでにこの質問をSOに投稿しましたが、大丈夫でした。それは残念ながら閉じられました（再開するには1票しか必要ありません）が、誰かが私がここに投稿することを提案したので、それはより適切なので、以下は文字通り質問のコピーペーストです この答えに関するコメントを読んでいたこの引用を見ました。 オブジェクトのインスタンス化とオブジェクト指向の機能は、最初から設計されているため、非常に高速です（多くの場合、C ++よりも高速です）。コレクションは高速です。ほとんどの最適化されたCコードであっても、標準Javaはこの領域で標準C / C ++に勝ります。 あるユーザー（私が追加する可能性のある非常に高い担当者）は、この主張を大胆に擁護し、 Javaでのヒープ割り当てはC ++よりも優れています Javaでコレクションを守るこのステートメントを追加しました また、主にメモリサブシステムが異なるため、JavaコレクションはC ++コレクションに比べて高速です。 だから私の質問はこれのどれでも本当に真実でありえ、もしそうなら、なぜJavaのヒープ割り当てがそんなに速くなるのかということです。

13 java  c++  performance  heap  collections 

閉まっている。この質問はトピック外です。現在、回答を受け付けていません。 この質問を改善したいですか？ 質問を更新して、 Software Engineering Stack Exchangeのトピックになるようにします。 6年前に閉鎖されました。 私はこの質問をC ++プログラマーに投げかけています。a）C ++プログラマーだけが、例の技術的なメリットを判断できるからです。b）プログラマーだけが、このようなコードを書く他のプログラマーの気質を感じます。 人事部長と取締役は、単に現場で証拠を見ているだけで問題があることを認識しています。問題のプログラマーにより多くの時間を与えるかどうかは私の呼びかけです。エラーの多くは非常に基本的なレベルです-私の質問（プログラマーにとって）は、上級C ++開発者であると公言する人に、現在のコードのサンプルに基づいて疑いの利益を与えるべきかどうかです。非プログラマー-C ++プログラミング以外の人でも-これについて判断することはできません。 背景として、私は定評のある会社の開発者を管理するタスクを割り当てられました。彼らにはすべてのC ++コーディングを専門とする単一の開発者がいます（永遠に）が、作業の質はひどいものです。コードのレビューとテストにより、多くの問題が明らかになりました。最悪の事態の1つはメモリリークです。開発者はコードのリークを一度もテストしたことがなく、わずか1分でアプリケーションが多くのMBをリークする可能性があることを発見しました。ユーザーは巨大な減速を報告しており、彼の見解は「それは私とは何の関係もありません-彼らが終了して再起動すれば、それは再び良いことです。」 私は彼にリークを検出して追跡するためのツールを提供し、ツールの使用方法、問題が発生した場所、およびそれらを修正するために何をすべきかを実証するために何時間も座っていました。私たちは6か月後、新しいモジュールを作成するように彼に割り当てました。私たちがより大きなコードベースに統合される前に私はそれをレビューし、以前と同じ悪いコーディングを発見することに落胆しました。私が理解できないと感じるのは、一部のコーディングがアマチュアよりも悪いということです。たとえば、彼は別のクラス（バー）のオブジェクトを作成できるクラス（Foo）が必要でした。彼は、フーがバーへの言及を保持することを決めました、例えば： class Foo { public: Foo(Bar& bar) : m_bar(bar) {} private: Bar& m_bar; }; しかし（他の理由で）彼はFooのデフォルトコンストラクターも必要とし、彼の初期設計に疑問を呈するのではなく、このgemを書きました。 Foo::Foo() : m_bar(*(new Bar)) {} そのため、デフォルトのコンストラクターが呼び出されるたびに、Barがリークされます。さらに悪いことに、Fooはヒープから他の2つのオブジェクトにメモリを割り当てますが、デストラクタやコピーコンストラクタを作成しませんでした。したがって、Fooの割り当てごとに3つの異なるオブジェクトが実際にリークし、Fooがコピーされたときに何が起こったのか想像できます。そして、それは良くなるだけです-彼は他の3つのクラスで同じパターンを繰り返したので、1回限りのスリップではありません。非常に多くのレベルで概念全体が間違っています。 これが完全な初心者から来た場合、私はより多くの理解を感じるでしょう。しかし、この男は長年にわたってこれを行っており、過去数か月にわたって非常に集中的なトレーニングとアドバイスを行ってきました。彼はほとんどの時間、メンタリングやピアレビューなしで働いてきましたが、彼は変わらないと感じ始めています。だから私の質問は、そのような明らかに悪いコードを書いている人に固執しますか？

13 c++  management  training 

共通の基本型の別のクラスをラップするクラスがあります。基本型インターフェースは非常に大きいため、これには多くのパススルー関数の作成が含まれます。これを回避する方法を探しています。 例を作りましょう： Car / \ Volvo VolvoWithTrailer ここで、VolvoWithTrailerの車のインターフェイスにすべての関数を実装し、ラップされたVolvoオブジェクトで適切な関数を呼び出す必要があります。ただし、GetMaxSpeed（）は、より低い値を返します。基本的に次のような多くの機能があります int VolvoWithTrailer::GetNumSeats() { return mVolvo.GetNumSeats() } これを解決する明白な方法は、VolvoWithTrailerをVolvoのサブクラスにすることです。 Car | Volvo | VolvoWithTrailer しかし、それは継承よりも構成を優先するという原則に違反しているようです。 これらのすべてのラッパー（言語はC ++）を書くことを他にどのように回避できますか？または-それがあなたの立場である場合-なぜ私はそれらを書くだけですか/単に継承を使用するのですか？これに役立つテンプレートの魔法はありますか？

13 c++  inheritance  templates  composition 

C ++の新機能！だから私はこれを読んでいた：http : //www.learncpp.com/cpp-tutorial/110-a-first-look-at-the-preprocessor/ ヘッダーガード ヘッダーファイルには他のヘッダーファイルを含めることができるため、ヘッダーファイルが複数回インクルードされる状況になる可能性があります。 そこで、これを回避するためにプリプロセッサディレクティブを作成します。しかし、私はわからない-なぜコンパイラがちょうどできないのか... 同じものを2回インポートしないのですか？ ヘッダーガードはオプションです（ただし、明らかに良い方法です）ので、何かを2回インポートしたいというシナリオがあると思います。そのようなシナリオはまったく考えられませんが。何か案は？

13 c++  compiler 

私はC ++の男ではありませんが、これについて考えることを余儀なくされています。C ++では多重継承が可能ですが、C＃ではできないのはなぜですか？（ダイヤモンドの問題を知っていますが、それは私がここで尋ねていることではありません）。C ++は、複数の基本クラスから継承された同一のメソッドシグネチャのあいまいさをどのように解決しますか？そして、なぜ同じデザインがC＃に組み込まれていないのですか？

13 c#  c++  language-design  multiple-inheritance