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

C ++ 11の統一された初期化は言語の構文上の曖昧さを解決することを理解していますが、多くのBjarne Stroustrupのプレゼンテーション（特にGoingNative 2012の講演中のプレゼンテーション）では、彼の例は主にオブジェクトを構築するときに常にこの構文を使用しています。 すべての場合に均一な初期化を使用することをお勧めしますか？コーディングスタイルと一般的な使用法に関する限り、この新しい機能に対する一般的なアプローチはどうあるべきですか？使用しない理由は何ですか？ 私の考えでは、ユースケースとして主にオブジェクトの構築を考えていますが、考慮すべき他のシナリオがある場合はお知らせください。

172 c++  c++11 

CとC ++は異なる言語であることは理解していますが、C ++を学習していたとき、CはC ++のサブセットであるか、C ++はクラスを持つCであると常に言われました。そして、C ++ x0、C ++ 11（または一般的な現代のC ++ 11/14/17）が登場するまで、それは非常に真実でした。実際（特に組み込みシステムで作業している場合）、C ++で記述されたコードを見つける可能性が非常に高くなりますが、多くの部分は完全に純粋なC言語で記述されています。ここにいくつかの質問があります： C / C ++という用語の使用をやめるべきですか？ ＃1の答えが「はい」の場合、CとC ++を組み合わせて使用​​するプログラムをどのように呼び出すのでしょうか？ それらの両方が「異なる」言語であることを考えると、C ++コンパイラがC言語で書かれたコードのサポートをやがて停止する可能性があります（現代のc ++はポインタ、動的メモリ処理などの基本的なもののためにCの考え方とは異なるため） 現在、互換性を維持するためにC / C ++の標準を作成している人々の間でコラボレーションはありますか ＃4が「はい」の場合、このようなコラボレーションは近い将来、現代のc ++（11/14/17）の登場で終わる可能性があります 私はすでに同様の質問があることを知っていますが、多くの人々がこれらの質問を共有していると確信していますので、特に近い将来のC ++の傾向に関係する点については良い答えを得ることに非常に興味があります。

140 c++  c  terminology  c++11 

私はハーブサッターによるカンファレンスを見て、そこで彼はすべてのC ++プログラマーの使用を奨励していますauto。 C＃コードvarを広く使用されていたコードを読む必要があり、コードを理解するのは非常に困難varでした。時間の経過ごとに右側の戻り値の型を確認する必要がありました。しばらくして変数の型を忘れてしまったので、時々複数回！ コンパイラーは型を知っているので、型を書く必要はありませんが、コンパイラーではなくプログラマー向けにコードを書くことは広く受け入れられています。 私はそれがより簡単に書くことも知っています： auto x = GetX(); より： someWeirdTemplate<someOtherVeryLongNameType, ...>::someOtherLongType x = GetX(); ただし、これは1回しか記述されず、GetX()戻り値の型が何回あるかを理解するために何度もチェックされますx。 これは私に不思議に思いましたauto—C ++コードを理解するのを難しくしますか？

122 c++  c++11 

enum X : int（C＃）と、またはenum class X : int（C ++ 11）の隠れた内部フィールド有するタイプであるintことは、任意の値を保持することができます。さらに、いくつかの定義済み定数がX列挙型で定義されています。列挙型を整数値にキャストしたり、その逆を行うことができます。これは、C＃とC ++ 11の両方に当てはまります。 C＃では、列挙型は個々の値を保持するためだけでなく、Microsoftの推奨に従って、フラグのビットごとの組み合わせを保持するためにも使用されます。このような列挙型は（通常、必ずしもそうではありませんが）[Flags]属性で装飾されています。開発者の生活を楽にするために、ビット単位の演算子（OR、ANDなど）がオーバーロードされているため、次のようなことが簡単にできます（C＃）。 void M(NumericType flags); M(NumericType.Sign | NumericType.ZeroPadding); 私は経験豊富なC＃開発者ですが、C ++をプログラミングしてから数日しか経っていないため、C ++の規約については知りません。C＃で使用したのとまったく同じ方法でC ++ 11列挙型を使用する予定です。C ++ 11では、スコープ付き列挙型のビット演算子はオーバーロードされないため、それらをオーバーロードしたかったのです。 これは議論を呼び起こし、意見は3つの選択肢の間で異なるようです： C＃と同様に、ビット型を保持するために列挙型の変数が使用されます。 void M(NumericType flags); // With operator overloading: M(NumericType::Sign | NumericType::ZeroPadding); // Without operator overloading: M(static_cast<NumericType>(static_cast<int>(NumericType::Sign) | static_cast<int>(NumericType::ZeroPadding))); しかし、これはC ++ 11のスコープ付き列挙型の厳密に型指定された列挙型の哲学に反するでしょう。 列挙型のビットごとの組み合わせを保存する場合は、プレーン整数を使用します。 void …

