私は最近、C / C ++構造-structに精通しました。 主よ、はい、「彼らと知り合うことは何ですか」とあなたは言いますか？ したがって、あなたはすぐに2つの間違いを犯します。
第一に、私は主で
はありません。第二に、私はその構造も考えました。 しかし、結局のところ-いいえ。 一部の読者を1時間ごとのデバッグから救ういくつかの重要な詳細について説明します...
メモリ内のフィールドの配置
構造に注意してください：
struct Foo { char ch; int value; };
さて、まず第一に、メモリ内のこの構造のサイズは何ですか？
sizeof(Foo) ？
メモリ内のこの構造のサイズは、コンパイラの設定とコード内のディレクティブに依存します...
一般的に、フィールドはメモリ内で、それ自体のサイズの倍数である境界に沿って整列されます。 つまり、1バイトのフィールドは位置合わせされず、2バイトのフィールドは偶数位置に位置合わせされ、4バイトのフィールドは4の倍数などになります。 ほとんどの場合（または今日のように）、メモリ内の構造体のサイズのアライメントは4バイトです。 したがって、
sizeof(Foo) == 8です。 余分な3バイトがどこにどのように残るか？ わからない場合、あなたは推測することはありません...
- 1バイト：ch
- 2バイト： 空
- 3バイト： 空
- 4バイト： 空
- 5バイト：値[0]
- 6バイト：値[1]
- 7バイト：値[2]
- 8バイト：値[3]
次に、次の構造のメモリ内の配置を見てみましょう。
struct Foo { char ch; short id; int value; };
次のようになります。
- 1バイト：ch
- 2バイト： 空
- 3バイト：id [0]
- 4バイト：id [1]
- 5バイト：値[0]
- 6バイト：値[1]
- 7バイト：値[2]
- 8バイト：値[3]
つまり、4バイト単位で整列させることができるもの-強打（メモリ内の構造体のサイズを増やすことなく）で押し込み、別のフィールドを追加します。
struct Foo { char ch; short id; short opt; int value; };
メモリ内のフィールドの配置を見てみましょう。
- 1バイト：ch
- 2バイト： 空
- 3バイト：id [0]
- 4バイト：id [1]
- 5バイト：opt [0]
- 6バイト：opt [1]
- 7バイト： 空
- 8バイト： 空
- 9バイト：値[0]
- 10バイト：値[1]
- 11バイト：値[2]
- 12バイト：値[3]
これはどれほど悲しいことでしょうが、コードから直接これに対処する方法があります：
#pragma pack(push, 1) struct Foo {
アライメントサイズを1バイトに設定し、構造を記述して、前の設定に戻しました。 前の設定に戻る-強くお勧めします。 そうしないと、すべてがひどく終了する可能性があります。 私はかつてこれを持っていました-Qtが落ちました。 どこかで彼は.h-nickの下に.h-nickを隠した...
ビットフィールド
コメントで、彼らは私に、標準による構造のビットフィールドは「実装定義」であると指摘しました-したがって、それらの使用を避ける方が良いですが、私にとって誘惑は大きすぎます...心に不安を感じるわけではありませんが、一般的に、コードでマスクやシフトを使用したビットフィールドの塗りつぶしを見ると気分が悪くなります。たとえば、次のようになります。
unsigned field = 0x00530000;
このような悲しみやエラー、それらのデバッグの匂いはすべて、私はすぐに片頭痛を感じます！ そして、彼らはカーテンの後ろから出てきます-ビットフィールド。 最も驚くべきこと-彼らはまだC言語でしたが、私が尋ねる人は誰でも-誰もが初めてそれらについて聞いています。 この無法状態を修正する必要があります。 次に、すべてのリンク、または少なくともこの記事へのリンクを提供します。
このコードはどうですか？
#pragma pack(push,1) struct IpHeader { uint8_t header_length:4; uint8_t version:4; uint8_t type_of_service; uint16_t total_length; uint16_t identificator;
そして、C / C ++のフィールドを常に操作するので、コードでフィールドを操作できます。 すべてがシフトなどで機能します。 コンパイラを引き継ぎます。 もちろん、いくつかの制限があります... 1つの物理フィールドに関連する行に複数のビットフィールドをリストする場合（ビットフィールド名の左側にあるタイプを意味します）-フィールドの末尾までのすべてのビットの名前を指定します。そうしないと、これらのビットにアクセスできません
つまり、コードになります。
#pragma pack(push,1) stuct MyBitStruct { uint16_t a:4; uint16_t b:4; uint16_t c; }; #pragma pack(pop)
結果の構造は4バイトです！ 最初のバイトの2つの半分は、フィールド
aと
bです。 2番目のバイトは名前では使用できず、最後の2バイトは名前
c使用できます。 これは非常に危険な瞬間です。 ビットフィールドで構造を記述した後、必ずその
sizeof確認してください！
また、バイトにビットペインが配置される順序は、バイトの順序によって異なります。 LITTLE_ENDIANの順序では、ビットフィールドは最初のバイトから分散され、BIG_ENDIANは反対になります...
バイトオーダー
また、C ++コードの
htons() 、
ntohs() 、
htonl() 、
nthol()の呼び出しによって、コードが悲しくなりました。 Cでは、これはまだ有効ですが、C ++では無効です。 私はこれに耐えることはありません！ 以下のすべてがC ++に適用されます！
さてここで簡単に説明します。
以前の記事の1つで、バイトオーダーの処理方法を既に書いています。 外部で数値として機能する構造を記述することができ、内部ではそれ自体がバイト単位で格納順序を決定します。 したがって、IPヘッダー構造は次のようになります。
#pragma pack(push,1) struct IpHeader { uint8_t header_length:4; uint8_t version:4; uint8_t type_of_service; u16be total_length; u16be identificator;
2バイトフィールドのタイプ
u16be注意して
u16be 。 これで、構造フィールドはバイト変換を必要としません。
fragment_offsetはまだ問題がありますが、問題のない人は誰でも。 それでも、この不名誉を隠し、一度テストして、すべてのコードで安全に使用するテンプレートを作成することもできます。
「C ++言語は、単純に記述できるほど複雑です」 ©奇妙なことに-I
Z.Y. 次のいずれかの記事で、TCP / IPスタックのプロトコルヘッダーを操作するための理想的な構造を自分の観点からレイアウトすることを計画しています。 思いとどまる-手遅れになる前に！