[表示 : 全て 最新50 1-99 101- 201- 301- 401- 501- 601- 701- 801- 2chのread.cgiへ]
Update time : 05/09 12:15 / Filesize : 193 KB / Number-of Response : 819
[このスレッドの書き込みを削除する]
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

スレを勃てるまでもないC/C++の質問はここで 8



83 名前:64 mailto:sage [2009/03/05(木) 09:18:13 ]
>>81
各項目での自分的評価だと、こんな感じです(1が最も短い・速い・わかりやすい・etc):

cast: 3321
標準的な記法で、外部知識を要しない。オブジェクトサイズも最小。ただ、キャストの嵐が目に
やさしくない(マクロで対処は可能)のとオフセット計算が間違えやすい。パックされた構造の把握は
縦に読む必要がある。縦の行数はパック対象変数分程度。バッファコピーが必要になるとmemcpyが必要。

 例: *(uint32_t *)(dst + 4) = (uint32_t)htonl(src); <- これがN行続く

memcpy: 4211
標準関数なので、外部知識を要さず、サイズも呼び出しのみで小さい。キャストも不要。
オフセット計算は必要で、転送データ構造のイメージは縦に読んで把握する必要がある。
縦の行数は最大で対象変数の数+エンディアン変換数程度で最大。

 例: src = htonl(src); memcpy(dst + 4, &src, sizeof(src));  <- これがN行続く

struct: 2222
外部知識は要しないが、一般性で劣る。サイズはキャスト方式と同等か、スタック消費分劣る。
オフセット計算が不要で、構造イメージは横に並んだ順そのままで把握はしやすい。しかし、
構造定義が長くなりがちで、変数の使用位置から離れるとズレやすいかも。バッファコピーが必要に
なるとmemcpyが必要。

 例: struct { uint32_t _a; uint8_t _b, ... } buf = { htonl(src1), htonl(src2), ... }; <- スタック利用
  or typedef struct { uint32_t _a; uint8_t _b, ... } in_t;
    *(int_t *)(buf + 4) = { htonl(src1), htonl(src2), ... }; <- 既存バッファへの書き込み

mprintf: 1113
フォーマット表記の知識を得る必要があるが、処理部分のコードはかなり簡潔にデータ構造を
表現・理解できる。ただし、mprintfの実装分、メモリと処理速度で劣る。処理の中身はmemcpy。

 例: mprintf(buf + 4, "NN...", src1, src2, ...);






[ 続きを読む ] / [ 携帯版 ]

全部読む 次100 最新50 [ このスレをブックマーク! 携帯に送る ] 2chのread.cgiへ
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧]( ´∀`)<193KB

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef