問題タブ [c++14]

このC++1yコード ( LIVE EXAMPLE ) を考えてみましょう:

コンパイラ (GCC 4.8.1) は、寛大にも次のエラーを出します。

main.cpp: 関数 'int main()' 内:
main.cpp:8:18: エラー: 'auto' の推定前に 'auto foo()' を使用<br> std::cout << foo();
                   ^

ここで前方宣言するにはどうすればよいfoo()ですか? または、より適切に、前方宣言することは可能foo()ですか?

foo()また、ファイルで宣言しようとしたコードをコンパイルして、上記のファイルと同じよう.hに定義し、 と への呼び出しを含むファイルに含め、それらをビルドしました。foo().cpp.hmain.cppint main()foo()

同じエラーが発生しました。

Quad-/octree データ構造があります。セルの子インデックス/ptrsを配列に格納しています。配列内の各位置は、親に対する子の位置を表します (例: 2D):

Integer子の最大数は、型が表現できる値のサブセットであることを知っています。-1したがって、 forInteger = intやstd::numeric_limits<unsigned>::max()forのような「魔法の」値を使用して、セルに子がないかどうかを識別できますInteger = unsigned。これはstd::optional<Integer>想定できないことです。

私が理解している限りでは、この魔法の値の使用は の存在理由の 1 つですstd::optional。std::vector<std::optional<int>>それでも、 in inner loops の性能が気になります。

そう、

• のパフォーマンスは のパフォーマンスstd::vector<std::optional<int>>より悪くなりstd::vector<int>ますか? （私はすでに「存在しない」値の比較を行っています）。

• std::optionalまたは、 raw と同じパフォーマンスを提供するようにの実装を最適化できintますか? そしてどうやって？

関数の戻り値の型とマジック値をデータ構造に混在std::optionalさせるのは、非常に悪い考えのように思えます。私は一貫性を保ち、どちらか一方を (少なくとも同じコンテキスト内で) 使用することを好みます。マジック ナンバーとの比較を実行する関数をオーバーロードすることはできますが、次のようにします。

オプションタイプの場合。

ドラフト C++14 には、実行時サイズの配列とstd::dynarrayコンテナーの両方が含まれています。私が知る限り、この 2 つの違いは、ランタイム サイズの配列にはありませんが、STL インターフェイス (たとえば、、、、など) があることだけstd::dynarrayですbegin。では、なぜ C++14 は両方を必要とするのでしょうか?endsize

実行時サイズの配列はコア言語のstd::dynarray一部であり、標準ライブラリの一部であることは理解していますが、 の提案はstd::dynarray、多くの場合、コンパイラがstd::dynarray効率的になるように特別なサポートを提供することを著者が期待していることを明確にしています。つまり、実行時サイズの配列と同じくらい効率的です。そのため、言語とライブラリの区別はやや不自然に思えます。

繰り返しになりますが、なぜ C++14 は実行時サイズの配列と の両方を必要とするのstd::dynarrayでしょうか? よりリッチな (STL 化された) インターフェースを備えていることを考えると、同等のランタイム効率で実装できるとstd::dynarray仮定して、なぜランタイム サイズの配列をドロップしないのでしょうか?std::dynarray

明確化

「ランタイム サイズの配列」について話すとき、N3639で説明されている新しい C++14 コア言語機能について言及していて、従来の C 配列や VLA、または C++11 の何かについて言及しているのではありません。

C++11 では、次のようなエイリアス テンプレートが追加されました。

これらは、型引数がローカル コンテキストに依存している場合でも、結果が型であることをコンパイラに通知する必要がないためtemplate、フィールドに戻り値を与える古い型マップよりもはるかに使いやすいです。::type

typename実際には、使用場所からusingエイリアスに を巻き上げます。

template生成された余分なsを取り除くために使用できる同等のものはありますか?

出力が型ではなくクラスまたはエイリアス テンプレートであるメタ関数があるとします。現在の方法は次のようなものです。

これを次のように使用できます。

メタ関数の戻り値を明確にするために戻り値の型に存在する余分なtemplateキーワードは、私が排除したいものです。

template呼び出しの場所でキーワードを使用せずに、メタ計算の結果が C++11 または C++1y の別のエイリアスまたはクラス テンプレートであることをコンパイラに示す方法はありますか?

すなわち:

あるいは

エラー処理のためにから継承されたクラスを使用しており、が呼び出されたstd::system_errorときに何が返されるかを制御したいと考えています。what()理由: 標準 (C++11 とドラフト C++1y CD - N3690 の両方、§ 以下の参照は後者です) は、によって返される文字列がどのwhat()ように見えるかを正確に指定していません。 .6.2 (14):

注: 返された NTBS は、what_arg + ": " + code.message(). — エンドノート

したがって、実装依存と見なされます。（ちなみに、code().message()代わりにすべきではありませんcode.message()か？）

what()したがって、問題は次のとおりです。標準に準拠し、実装に依存したくない場合 (つまり、移植可能にしたい場合) に返される文字列を正確に定義するにはどうすればよいでしょうか?

コードを好む人のために：

わかりました、私が好きではない簡単な解決策は次のとおりです。

仮想なのでstd::exception::what()機能しますが、実装の詳細を使用せずにもっとエレガントな方法はありますか? 2 つの文字列を格納するという考えは好きではありませstd::system_errorんmy_what。

問題の根源: std::runtime_error — たまたま std::system_error の親クラス — には、コンストラクターの事後条件である §1.9.2.6 (3) に正確な要件があります。

の場合はstd::system_error、§19.5.6.2 (2) で次のようになります。

code().message()標準が に含めようとするのがなぜそんなに難しいのか、誰にも手がかりがありますwhat()か? code()はエラー コード オブジェクトを返すので、誰でもcode().message()いつでも (このクラスの例外がキャッチされたときでも) 文字列に含めることができます。

の要件が の要件とstd::system_error同じである場合、次のstd::runtime_errorように書くことができます。

エレガントでポータブルなソリューションはありますか?

更新: 以下のコメントの多くは、エラー メッセージが実装定義であると述べています。によって返される文字列をフォーマットしたいだけでwhat()、すべてのシステムでバイトごとに同等にしたくないことを理解しています。ログに記録するか、サードパーティに渡したいと考えてみてください。一定の形式に従う必要があります（これは標準で提案されているものではありません）。

UPDATE2: std::system_error は OS または STL エラーだけではないと思います。そこから独自のクラスを派生させて、エラー報告に使用することができます (そしてそうすると思います)。低レベルの API を書いている場合はどうなりますか? ところで、高レベル API での使用が禁止されているのはなぜですか?

API のエラー処理部分ですべての引数をコンストラクターに渡すと、実装で定義された (つまり不明な) エラー文字列は含まれませんが、データを複製せずにフォーマットすることはできません。