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

C ++ 11は、2011年に承認されたC ++標準の名前です。これは、以前のC ++ 03標準に置き換わり、さまざまなコア言語の変更と修正、および改良および拡張された標準ライブラリを追加します。

2
C ++関数constexprをマークするのは悪いことですか?
非常に簡単な関数を考えると、 int transform(int val) { return (val + 7) / 8; } この関数を関数に変換するconstexprことは簡単で、constexpr変数を定義するときに次のように使用できることは非常に明白です。 constexpr int transform(int val) { return (val + 7) / 8; } 私の想定では、これは厳密に改善されたものです。関数はconstexprコンテキスト以外でも呼び出すことができ、コンパイル時の定数変数の定義に使用できるようになったためです。 私の質問は、これが悪い考えである状況はありますか?たとえば、この関数を作成することによりconstexpr、特定の状況でこの関数が使用できなくなる状況や、誤動作する状況に遭遇することはありますか?
26 c++  c++11 

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

6
特にループで、新しいC ++ 11の「自動」機能を使用する必要がありますか?
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 

5
constが早すぎる最適化を参照するときに引数を渡しますか?
「時期尚早の最適化はすべての悪の根源です」 これは私たち全員が同意できると思います。そして、私はそれを避けるために一生懸命努力します。 しかし最近、私はValueではなくconst Referenceによってパラメーターを渡す方法について疑問に思っています。非自明な関数引数(つまり、ほとんどの非プリミティブ型)はconst参照で渡すことが望ましいことを教えられました。これまで読んだ本の中では、これを「ベストプラクティス」として推奨しているものがかなりあります。 それでも私は不思議に思わずにはいられません:現代のコンパイラーと新しい言語機能は驚異的に機能する可能性があるため、私が学んだ知識は非常に古くなっている可能性があり、 void fooByValue(SomeDataStruct data); そして void fooByReference(const SomeDataStruct& data); 私が学んだ慣習は-const参照を渡す(非自明な型のデフォルト)-早すぎる最適化ですか?

2
最新のC ++パラダイムの概要 [閉まっている]
閉まっている。この質問はトピック外です。現在、回答を受け付けていません。 この質問を改善したいですか? 質問を更新して、 Software Engineering Stack Exchangeのトピックになるようにします。 4年前に閉鎖されました。 私は8〜10年前にC ++を広範囲に記述していました。それ以来、専門的な理由でC#に移行しました。しかし、時々私は次のような声明を見ます 「まだポインタ参照を手動で追跡している場合は、間違っています」 または 「C ++は、RAIIのような最新のコンセプトを使用しており、回復中のC開発者のようにメモリを手動で割り当てない限り、完全に安全です。」 どちらも10年前の標準的な手順でした。最近、C ++がかなり改善されているのを見てきました。特にC ++ 0xには、いくつかの新しい機能があるようです。「C / old C ++」プログラマーが「最新」のC ++パターンとプラクティスに追いつくための最適なリソースは何ですか?

2
std :: bitsetよりもcスタイルのビット操作には利点がありますか?
私はほとんどC ++ 11/14でのみ動作しますが、通常、次のようなコードが表示されたときはうんざりします。 std::int64_t mArray; mArray |= someMask << 1; これは単なる例です。私は一般的にビット単位の操作について話しています。C ++では、本当にポイントがありますか?上記は心をゆがめ、エラーを起こしやすいですが、を使用すると次のstd::bitsetことができます: より簡単にサイズを変更します std::bitset必要に応じてテンプレートパラメータを調整し、実装に残りの処理を任せることで、ます。 何が起こっているかを考え出す(そして間違いを犯す可能性がある)時間を短縮std::bitsetし、同様の方法で、std::arrayまたは他のデータコンテナーに書き込みます。 私の質問は 下位互換性以外に、プリミティブ型を使用しない理由はありますstd::bitsetか?

