C ++ 11のautoキーワードでは多すぎますか？

私はauto、C ++ 11標準で利用できる新しいキーワードを、それが設計されたと考えている複雑なテンプレート型に対して使用しています。しかし、私はそれを次のものにも使用しています：

auto foo = std::make_shared<Foo>();

そしてもっと懐疑的に：

auto foo = bla(); // where bla() return a shared_ptr<Foo>

私はこのトピックについてあまり議論していません。と思われるautoタイプは、多くの場合、文書化と健全性チェックの形であることから、過剰に使用することができます。使用の際にどこに線を引くautoか、この新機能の推奨される使用例は何ですか？

明確にするために、私は哲学的な意見を求めているのではありません。標準的な委員会によるこのキーワードの意図された使用をお願いします。おそらく、その意図された使用が実際にどのように実現されるかについてのコメントが必要です。

補足：この質問は、SE.Programmersに移動され、Stack Overflowに戻されました。これに関する議論は、このメタ質問にあります。

auto型の書き方が一目でわかりにくいときはキーワードを使うべきだと思いますが、式の右辺の型は一目瞭然です。たとえば、次のように使用します。

my_multi_type::nth_index<2>::type::key_type::composite_key_type::
    key_extractor_tuple::tail_type::head_type::result_type

でboost::multi_indexあることがわかっている場合でも、で複合キータイプを取得しますint。int将来変更される可能性があるので、単に書くことはできません。autoこの場合、私は書きます。

したがってauto、特定のケースでキーワードが読みやすさを向上させる場合は、それを使用します。auto型が何をauto表しているかが読者に明らかな場合は、書くことができます。

ここではいくつかの例を示します。

auto foo = std::make_shared<Foo>();   // obvious
auto foo = bla();                     // unclear. don't know which type `foo` has

const size_t max_size = 100;
for ( auto x = max_size; x > 0; --x ) // unclear. could lead to the errors
                                      // since max_size is unsigned

std::vector<some_class> v;
for ( auto it = v.begin(); it != v.end(); ++it )
                                      // ok, since I know that `it` has an iterator type
                                      // (don't really care which one in this context)

可能な限りautoあらゆる場所で使用します。特にconst auto、副作用の心配が少ないように使用します。明らかな場合を除いて型について心配する必要はありませんが、静的に検証されるため、繰り返しを避けることができます。auto実行不可能な場合は、を使用decltypeして、式に基づくコントラクトとして型を意味的に表現できます。あなたのコードは異なって見えますが、それは前向きな変更になります。

簡単です。タイプを気にしない場合に使用します。例えば

