C# と VB.NET の質問掲示板

ASP.NET、C++/CLI、Java 何でもどうぞ

C# と VB.NET の入門サイト

Re[32]: バイナリコード内の16進数での文字列検索 [3]


(過去ログ 52 を表示中)

[トピック内 72 記事 (61 - 72 表示)]  << 0 | 1 | 2 | 3 >>

■28676 / inTopicNo.61)  Re[24]: バイナリコード内の16進数での文字列検索
  
□投稿者/ .SHO (236回)-(2008/11/28(Fri) 17:47:04)
っていうか、ungetc の実装は stdio.h の中見ればわかるか。
引用返信 編集キー/
■28677 / inTopicNo.62)  Re[24]: バイナリコード内の16進数での文字列検索
□投稿者/ επιστημη (1393回)-(2008/11/28(Fri) 17:57:03)
επιστημη さんの Web サイト
> 戻せますよ。読み込んだ分だけ戻せます。
> かなり前だけど、ストリーム関連のソースは全部読んだので
> どういう仕組みで戻してるのかもわかってるので間違いないです。

そじゃなくてぇ... それは"いくつでも戻せる実装"のソースを読んだからじゃなくて?
標準関数の「仕様としてどうか」ってことです。

ストリームに戻せるのは一個だけだったと記憶してんですけどー

引用返信 編集キー/
■28679 / inTopicNo.63)  Re[25]: バイナリコード内の16進数での文字列検索
□投稿者/ .SHO (237回)-(2008/11/28(Fri) 18:11:15)
No28677 (επιστημη さん) に返信

> そじゃなくてぇ... それは"いくつでも戻せる実装"のソースを読んだからじゃなくて?
> 標準関数の「仕様としてどうか」ってことです。
> ストリームに戻せるのは一個だけだったと記憶してんですけどー

了解です。正確に書きますね。
一応戻せるんですけど ungetc で戻して処理が保障されるのは一個だけです。

なぜかと言うとFILE構造体の中では256バイトのリングバッファを持っていて
fgetcとして1バイト読みだしても、内部では256バイトの塊でファイルから読込み
そこから1バイトを返してます。
ungetc は、そのポインターを戻して指定された文字を格納してるだけなんです。
ですから、この256バイトの境界をまたいでのungetcは出来ないというのが
正しい答えなんですが、標準関数の仕様としては1バイトしか保証しない
という言い方をしてます。
まぁ、通常は1個しか戻せないと覚えておいて問題はないと思います。
従って、ungetcを複数回呼び出す必要がある場合は、バイト数分前にseekする
のが正解です。

引用返信 編集キー/
■28680 / inTopicNo.64)  Re[26]: バイナリコード内の16進数での文字列検索
□投稿者/ .SHO (238回)-(2008/11/28(Fri) 18:21:33)
ちなみに業務で作るプログラムでは ungetc と scanf は絶対に使わないです。
さっきのコードは途中で面倒になったので ungetc で逃げました^^;
引用返信 編集キー/
■28682 / inTopicNo.65)  Re[27]: バイナリコード内の16進数での文字列検索
□投稿者/ .SHO (240回)-(2008/11/28(Fri) 18:37:46)
ごめんなさい。
ですから「ストリームに戻せるのは一個だけ」で正しいです。

ようするに、検索&置換の処理はめんどくさいということで…^^;
引用返信 編集キー/
■28684 / inTopicNo.66)  Re[26]: バイナリコード内の16進数での文字列検索
□投稿者/ .SHO (241回)-(2008/11/28(Fri) 19:08:53)
No28679 (.SHO さん) に返信

> なぜかと言うとFILE構造体の中では256バイトのリングバッファを持っていて

また突っ込まれそうなので補足しておきます。
K&Rの頃は256バイト固定だったんですが、今調べてみたらVCでは4096バイトでした。
今時256バイトはないですね。。。
4096バイトの方がディスクのFATセグメントとも相性がいいですし。
引用返信 編集キー/
■28697 / inTopicNo.67)  Re[27]: バイナリコード内の16進数での文字列検索
□投稿者/ あんどちん (26回)-(2008/11/28(Fri) 23:46:17)
No28684 (.SHO さん) に返信
> ■No28679 (.SHO さん) に返信
>
>>なぜかと言うとFILE構造体の中では256バイトのリングバッファを持っていて
>
> また突っ込まれそうなので補足しておきます。
> K&Rの頃は256バイト固定だったんですが、今調べてみたらVCでは4096バイトでした。
> 今時256バイトはないですね。。。
> 4096バイトの方がディスクのFATセグメントとも相性がいいですし。

