[過去ﾛｸﾞ] C言語なら俺に聞け 160 (1002ﾚｽ)
上下前次1-新
抽出解除 ﾚｽ栞
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
907(3): (ｱｳｱｳｳｰ Sa05-9cWA) 2023/04/12(水)11:42 ID:+8HledSTa(1/2) AAS
0終端の良い所は可変長でどんなに長い文字列でもメモリが許す限り文字列を続けられる
もちろんデメリットは長さがすぐに判らない
逆に長さを持って struct {size_t len; char hoge[0]} Str; みたいな構成にするのもありだが
例えば Str *s = (Str *)malloc(len + sizeof(Str)); で確保して使う
後者のデメリットは size_t len の最大値までしか文字を格納出来ないこと
struct {short len; char hoge[0]} Str; みたいな実装もたまに観るからあなどれない
920: 2023/04/12(水)15:04 ID:219MxBT/0(1/2) AAS
>>907
馬鹿な私に少しだけアドバイスを
それってsize_tのビット幅 < システム（OS)のビット幅と言う条件下での話なんでしょうか？
size_tがシステム（OS)のビット幅と同じならメモリで管理できるものは必然的にsize_tでも表現できると思うのですが
メモリ上で管理できているゼロ終端文字列をsize_tで表現できない場合ってあるんですか？
まあ一部の組み込みとかならあるかも知れませんが……
けどそういう環境の場合strlenなどのsize_tで返す場合でも表現できなくなるわけで、結局size_tに依存することになってどっちでも同じじゃないかと思うんですがどうなんでしょうか？
923: 2023/04/12(水)15:15 ID:219MxBT/0(2/2) AAS
>>908
もう一つ無知なる私にアドバイスをお願いします
size_t len までは文字を格納出来ると>>907から読み取りましたが
sizeof(size_t)==sizeof(int) の場合
vector v のサイズがINT_MAX以上だった場合、 i < (int)v.size() ではプログラマーが予期しない動作になりませんか？
933: (ﾜｯﾁｮｲ 02ad-Ay2p) 2023/04/13(木)02:04 ID:o3x890Fi0(1/2) AAS
>>907
昔々の PASCAL はそんな感じだったな。先頭1バイトに文字列のバイト数が入っていてその後に文字列がある。
当然それだと255バイトまでしか入らないのでもっと長い文字列を扱いたい時に苦しむことになる。
まあでも 8 bit とか 16 bit CPU のマイコンやパソコンにそういう高い要求は最初の頃はあまりなかったのでなんとかなっていた。
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.042s