for (const auto & i : some_container) {
   ...

ここで私が気にするiのは、コンテナに何があるかということだけです。

typedefに少し似ています。

typedef float Height;
typedef double Weight;
//....
Height h;
Weight w;

ここではh、wがfloatかdouble かは関係ありません。高さと重さを表現するのに適したタイプであることだけが重要です。

または検討する

for (auto i = some_container .begin (); ...

ここで私が気にしているのは、それが適切なイテレータであり、サポートoperator++()しているということだけです。

また、ラムダのタイプはスペルできないので、auto f = []...良いスタイルです。代わりの方法はキャストstd::functionですが、オーバーヘッドが伴います。

の「乱用」は本当に想像できませんauto。私が想像できる最も近いものは、いくつかの重要な型への明示的な変換をあなた自身から奪うことです-しかし、あなたはそれを使用autoしないでしょう、あなたは望ましい型のオブジェクトを構築するでしょう。

あなたがいる場合することができ、副作用を導入することなく、あなたのコード内のいくつかの冗長性を削除し、しなければならない、そうすることは良いこと。

反例（他人の回答から借用）：

auto i = SomeClass();
for (auto x = make_unsigned (y); ...)

ここではタイプを気にしますのでSomeclass i;、for(unsigned x = y;...

頑張れ。autoコードを簡単に記述できる場所ならどこでも使用できます。

任意の言語のすべての新機能は、少なくとも一部のタイプのプログラマーによって過剰に使用されます。一部の経験豊富なプログラマー（初心者ではない）が適度に使いすぎた場合のみ、残りの経験豊富なプログラマーが適切な使用の境界を学習します。極端な過度の使用は通常悪いことですが、そのような過度の使用は機能の改善またはそれを置き換えるより良い機能につながる可能性があるため、良いかもしれません。

しかし、私が数行以上のコードで作業していた場合

auto foo = bla();

タイプがゼロ回示されている場合、それらの行を変更してタイプを含めることができます。最初の例は、型が一度記述されているので素晴らしいものであり、auto面倒なテンプレート型を2回記述する必要がなくなります。Hooray for C ++++。しかし、タイプをゼロ回明示的に示すと、近くの行で簡単に見られない場合、少なくともC ++とその直後のバージョンでは緊張します。抽象化、ポリモーフィズム、および汎用性を高めて、より高いレベルで機能するように設計された他の言語については、問題ありません。

で、C ++および2013年以降で掲載会社何かのパネルあったが、使用して、使用しないようにするときの話アンドレイアレキ、スコット・マイヤーズとハーブサッター間の素晴らしい交換がauto。25分の03にスキップして4分間のディスカッションを行います。3つのスピーカーすべてが、使用しない場合に留意すべき優れたポイントを提供しますauto。

私は人々に自分の結論に来ることを強く勧めますが、私のテイクアウトは次の場合を除いてどこでも使用autoすることでした：

1. 読みやすさを損なう
2. 自動型変換に関する懸念があります（例：コンストラクター、割り当て、テンプレート中間型、整数幅間の暗黙的な変換から）

の自由な使用はexplicit、後者に対する懸念を減らすのに役立ち、前者が問題となる時間を最小限に抑えるのに役立ちます。

「X、Y、およびZを実行していない場合は、を使用してautoください。X、Y、およびZが何であるかを学び、auto他のあらゆる場所で使用してください」とHerbが言ったことを言い換えます。

はい、読みやすくするために使いすぎることがあります。正確な型が長いか、発話できないか、読みやすさにとって重要ではなく、変数の有効期間が短いコンテキストで使用することをお勧めします。たとえば、イテレータタイプは通常長く、重要ではないのでauto機能します。

   for(auto i = container.begin(); i != container.end(); ++i);

auto ここでは読みやすさは損なわれません。

別の例は、パーサールールタイプです。これは、長く複雑な場合があります。比較：

   auto spaces = space & space & space;

と

r_and_t<r_and_t<r_char_t<char>&, r_char_t<char>&>, r_char_t<char>&> spaces = 
   space & space & space;

一方、型がわかっていて単純な場合は、明示的に記述した方がはるかに優れています。

int i = foo();

のではなく

auto i = foo();

auto は、EigenやOpenCVなどの線形代数ライブラリでよく使用される式テンプレートと組み合わせると非常に危険な場合があります。

auto A = Matrix(...);
auto B = Matrix(...);
auto C = A * B; // C is not a matrix. It is a matrix EXPRESSION.
cout << C; // The expression is evaluated and gives the expected result.
... // <code modifying A or B>
cout << C; // The expression is evaluated AGAIN and gives a DIFFERENT result.

このタイプのミスによって引き起こされるバグは、デバッグするのが非常に困難です。可能な解決策の1つは、左から右への宣言スタイルにautoを使用している場合、結果を期待される型に明示的にキャストすることです。

auto C = Matrix(A * B); // The expression is now evaluated immediately.

私はauto制限なしで使用し、何の問題もありませんでした。時々、のような単純なタイプにそれを使用することさえありintます。これにより、c ++は私にとってより高水準の言語になり、Pythonのようにc ++で変数を宣言できます。Pythonコードを書いた後、私は時々さえ書く

auto i = MyClass();

の代わりに

MyClass i;

これはautoキーワードの乱用と言えるケースの1つです。

多くの場合、私はそのfonctionalityでより多くの興味、および関数名は、一般的に、彼らが返すオブジェクトについて何かを言うように、オブジェクトの正確な型が何であるかを気にしないauto例には：悪くはないauto s = mycollection.size()、私はそれを推測することができますsになりますある種の整数で、正確な型が気になるまれなケースでは、関数のプロトタイプを確認してみましょう（つまり、コードを書くときにアプリオリではなく、情報が必要なときに確認する必要があります。のようにいつか役立つかもしれない場合に備えてint_type s = mycollection.size()。

受け入れられた答えからのこの例に関して：

for ( auto x = max_size; x > 0; --x )

autoこの場合も引き続き使用するコードで、x署名なしにしたい場合は、sayという名前のユーティリティ関数を使用しますmake_unsigned。これは、私の懸念を明確に表しています。

for ( auto x = make_unsigned(max_size); x > 0; --x )

免責事項：私は自分の使用法について説明しているだけです。

C ++プログラムの主な問題の1つは、初期化されていない変数を使用できることです。これは、不快な非決定論的なプログラム動作につながります。現在のコンパイラーは、プログラムが使用するのに疲れた場合、適切な/メッセージの警告メッセージをスローするようになりました。

これを説明するために、以下のc ++プログラムを検討してください。

int main() {
    int x;
    int y = 0;
    y += x;
}

このプログラムを最新のコンパイラ（GCC）を使用してコンパイルすると、警告が表示されます。実際の複雑なプロダクションコードで作業している場合、このような警告はあまり明白ではない場合があります。

main.cpp：関数 'int main（）'で：

main.cpp：4：8：警告：この関数では初期化されていない 'x'が使用されています[-Wuninitialized]

y + = x;

    ^

================================================== ===============================ここで、autoを使用するプログラムを変更した場合 、コンパイルすると次のようになります。

int main() {
    auto x;
    auto y = 0;
    y += x;
}

main.cpp：関数 'int main（）'で：

main.cpp：2：10：エラー： 'auto x'の宣言に初期化子がありません

 auto x;

      ^

autoでは、初期化されていない変数を使用することはできません。これは、autoの使用を開始した場合に（無料で）取得できる主要な利点です。

このコンセプトとその他のすばらしい最新のC ++コンセプトは、C ++のエキスパートであるハーブシャッターが彼のCppCon14講演で説明しています。

基本に戻ります！最新のC ++スタイルの要点

私が指摘した1つの危険は、参照に関してです。例えば

MyBigObject& ref_to_big_object= big_object;
auto another_ref = ref_to_big_object; // ?

問題は、another_refが実際には参照ではなく、MyBigObject＆ではなくMyBigObjectであることです。大きなオブジェクトを気付かずにコピーしてしまいます。

メソッドから直接参照を取得している場合は、それが実際に何であるかを考えていない可能性があります。

auto another_ref = function_returning_ref_to_big_object();

「auto＆」または「const auto＆」が必要になります

MyBigObject& ref_to_big_object= big_object;
auto& another_ref = ref_to_big_object;
const auto& yet_another_ref = function_returning_ref_to_big_object();

auto型が推論されるのが理にかなっている場所で使用します。整数であることがわかっている場合、または文字列であることがわかっている場合は、int / std :: stringなどを使用してください。ばかばかしいところに到達しない限り、言語機能を「使いすぎ」ても心配しません。またはコードを難読化します。

それはとにかく私の意見です。

autoキーワードはローカル変数にのみ使用でき、引数やクラス/構造体のメンバーには使用できません。そのため、どこでも好きな場所で使用することが安全で実行可能です。よく使います。タイプはコンパイル時に推定され、デバッガーはデバッグ中にタイプを表示し、sizeofそれを正しく報告し、decltype正しいタイプを提供します-害はありません。auto使いすぎだとは思わない！

TL; DR：下部の経験則を参照してください。

受け入れ答えは、親指の次のルールを提案しています：

使用autoそれは一見のタイプを作成する方法を言うのは難しいですが、式の右辺の型が明らかであるときはいつでも。

しかし、それは制限が多すぎると思います。時々私はタイプについて気にしません。ステートメントがタイプを理解するために時間を費やすことをせずに十分に有益であるためです。それはどういう意味ですか？いくつかの答えに現れた例を考えてみましょう：

auto x = f();

これを誤用の例にするもの autoますか？f()の戻り値の型を知らないのですか？まあ、私がそれを知っていれば確かに役立つかもしれませんが、それは私の主な関心事ではありません。問題の多くはそれでxありf()、かなり意味がありません。私たちが持っていた場合：

auto nugget = mine_gold();

その代わり、私は通常、関数の戻り値の型が明白であるかどうかを気にしません。ステートメントを読んで、私は自分のしていることを理解しています。また、戻り値のセマンティクスについて、そのタイプも知る必要がないと感じないようにするために十分な知識があります。

だから私の答えは：autoコンパイラが許可するときはいつでも使用します：

• 変数名と初期化/割り当て式では、ステートメントの実行内容に関する十分な情報が得られないと感じています。
• 変数名を初期化/割り当て式と組み合わせて、型がどうあるべきかについて「誤解を招く」情報を提供していると感じます-つまり、autoの代わりに何が来るかを推測しなければならない場合、推測することができます-そしてそれは間違っており、この誤った仮定はコードの後半で影響を及ぼします。
• 別のタイプ（参照など）を強制したい。

そしてまた：

• auto具体的な型に置き換える前に、意味のある名前（もちろん型名を含まない）を付けることをお勧めします。

私の苦い経験の一つautoれるラムダ式でそれを使用しました：

auto i = []() { return 0; };
cout<<"i = "<<i<<endl; // output: 1 !!!

実際、ここiはの関数ポインタに解決されますint(*)()。これは単純なものですがcout、一緒に使用するとどのようなコンパイル/ランタイムエラーが発生する可能性があるか想像してみてくださいtemplate。

あなたはそのような表現を避け autoて適切なreturnタイプを置くべきです（または制御されますdecltype()）

上記の例の正しい使い方は、

auto i = []() { return 0; }(); // and now i contains the result of calling the lambda