僕が以前関わっていたプロジェクトで使用していたライブラリではf系のファイル関数は512バイト単位でファイルシステムへアクセスしていました。(ライブラリの再構築で変更可能)
古いライブラリでの256バイトのバッファサイズは恐らく当時であればフロッピーのセクタサイズと合っていたから、もしくはメモリ使用量を考慮してではないでしょうか。最近ではFAT32/NTFS共クラスタサイズを4Kで取ってフォーマットしている事が多いでしょうから最近のVCのライブラリがそのサイズなのはご指摘の通りなのでしょうね。
# ISO9660やUDFは工学メディアのセクタサイズが2Kなので4Kだと倍数だから収まりがいいのかな?

ところでFILE構造体にバッファを持つことは規定されているのでしょうか?FILE構造体の実装はベンダー依存のような気がします。

引用返信 編集キー/
■28711 / inTopicNo.68)  Re[28]: バイナリコード内の16進数での文字列検索
□投稿者/ .SHO (247回)-(2008/11/29(Sat) 11:37:35)
No28697 (あんどちん さん) に返信

> ところでFILE構造体にバッファを持つことは規定されているのでしょうか?FILE構造体の実装はベンダー依存のような気がします。

いえ、規定されていません。
ただ現実には、FILE構造体が極端に異なるように実装された処理系を見たことがないです。

高水準入出力は、内部では低水準入出力を使用して実装されているのでバッファリングしないと
あまり意味がなくなってしまうので、結果的にどの処理系もバッファを持つことになると思います。

そうだとしても、規定されていないのならFILE構造体で持つ必要はないのでは?と言われるかも
知れないですが、fopen は同時に複数のファイルを開けますので fopen するたびに
動的に確保される FILE 構造体の中に持つのが自然です。

引用返信 編集キー/
■28712 / inTopicNo.69)  Re[29]: バイナリコード内の16進数での文字列検索
□投稿者/ .SHO (248回)-(2008/11/29(Sat) 11:48:23)
それに、仮に FILE 構造体の外部にバッファを持ったとしても
そのバッファとFILE構造体を結びつけるポインタは絶対に必要になります。
それならば、始めから FILE 構造体の中にバッファを持った方が自然です。
引用返信 編集キー/
■28723 / inTopicNo.70)  Re[30]: バイナリコード内の16進数での文字列検索
□投稿者/ dogatana (16回)-(2008/11/29(Sat) 16:27:51)
No28712 (.SHO さん) に返信
> それに、仮に FILE 構造体の外部にバッファを持ったとしても
> そのバッファとFILE構造体を結びつけるポインタは絶対に必要になります。
> それならば、始めから FILE 構造体の中にバッファを持った方が自然です。

高水準入出力は、システムコールとは異なりバッファリングする関数なので、
何らかの形でバッファが必須ですね。
で、そのサイズはsetvbufで変更できるので、内部に固定的に持つというよりは
ポインタを持つのが自然な気がします。

Visual C++, Borland C++いずれのFILE構造体もポインタで持っているようです。

引用返信 編集キー/
■28724 / inTopicNo.71)  Re[31]: バイナリコード内の16進数での文字列検索
□投稿者/ .SHO (250回)-(2008/11/29(Sat) 16:50:40)
No28723 (dogatana さん) に返信

> で、そのサイズはsetvbufで変更できるので、内部に固定的に持つというよりは
> ポインタを持つのが自然な気がします。

固定的という言葉が悪かったです。すいません。
もちろん char buffer[4096]; ということではないです。

fopen は

FILE *fp = malloc( sizeof( FILE ) );
fp->buffer = malloc( buffer_size );
  :
その他の初期化
  :
return fp;

という動きをするので、もちろんポインタで持ってます。
引用返信 編集キー/
■28725 / inTopicNo.72)  Re[32]: バイナリコード内の16進数での文字列検索
□投稿者/ .SHO (251回)-(2008/11/29(Sat) 16:53:15)
No28724 (.SHO さん) に返信

ヒープ領域はFILE構造体の外部だと言われれば、まぁ確かに外部ですね。
引用返信 編集キー/

<前の20件
トピック内ページ移動 / << 0 | 1 | 2 | 3 >>

このトピックに書きこむ

過去ログには書き込み不可

管理者用

- Child Tree -