60 c++  c++11  enum  bitwise-operators 

「Going Native 2012」ストリームを見ているだけで、についての議論に気付きましたstd::shared_ptr。Bjarneのやや否定的な見方std::shared_ptrと、オブジェクトの寿命が不確かな場合の「最後の手段」として使用すべきだという彼のコメントを聞いて、私は少し驚いていました（彼によると、そうではないはずです）。 これをもう少し詳しく説明したい人はいますか？どうすればstd::shared_ptrオブジェクトの寿命を安全な方法で管理し、管理できますか？

59 c++  c++11  smart-pointer 

C \ C ++仕様では、コンパイラが独自の方法で実装するための多数の動作が公開されていません。同じことについて常にここで質問され続ける多くの質問があり、それに関するいくつかの素晴らしい投稿があります： https://stackoverflow.com/questions/367633/what-are-all-the-common-undefined-behaviour-that-ac-programmer-should-know-abo https://stackoverflow.com/questions/4105120/what-is-undefined-behavior https://stackoverflow.com/questions/4176328/undefined-behavior-and-sequence-points 私の質問は、未定義の振る舞いについてではなく、本当に悪いことです。危険と標準からの関連する未定義の動作の引用のほとんどを知っているので、それがどれほど悪いかについての回答を投稿することは控えてください。この質問は、コンパイラ実装のために非常に多くの動作を開いたままにすることの背後にある哲学に関するものです。 パフォーマンスが主な理由であると述べている素晴らしいブログ記事を読みました。パフォーマンスがそれを許可するための唯一の基準であるのか、それともコンパイラー実装のためにオープンなままにする決定に影響する他の要因があるのか​​疑問に思っていましたか？ 特定の未定義の動作がコンパイラが最適化するのに十分な余地を提供する方法について引用する例がある場合は、それらをリストしてください。パフォーマンス以外の他の要因を知っている場合は、十分な詳細を含めて回答を返してください。 質問を理解していないか、回答を裏付ける十分な証拠/情報源がない場合は、広く推測する回答を投稿しないでください。

59 c++  c  philosophy  c++11  undefined-behavior 

私は、コンパイル段階で特定の種類のバグをキャッチするために、強く型付けされたtypedefを宣言する方法を考えていました。多くの場合、intをいくつかのタイプのIDにtypedefするか、位置または速度を指定するベクトルを入力します。 typedef int EntityID; typedef int ModelID; typedef Vector3 Position; typedef Vector3 Velocity; これにより、コードの意図をより明確にすることができますが、長い夜のコーディングの後、さまざまな種類のIDを比較したり、速度に位置を追加したりするなど、愚かな間違いを犯す可能性があります。 EntityID eID; ModelID mID; if ( eID == mID ) // <- Compiler sees nothing wrong { /*bug*/ } Position p; Velocity v; Position newP = p + v; // bug, meant p + v*s but …

49 c++  c++11  type-safety 

C ++ 11にはstd::sto@文字列からints / floats / longsを簡単にアンパックするための関数ファミリーがあることに気がつきました。しかし、その反対が実装されていないことに驚いています。なぜ標準化委員会には、std::itosints / floats / whatever（back）から文字列に戻るための関数ファミリーが含まれていないのですか？

37 c++  parsing  strings  c++11 

私は初心者であり、プログラミングの知識はほとんどありません。 新しいC ++ 11を扱っている本からC ++を直接学んだり、古い最高のC ++の本を勉強したりするのは良いことでしょうか？ C ++ 11を学習する前に、C ++についての知識がほとんどないはずですか？またはそこから直接開始できますか？ C ++ 11から直接起動すると問題が発生しますか？いいえの場合は、C ++ 11に関する本をいくつか提案してください。

36 c++  c++11 

私はしばらくの間C ++でプログラミングを行ってきましたが、ほとんどはC ++の低レベルの機能に集中していました。それによって、私は主にポインターと生の配列で作業することを意味します。この動作は、クラスでCとしてC ++を使用することで知られていると思います。それにもかかわらず、私は最近初めてCを試しました。C＃やJavaなどの言語が、ディクショナリやリストなどの便利な標準ライブラリクラスでこれらの詳細を隠していることに驚きました。 C ++標準ライブラリにはベクター、マップ、文字列などの多くのコンテナがあり、C ++ 11はstd ::配列と範囲ループを使用することでこれに追加するだけであることを認識しています。 これらの最新の言語機能をどのように活用し、どの場面がどの瞬間に適しているかを最もよく学ぶにはどうすればよいですか？最近のC ++でのソフトウェアエンジニアリングは、ほとんど手動のメモリ管理から解放されているのですか？ 最後に、新しい標準を最大限に活用するためにどのコンパイラを使用する必要がありますか？Visual Studioには優れたデバッグツールがありますが、VS2012でさえひどいC ++ 11サポートがあるようです。

35 c++  c++11 

C ++についての私の主な不満の1つは、動的ライブラリ（つまり、dll / so）境界の外側にstdライブラリオブジェクトを渡すことが実際にはどれほど難しいかということです。 stdライブラリは、多くの場合ヘッダーのみです。これは、いくつかの素晴らしい最適化を行うのに最適です。ただし、dllの場合、それらは多くの場合、stdライブラリコンテナの内部構造/コードに影響する可能性のある異なるコンパイラ設定で構築されます。たとえば、MSVCでは、1つのdllがイテレータデバッグをオンにしてビルドされ、別のdllがオフでビルドされます。これらの2つのdllは、stdコンテナーを渡す問題に遭遇する可能性があります。std::stringインターフェイスで公開すると、クライアントが使用しているコードがstd::stringライブラリのに完全に一致することを保証できませんstd::string。 これにより、デバッグや頭痛などの問題が発生しやすくなります。組織内のコンパイラ設定を厳密に制御してこれらの問題を防ぐか、これらの問題のない単純なCインターフェイスを使用します。または、クライアントが使用するはずの予想されるコンパイラ設定を指定します（別のライブラリが他のコンパイラ設定を指定する場合、これは問題になります）。 私の質問は、C ++ 11がこれらの問題を解決するために何かを試みたかどうかです。

34 c++  libraries  c++11 

意見が必要です。GCCは常に非常に優れたコンパイラーでしたが、最近では「魅力」を失いつつあります。私は、Windows GCCにはstd::threadサポートがなく、Windowsユーザーが別のコンパイラーを使用することを強いられていることがわかりました。なぜなら、最もエキサイティングな機能がまだ欠けているからです。 しかし、WindowsでGCCがまだスレッドをサポートしていないのはなぜですか？ライセンスの問題？ABIの非互換性 （まあ、マルチスレッドを使用するクロスプラットフォームライブラリが既にいくつかあります：boost、POCO、SDL、wxwidgetsなど。GCCリリースを出荷する代わりに、既存のMIT / libpngライセンスのコードをこのホールに合うように使用するのは簡単ではないでしょうかスレッドのサポートなし？） 最近、コンパイラの比較を見ると、GCCは他のコンパイラに比べてC ++ 11の機能を最も幅広くサポートしていますが、Windowsではアトミック、ミューテックス、スレッドがまだないため、これは真実ではありません。 このトピックについてもっと知りたいのですが、私が見つけることができる唯一のことは、次の理由で助けを求める人々です： 「スレッド」はstd名前空間に存在しません GCC / TDM-GCCのチケットトラッキングとメールディスカッションを見ると、2009年からスレッドサポートのリクエストがありました。本当に何が起こっているのですか？

31 c++11  support  multithreading  gcc 

