6 
const auto min = -std::numeric_limits<T>::max();
T x = min; // conversion from 'const int' to 'short', possible loss of data

Tはテンプレート引数でありshort、この場合はaです。単項マイナスは、明らかに汎整数拡張を実行します。

  • 単項マイナスが汎整数拡張を実行するのはなぜですか？
  • autoがに変更された場合T、警告は生成されませんが、intをshortに割り当てる必要があります。警告がないのはなぜですか（VSが派手である可能性があります）？
4

4 に答える 4

6

簡単な答え:(人々は英語について過度に衒学者になりたいので、今では長いですが、それは本質的に正確ではありません）。

明示的にではありません（単項マイナスのようにmathematical）。ただし、operationPODデータに対する操作（単項マイナスを含む）の一部として、入力パラメーター（で使用できる最小の整数型であり、操作はint）に対する暗黙のチェックがあるため、単項マイナス（mathematical操作部分ではない部分）。PODに対するすべての操作の出力は、入力パラメーターと同じです（汎整数拡張が適用された後）。したがって、ここでの出力もintです。

長い答え：

C（したがってC ++）では、POD操作が発生する最小の型はですint。したがって、単項マイナスが適用される前に、値はintに変換されます。次に、単項マイナスが適用されます。したがって、式の結果はintです。

ここを参照してください：C++演算子の暗黙的な型変換ルール

于 2012-08-02T20:37:56.780 に答える
3

単項マイナスは、整数型のすべての算術演算子が実行するため、整数拡張を実行します。この規則は、おそらくパフォーマンス上の理由（通常、intはハードウェアでの整数演算に最適なサイズでした）と、より小さな整数型の範囲に限定されないことが有用な場合があるために確立されました。

私は人々がするバグを見てきました：

uint64_t i = 1 << 33; // use 64-bit type to ensure enough bits to hold the result

しかし、結果は1 << 33割り当てられたものに依存しないため、これはバグです。（今日、これについて警告があります）。醜い解決策は、オペランドの1つを手動で十分に大きくすることです。uint64_t i = static_cast<uint64_t>(1) << 33

汎整数拡張は、Cがこのように設計されたときに一般的なケースであった、より小さなタイプの同じ種類のバグを回避するために発生します。

short a = 30000, b = 20000
int i = a + b;

いずれにせよ、「それは論理的である必要はありません。それは法律です。」

于 2012-08-02T22:53:04.243 に答える
0

これは、C /C++が想定している理想的なコンピューターモデルを説明するためだと思います。計算はレジスタで実行され、結果のサイズがマシンワードになることを意味します。したがって、「自動」拡張

于 2012-08-02T20:22:11.167 に答える
0

の負の数は。shortとして表現できない可能性があるため、（部分的に）そうだと思いますshort。
（-2 15は、16ビットでそれより大きいint場合に昇格する必要がある場合があります。）shortint

もちろん、これ以上大きいという保証はありませんが、とにかく（通常は？）マシンに最適なデータ型であるため、パフォーマンスコストが発生しない可能性があるため、int昇格してみるのは理にかなっています。int

于 2012-08-02T20:41:25.453 に答える