2
一時的なものへの言及をベースに、この範囲を誰が責めるのでしょうか?
次のコードは一見無害に見えます。ユーザーはこの関数bar()を使用して、いくつかのライブラリ機能と対話します。(これはbar()、一時的でない値または同様のものへの参照を返したので、長い間働いていたかもしれません。)しかし、今では単にの新しいインスタンスを返していますB。B繰り返しa()処理可能な型のオブジェクトへの参照を返す関数がありますA。Bによって返される一時オブジェクトはbar()、反復が開始される前に破棄されるため、ユーザーはこのオブジェクトを照会すると、セグメンテーション違反につながります。 誰(ライブラリーまたはユーザー)がこれを責めるかは私は優柔不断です。すべてのライブラリが提供するクラスは私にはきれいに見えますが、確かに他の多くのコードとは何も違いはありません(メンバーへの参照を返す、スタックインスタンスを返すなど)。ユーザーは何も悪いことをしていないように見えます。彼は、オブジェクトの存続期間に関して何もせずにオブジェクトを繰り返し処理しているだけです。 (関連する質問は次のとおりです:ループヘッダー内の複数のチェーンされた呼び出しによって取得されるものに対してコードが「範囲ベースの反復」ではないという一般的なルールを確立する必要があります。右辺値?) #include <algorithm> #include <iostream> // "Library code" struct A { A(): v{0,1,2} { std::cout << "A()" << std::endl; } ~A() { std::cout << "~A()" << std::endl; } int * begin() { return &v[0]; } int * end() { return &v[3]; } int v[3]; }; struct B { …
15 c++11 

6
フレンドクラスを使用したC ++の単体テストプライベートメソッド
これは議論の余地があることを知っていますが、これが私にとって最良の選択肢であると仮定しましょう。私はこれを行うための実際のテクニックは何なのかと思っています。私が見るアプローチはこれです: 1)テストするメソッドのクラスのフレンドクラスを作成します。 2)friendクラスで、テストされたクラスのプライベートメソッドを呼び出すパブリックメソッドを作成します。 3)friendクラスのパブリックメソッドをテストします。 上記の手順を説明する簡単な例を次に示します。 #include <iostream> class MyClass { friend class MyFriend; // Step 1 private: int plus_two(int a) { return a + 2; } }; class MyFriend { public: MyFriend(MyClass *mc_ptr_1) { MyClass *mc_ptr = mc_ptr_1; } int plus_two(int a) // Step 2 { return mc_ptr->plus_two(a); } private: …

1
汎用C ++ラッパーを使用してRustの所有権モデルを実現できますか?
Rustの並行処理の安全性に関するこの記事をご覧ください。 http://blog.rust-lang.org/2015/04/10/Fearless-Concurrency.html これらのアイデアのどれだけがC ++ 11(またはそれ以降)で達成できるのかと思っていました。特に、所有権を渡すメソッドに所有権を譲渡する所有者クラスを作成できますか?C ++には変数を渡す方法がたくさんあるので不可能だと思われますが、クラスまたはテンプレートにいくつかの制限を設けて、メソッドのパスごとにテンプレートコードが実行されるようにすることができますか?

