問題タブ [cstdint]

整数の<cstdint>のように、C ++にfloatの<cstdfloat>ヘッダーがないのはなぜですか？

編集 ：

<cstdfloat>とは、floatとdoubleのtypedefを提供するヘッダーを意味します。Qtのqrealtypedefによく似ています。私の質問が今はっきりしていることを願っています。

Boost の C99 stdint 実装は非常に便利です。ただし、1 つ気になることがあります。それらはすべての typedef を にダンプしboost namespaceます。この機能を使用する場合、次の 3 つの選択肢があります。

1. " using namespace boost"を使用
2. " using boost::[u]<type><width>_t"を使用
3. boost::プレフィックスを使用してターゲット タイプを明示的に参照します。例えば、boost::uint32_t foo = 0;

• オプション № 1 の種類は、名前空間のポイントを無効にします。ローカル スコープ内 (たとえば、関数内) で使用された場合でも、関数の引数のようなものは、オプション 3 のようにプレフィックスを付ける必要があります。
• オプション 2 の方が優れていますが、これらのタイプが多数あるため、ノイズが発生する可能性があります。
• オプション 3 は極端なレベルのノイズを追加します。多くの場合、boost::プレフィックスは問題の型の長さ以上です。

私の質問は、これらすべての型をグローバル名前空間に持ち込む最もエレガントな方法は何でしょうか? オプション № 2 を使用するラッパーを作成して、それで終了する必要がboost/cstdint.hppありますか?

また、ヘッダーを次のようにラップしても、VC++ 10 では機能しませんでした (標準ライブラリ ヘッダーの問題)。

編集:別のオプションは、プリプロセッサを使用してVC 10で動作させることだと思いますか? 上記のスニペットを取る：

仕事が減ったと思いますか？

バックグラウンド：

私はテンプレート ストリーム演算子 (例: ) を持っています (これは、8 ビット整数型 (例: など)でoperator << (ostream &, std::vector <T>)ある可能性があるコンテナー要素を出力します)。unsigned charint_least8_t

問題：

デフォルトでは、これらのタイプはchar(ASCII) として出力されます。私はASCII変数にのみchar（wchar_tまたは何でも）使用し、符号なし/符号付きタイプは決して使用しませんでした。呼び出し元が型を知らない場合でも、これらの他の 8 ビット型を常にsigned int/ (数値) として出力するにはどうすればよいですか?unsigned int

最初の試行:

たとえばoperator << (ostream &, unsigned char)、キャストを使用して定義しようとしました（GCCを使用）（つまり、値に対してはstream << static_cast <int> (value)機能しますが、出力は.unsigned charuint8_tchar

同じ基になる型 (つまりunsigned/signed char、オーバーロードでは使用できないため、たとえばoperator << (ostream &, int_fast8_t).

C++ の型の特性を使用しているときに奇妙な動作を経験しましたが、問題をこの風変わりな小さな問題に絞り込みました。誤解を招く可能性があるため、これについて多くの説明を行います。

次のようなプログラムがあるとします。

GCC (および 32 ビットと 64 ビットの MSVC) を使用した 32 ビット コンパイルの両方で、プログラムの出力は次のようになります。

ただし、64 ビット GCC コンパイルの結果のプログラムは次のように出力されます。

long long intは符号付き 64 ビット整数であり、すべての意図と目的でlong intとint64_t型と同一であるため、論理的にint64_tはlong intとは同等の型になるため、これは興味深いlong long intことです。これらの型を使用するときに生成されるアセンブリは同一です。一見すると、そのstdint.h理由がわかります：

64 ビット コンパイルでint64_tは、 islong intであり、long long int(明らかに) ではありません。

この状況の修正は非常に簡単です。

しかし、これはひどくハックであり、うまくスケーリングできません (実体の実際の機能uint64_tなど)。 だから私の質問は次のとおりlong long intです。コンパイラに aも aint64_tであることを伝える方法はありlong intますか?

私の最初の考えでは、C/C++ の型定義が機能する方法のために、これは不可能であるということです。基本的なデータ型の型等価性をコンパイラに指定する方法はありません。これはコンパイラの仕事であり (そして、それを許可すると多くのことが壊れる可能性があります)、一方向にしか進まないためtypedefです。

また、ここで回答を得ることにもあまり関心がありません。これは非常に極端なエッジ ケースであり、例がひどく不自然である場合に誰も気にしないと思われるからです (つまり、これはコミュニティ wiki であるべきということですか?)。 .

追加: 次のような簡単な例ではなく、部分的なテンプレートの特殊化を使用している理由:

long long intは暗黙的に に変換可能であるため、上記の例は引き続きコンパイルされint64_tます。

追加: これまでの唯一の答えは、型が 64 ビットかどうかを知りたいという前提です。私はそれを気にかけていると人々に誤解させたくなかったので、おそらくこの問題がどこで現れるかについてもっと多くの例を提供するべきでした.

この例でsome_type_trait<long int>は、 になりますが、そうboost::true_typeでsome_type_trait<long long int>はありません。これは C++ の型の考え方では理にかなっていますが、望ましくありません。

別の例では、次のような修飾子same_typeを使用しています (C++0x の概念で使用するのはかなり一般的です)。

C++ は型が異なることを (正しく) 認識するため、この例はコンパイルに失敗します。g++ は次のようなエラーでコンパイルに失敗します: no matching function call same_type(long int&, long long int&)。

なぜこれが起こっているのかを理解していることを強調したいと思いますが、コードをあちこちに繰り返さなくても済む回避策を探しています。

内部で typedef を使用するかどうかを検討して<cstdint>います。

私は個人的に何度も何度も書くことuint32_tをunsigned int好みます...私にとってははるかに直感的だからです。int8_tchar

皆さんはどう思いますか？typedef を使用することは良い考え <cstdint>ですか? デメリットはありますか？

独自のメモリ マネージャーを書き始めたばかりですが、そのためには、f32(float integer) を作成するための何らかの種類のインクルード ファイルが必要です。

私はすでに自分のプログラムに持っていますが、 、またはその#include <cstdint>ために何が必要なのかわかりません。F32I32

今日、私はcstdintヘッダーファイルで定義されたいくつかのタイプを試していました: std::uint16_tなどstd::uint_least16_t..

、 などのより一般的なプラットフォーム固有のものとは異なり、サイズが正確に、または少なくともどれくらいかがわかるため、これらは非常に便利だとint思いunsigned intます。

このコードがあるとしましょう:

std::uint_fast16_t少なくとも 2 バイトであることがわかっています。

がちょうど 2 バイトの場合uint_fast16_t、このコードはオーバーフローのために警告を出します。しかし、私の場合uint_fast16_tは8バイトです（以前に確認しました）。

したがって、私の場合、このコードは正常にコンパイルおよび実行されますが、他のコードでは警告が表示されます。私たちのコードは移植性がありません。これは私にとっては間違っています。変数がそのデータを保持できる場合でも、コンパイラは少なくとも警告を表示するか、より大きな型を使用するように提案する必要があります。私は正しいですか？または、これらの型の目的を誤解しましたか?

これらのフラグを指定して g++ を使用してコードをコンパイルしました

-Wall -Werror -pedantic -std=c++0x

2007年に作成されたC++ソ​​フトウェアパッケージをコンパイルしようとすると、次のエラーが発生します。

error: ‘uint32_t’ does not name a type

これは、g++4.5.2を使用する64ビットUbuntuで発生しています。g++4.1.2を使用して64ビットCentOSで正常にコンパイルされます。

#include欠落しているまたはコンパイラフラグはありますか？または、またはtypedefに割り当てるuint32_tために使用する必要がsize_tありunsigned intますか？

stdint.hとの違いは何cstdintですか？

どちらもMSVC（Visual Studio 2010）とgcc-4.5.1で利用できます。また、両方ともintX_t/uintX_tタイプを定義します（ここXで、はタイプのバイト単位のサイズです）。

• 両方のヘッダーの論理的根拠が同じである場合（ポータブルタイプ）、どちらかを決定するためにどのような決定を行う必要がありますか？

はstdint.h名前空間なしで各タイプを定義し、cstdintタイプはstd名前空間にあります。

• std定義された型を名前空間に含める、または含めない理由はありますか？2つのヘッダーの違いは何ですか？

cstdintファイル拡張子がなく、cプレフィックスをstdint.h使用し、.h拡張子を使用します。

• このヘッダーの命名規則は何ですか？cプレフィックスは、これがCライブラリであることを示していますか？にファイル拡張子がないのには理由がありますcstdintか？

のようなコマンドでいくつかのプロジェクトを構築しようとしていますが、見つからないために失敗し続けています<cstdint>。プロジェクトは、インクルード パスの特定の行に到達するとビルドを試みます。具体的#include <cstdint>には、エラーがスローされます。

このファイルは私のホームパスにあるように見えますが、見つからないため、これは困惑しています。私はコンパイラとパスについてあまり知らないので、私の無知を許してください。

私のコンピューターと実行しようとしているものについての簡単な背景。これは MacBook Pro で、Xcode 4.6.2 を実行しています。私が構築しているフレームワークは Cinder フレームワークであり、エラーをスローしているファイルはCinder.h. どんな助けでも大歓迎です。ありがとうございました！