問題タブ [effective-c++]

For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.

0 投票する
2 に答える
266 参照

c++ - 関数のようなマクロと奇妙な振る舞い

私はEffectiveC++を読み始めましたが、項目2のある時点で、次のことが言及されています。

ここで、fを呼び出す前にaがインクリメントされる回数は、比較対象によって異なります。

確かに、で単純な印刷ステートメントを使用するfと、最初の呼び出しで7が印刷されますが、私は一生の間、その理由を理解できません。明らかな何かが欠けていますか?

0 投票する
5 に答える
712 参照

c++ - オブジェクト内部にハンドルを返さないようにする方法 - 項目 28 効果的な C++

有効な C++ の項目 28 は言うavoid returning "handles" to object internalsこの質問は、クラスの内部を誤って公開することを避けるために、カプセル化について考えることによって、コードを正確に設計する方法を示しています。

私の例にはデータ配列が含まれており、メモリは使用を避けたい問題であるためstd::vector(および Boost ライブラリ)。

ここで配列を使用すると、私のコードの非常に単純化されたバージョンになります。

constwith を使用しget_data()ても安全ではないことを理解しています。ベクトルを使用している場合は、上記の質問の例のようにコピーできますが、これを避けたいので、この潜在的に危険な状況を回避するためにクラスを設計する最善の方法を考えていましたか?

0 投票する
3 に答える
73259 参照

c++ - 効果的な C++ はまだ効果的ですか?

この投稿で見たことから、 Effective C++という本を読み始めることにしました。

しかし、C++11 によって多くの新機能が追加され、いくつかの優れたプラクティスが変更された現在、それが実際に良いアイデアであるかどうかはわかりません。C++11 の出現により、Effective C++ に含まれるアドバイスのいずれかが非推奨になりましたか? もしそうなら、どのトピックを避けるべきですか?

0 投票する
7 に答える
8026 参照

c++ - argc が定数でないのはなぜですか?

有効な C++項目 #3 に「可能な限り const を使用する」と記載されているように、「これらの「定数」パラメーターを作成しない理由」を考え始めますconst

argcの値がプログラムで変更されるシナリオはありますか?

0 投票する
5 に答える
1990 参照

c++ - メンバー初期化リストに std::array を入力します

次のコードは機能しますが、警告を回避したいと思います。

警告: 'fitness::vect_' はメンバー初期化リストで初期化する必要があります [-Weffc++]

g++ -Weffc++スイッチを指定してコンパイルすると、次のようになります。

警告を無視する必要がありますか? vect_コンストラクターの初期化リストを (型を変更せずに)埋める方法はありますか?

0 投票する
4 に答える
371 参照

c++ - C++ でローカル変数を返す (Effective C++、第 3 版のルール 21)

知られているように、C++ の関数からローカル変数を返すことは、スコープのために安全ではありません。Scott Meyers は、Effective C++ Third Edition の 101 ページの項目 21 でこの問題について述べています。

これも悪い習慣ではなく、この関数は安全ではありませんか?

UPD:説明してくれてありがとう。

0 投票する
4 に答える
2601 参照

c++ - 明示的に型を指定するよりも、「明示的に型指定されたイニシャライザー」イディオムを優先する必要があるのはなぜですか?

私は最近 Scott Meyers から新しいEffective modern C++ を購入し、今それを読んでいます。しかし、私は完全に私を悩ませている 1 つのことに遭遇しました。

項目 5 で、Scott は使用することautoは素晴らしいことだと述べています。入力を節約し、ほとんどの場合に正しい型を提供し、型の不一致の影響を受けない可能性があります。私はこれを完全に理解してautoおり、良いことだとも考えています。

しかし、項目 6 で、スコットは、すべてのコインには 2 つの面があると述べています。auto同様に、たとえばプロキシ オブジェクトの場合など、 が完全に間違った型を推測する場合もあります。

次の例はすでにご存知かもしれません。

ここまでは順調ですね。

しかし、これに対するスコットの解決策は、いわゆる「明示的に型付けされた初期化子イディオム」です。アイデアは、次のように初期化子で static_cast を使用することです。

しかし、これはより多くの型付けにつながるだけでなく、推論されるべき型を明示的に述べることも意味します。基本的にauto、明示的な特定の型に対する両方の利点を失います。

なぜこのイディオムを使用するのが有利なのか、誰か教えてもらえますか?


最初に物事を明確にするために、私の質問は、なぜ私が書くべきかを目的としています:

それ以外の:

@Sergey は、このトピックに関するGotWの素敵な記事へのリンクを提供してくれました。これは、私の質問に部分的に答えています。

ガイドライン: ローカル変数 auto x = type{ expr }; の宣言を検討してください。タイプに明示的にコミットしたい場合。コードが明示的に変換を要求していること、変数が初期化されることが保証されていること、および偶発的な暗黙的な縮小変換が許可されていないことを示すことは自己文書化されています。明示的な絞り込みが必要な場合にのみ、{ } の代わりに ( ) を使用してください。

これは基本的に関連する質問につながります。これらの4 つの選択肢のうち、どれを選択する必要がありますか?

ナンバーワンは今でも私のお気に入りです。入力が少なく、他の 3 つと同じくらい明確です。

保証された初期化に関するポイントは、実際には当てはまりません。変数を何らかの方法で初期化する前ではなく、変数を宣言しているためです。狭小化に関するもう 1 つの議論は、簡単なテストではうまくいきませんでした。