私の知る限り、これは実装のバグであると主張できると思います(または、実際には、C ++ 0xが公開されていないため、バグ自体ではなく、次の標準の現在の状態の不完全な実装です)。
予想される動作については、n3225を参照してください-std=c++0x
。
D.7は言う
それぞれがname.hという形式の名前を持つすべてのCヘッダーは、対応するcnameヘッダーによって標準ライブラリ名前空間に配置された各名前がグローバル名前空間スコープ内に配置されているかのように動作します。
OK、これまでのところ簡単です。<cstdint>
標準ライブラリの名前空間には何がありますか?
18.4.1:
typedef unsigned integer type uint64_t; // optional
どのようにオプションですか?18.4.1 / 2:
ヘッダーは、C標準の7.18と同じように、すべての関数、タイプ、およびマクロを定義します。
ドラト。C規格は何と言っていますか?n1256、7.18.1.1 / 3を取り出す:
これらのタイプはオプションです。ただし、実装が幅8、16、32、または64ビットの整数型を提供し、パディングビットがなく、(符号付き型の場合)2の補数表現を持つ場合、対応するtypedef名を定義する必要があります。
しかし、ちょっと待ってください。確かに、-std=c++0x
GCCを搭載したAndroidでは、パディングビットのない64ビットの符号なしタイプが提供さunsigned long long
れます。したがって<cstdint>
、提供する必要があるため、グローバル名前空間で提供する必要がstd::uint64_t
あります。stdint.h
uint64_t
続けて、誰かが私が間違っている理由を教えてくれます:-) 1つの可能性は、C++0xがバージョンを指定せずに「ISO/IEC9899:1999プログラミング言語—C」を参照していることです。(a)7.18.1.1 / 3がTCの1つに追加され、(b)C ++ 0xは、1999年以降の修正ではなく、1999年の時点で元の標準を参照する予定であるというのは本当ですか?どちらかが当てはまるかどうかは疑わしいですが、チェックする元のC99が手元になく(a)、チェック方法もわかりません(b)。
編集:ああ、どちらを使用すべきかについて-std=c++0x
は、まだ厳密な標準がないため、実際にはまだ厳密な標準準拠モードではありません。そして、標準があったとしても、gcc4.4.3は確かにそれの完成した実装ではありません。したがって、少なくともgccバージョンとプラットフォームの組み合わせに関しては、-std=gnu++0x
実際にはもっと完全であれば、それを使用する必要はあまりないと思います。
ただし、gnu++0x
他のGNU拡張機能が有効になり、コードで使用したくない場合があります。ポータブルC++0xを作成することを目的としている場合は、最終的にはに切り替えたいと思うでしょう-std=c++0x
。しかし、GCC4.4やその他の進行中のC++ 0x実装は、(ドラフト)標準からコードを書くのに実用的であるほど完全ではないと思います。 C ++ 0xをプログラミングしていますが、2011年だけです!」ですから、どちらが機能するかを使用し、現在使用しているものがどれであっても、いずれ-std=c++11
にせよ最終的には切り替える可能性があることを理解してください。