現在、C ++コードでGoogle C ++スタイルガイドを使用していますが、非常に満足しています。 最近、このガイドは非常に悪いと言われました。Googleが内部で使用していることは知っていましたが、時代遅れであり、非常に悪い習慣を助長しています。そこで、別のコーディングスタイルを使用したいと思います。 どのような優れた、かなり使用されているC ++スタイルガイドがありますか？私はgccとVisual Studioの両方のコードを記述し、多くのC ++ 11機能を使用しています。 Google C ++ Style Guideで非常に気に入ったのは、インデント、空白、および命名規則（特に、すべてのクラス、タイプ-typedef、タイプエイリアス、テンプレートエイリアスを含む-最初の文字が大文字）です。 私は答えが主観的であることを知っており（このサイトでこれがOKであることを願っています）、どんな意見も感謝しますが、最近使用されているガイドは興味があります。

29 c++  coding-style  c++11 

私はCとC ++のプログラマーですが、どちらの言語にも固執せず、2つの混合物を作成します。場合によっては、演算子のオーバーロードやテンプレートを使用したクラス内のコードを使用することもありますが、非常に優れたSTLは明らかに優れた方法です。単純なC関数ポインターを使用すると、はるかに読みやすく、明確になる場合があります。だから、私は両方の言語に美しさと実用性を見出しています。「それらを混ぜてC ++コンパイラでコンパイルすれば、それはもはや混同ではなく、すべてC ++である」という議論には入りたくありません。また、C対C ++については説明しません。この質問はすべてC ++ 11についてです。 C ++ 11では、C ++の動作に大きな変化があると思うものを紹介していますが、さまざまな機能が異なる状況でどのように動作するかを変更する多くの特殊なケース、例外、不規則性を導入し、多重継承、キーワードとして機能する識別子、拡張機能を制限しています文字列リテラル、ラムダ関数変数のキャプチャなど 将来のある時点で、C ++と言うとき、誰もがC ++ 11を想定することを知っています。最近Cを言うときと同じように、おそらくC99を意味します。そのため、C ++ 11の学習を検討します。結局、C ++でコードを書き続けたい場合、同僚が持っているという理由だけで、これらの機能の使用を開始する必要があるかもしれません。 Cを例にとります。何年も経った今でも、Cでコードを学んだり書いたりする人がたくさんいます。なぜですか？言語が良いからです。良い意味は、優れたプログラミング言語を作成するための多くの規則に従っていることです。そのため、Cは強力である（ほとんどすべてのプログラミング言語がそうであるか難しい）ことに加えて、Cは規則的であり、もしあれば例外はほとんどありません。しかし、C ++ 11はそうは思いません。C ++ 11で導入された変更によって言語が改善されているかどうかはわかりません。 質問は次のとおりです。なぜC ++ 11を学ぶのでしょうか。

28 learning  c++  c  c++11 

私は自分のコードのいくつかを-std=c++0xGCC のフラグでコンパイルしているところです。すべての若い人たちがやっていることを漠然と追いかけたいので（芝生にとどまっている場合）、警告がたくさん出ましたauto_ptr廃止されることについて。もちろん、私はそれauto_ptrがC ++ 0xで廃止されることを知っていましたが... 廃止は時間と労力の無駄ではありませんか？廃止されない理由（例としてauto_ptrを使用）： まだサポートが必要な大量のコードがあり、何百万もの警告を生成しても、警告をオフにしたくなるだけです。 auto_ptr 少しナッフですが、実際にはブリキに書かれていることを行います。 私たちが本当に物事を非難したいなら、私は指名しprintf()ます。しかし、その後に続く悲鳴を想像してください。auto_ptrあまりにも多くの友人はいませんが、少なくとも私のC ++コードではprintf、まったく使用されていないを超えて使用されています。 委員会はこれを正しく行ったという悪い記録を持っています-彼らは名前空間のスコープで静的を廃止し、今では廃止されていないようです- auto_ptr同様のカムバックをしても私は驚かないでしょう 最後に、委員会の言うことは何でも、コンパイラの実装者はそれらを無視します-彼らは単に彼らの顧客コードを壊す危険を冒すことができません、彼らができるすべては刺激的な警告を出すことです。 だから私の質問-（auto_ptrsだけでなく、C ++だけでなく）非推奨を良いアイデアと考えていますか？そうであれば、なぜですか？

27 c++  c++11  standardization