2
これは良いパターンですか?長い関数を一連のラムダに置き換えますか?
最近、次のような状況に遭遇しました。 class A{ public: void calculate(T inputs); } まず、A物理世界のオブジェクトを表します。これは、クラスを分割しないことの強力な議論です。今、calculate()非常に長く複雑な機能であることが判明しました。私は3つの可能な構造を知覚します: テキストの壁としてそれを書く-利点-すべての情報が一箇所にある privateクラスでユーティリティ関数を記述し、それらをcalculateボディで使用する-欠点-クラスの残りの部分は、これらのメソッドを知らない/気遣わない/理解しない calculate次のように書きます: void A::calculate(T inputs){ auto lambda1 = () [] {}; auto lambda2 = () [] {}; auto lambda3 = () [] {}; lambda1(inputs.first_logical_chunk); lambda2(inputs.second_logical_chunk); lambda3(inputs.third_logical_chunk); } これは良いプラクティスか悪いプラクティスか?このアプローチは問題を明らかにしますか?全体として、再び同じ状況に直面したとき、これを良いアプローチと考えるべきですか? 編集: class A{ ... public: // Reconfiguration of the algorithm. void set_colour(double …
14 c++11  lambda 

1
オブジェクトライフタイム不変式と移動セマンティクス
ずっと前に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 …

1
高次リスト関数のC ++ 11サポート
などなど、ほとんどの関数型プログラミング言語(例えばCommon Lispの、スキーム/ラケット、Clojureの、ハスケル、スカラ座、OCamlで、SML)リスト上のいくつかの一般的な高階関数をサポートするには、map、filter、takeWhile、dropWhile、foldl、foldr(例えば参照、Common Lispの、スキーム/ラケットをClojureの並列リファレンスシート、Haskell、Scala、OCaml、およびSMLドキュメント。 C ++ 11には、リストに同等の標準メソッドまたは関数がありますか?たとえば、次のHaskellスニペットを考えます。 let xs = [1, 2, 3, 4, 5] let ys = map (\x -> x * x) xs 最新の標準C ++で2番目の式をどのように表現できますか? std::list<int> xs = ... // Initialize the list in some way. std::list<int> ys = ??? // How to translate the Haskell expression? 上記の他の高階関数はどうですか? C …

2
C ++ 11でauto_ptrの廃止の設計変更を処理する方法は?
C ++ 11(つまり-std=c++11)でライブラリをテストしています。ライブラリはauto_ptr次のパターンを使用します: Foo* GetFoo() { autoptr<Foo> ptr(new Foo); // Initialize Foo ptr->Initialize(...); // Now configure remaining attributes ptr->SomeSetting(...); return ptr.release(); } C ++ 11は非推奨auto_ptrになったため、それから離れたいと思います。 ただし、コードはC ++ 03とC ++ 11の両方をサポートしているため、ヤンクするほど単純ではありませんauto_ptr。また、ライブラリに外部依存関係がないことにも言及する価値があります。C ++ 03を使用します。Autotools、Cmake、Boostなどを使用しません... auto_ptrC ++ 03との互換性を維持しながら、C ++ 11 から移行するための設計変更をどのように処理する必要がありますか?
12 design  c++  c++11 

3
C ++ 11との前方互換性の実現
私は、いくつかのプラットフォームで実行する必要がある大規模なソフトウェアアプリケーションで作業しています。これらのプラットフォームの一部は、C ++ 11の一部の機能(MSVS 2010など)をサポートしていますが、一部のプラットフォームはサポートしていません(GCC 4.3.xなど)。私はこの状況が数年間続くと予想しています(私の推測では3〜5年)。 そのため、最小限の保守で古いコンパイラでコンパイルできるC ++ 11コードを(可能な限り)作成できるように、互換性インターフェイスを設定したいと思います。全体として、目標は#ifdefを合理的に可能な限り最小化すると同時に、それらをサポートするプラットフォームで基本的なC ++ 11構文/機能を有効にし、サポートしないプラットフォームでエミュレーションを提供することです。 std :: move()から始めましょう。互換性を実現する最も明白な方法は、次のようなものを共通のヘッダーファイルに入れることです。 #if !defined(HAS_STD_MOVE) namespace std { // C++11 emulation template <typename T> inline T& move(T& v) { return v; } template <typename T> inline const T& move(const T& v) { return v; } } #endif // !defined(HAS_STD_MOVE) これにより、人々は次のようなことを書くことができます …
12 c++  c++11 

2
コンパイル済みのC ++ 11ライブラリ(lib、dllなど)を古いC ++コンパイラにリンクできますか?
古いC ++コンパイラ(VS2008やgcc3.4など)は、C ++ 11で記述された外部ライブラリとリンクできますか? 私の考えでは、C ++ 11 .libファイルはこの段階では単なるバイトコードであり、何らかの方法で解決可能かつ呼び出し可能であれば、古いコンパイラの生成方法を気にするべきではありません。 私はAPIがまだC ++ 03ユーザーをサポートする小さなライブラリを開発しています。だから、楽しみにして、std::unique_ptrなどの便利な機能を使用してライブラリを実装しても大丈夫なのか、それとも固執する必要があるのboost::でしょうか?
12 c++  c++11 

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.