findfirstとfindnext関数は駄目なんでしょうか？
ディレクトリを追っかけるだけならこれでも出来そうな気がしますけれど。

Cの標準ライブラリだったと思うので問題ないと思うのですが。
（C++はCの標準ライブラリを含むので問題ないかと）

ディレクトリ操作もあるはずです。
rmdir等々。

(_付いている)_findfirstと_findnextはデバッグで追っかけたら、
中で ::FindFirstFileを呼んでました。

findfirst,findnextはわかりませんけど。

結局ここらへんはＯＳによって違いそうだから、標準ではないんでしょうね。

環境によっては「ファイル」の概念の無いものがある (組み込み機器とか)
ので、ましてやディレクトリなんてものを扱うための C/C++ 言語規格なんてものはないです。
# 電卓とか電気ポットにファイルの概念など多分不要
# findfirst も Windows/VC++ 依存。

むしろ POSIX とか XPG とか調べたほうが幸せになれそうです。
まあこれも C/C++ 言語規格ではありませんけど。

あるいは boost::filesystem とか。

いえ、そもそもファイルシステムそのものはOS依存なのですから
内部で呼んでいるのは当然だと思いますけれど。
呼び出し口としてインターフェイスが規定されていて
標準で用意されていれば問題はないと思います。
むしろ、同じインターフェイスで用意されているかどうかが問題なんですよね。
なので、Windowsでの実装だけを見ても結論は出ないと思いますよ。

# 電卓とか電気ポットにファイルの概念など多分不要
# findfirst も Windows/VC++ 依存。

確かに電卓にファイルの概念は要りませんねぇ。
早い話、システム依存するような部分まで標準でやるのは無理であると
考えるのが良いんでしょうね。
逆にそういう部分はシステム依存とバッサリ割り切って
システムによって実装は切り替えられるような切り口を考えた方が良いんでしょうねぇ。

>PATIOさん
>>findfirstとfindnext Cの標準ライブラリだったと思う
残念乍、環境依存のようです。ANSI-C言語辞典に無かったのと、VSCCでも互換性欄にANSI
表記が無かった為です。
*firstとか*nextという名前の関数って、DOS時代からあるMSのお家芸のようです。こいつ
らが出てきたら、「MSの方言だな」と思うようにしています。

でも、有難うございます。

>Blueさん
>>ここらへんはＯＳによって違いそうだから、標準ではないんでしょう
やはり無いですか．．．。残念です。
ファイルシステムの階層構造って、どのコンピュータにも同じような仕組みですよね。違
うのは些細な部分だけ。だから、どのコンピュータでも共通の「階層を歩き回る操作」
は、標準ライブラリで用意されてるのかな？と思いました。

どうやら無さそうだ、という事が分かっただけでも有り難い事です。
どうもお世話様でした。助かりました。

解決になってますが、
お役に立てなかったようで申し訳ないです。（かき回しただけか）

せっかくC++使うのだったらその部分を仮想クラス化しておいて
各OS毎で実装するとかすれば、少しは何とかできませんかねぇ。
100%全ての環境をターゲットにするのは無理かもしれませんけれど、
数種類のシステムを相手にするのであれば、何とか出来そうな気もするんですけれど。

蛇足でした。

> 蛇足でした。

いや、だからそれが boost::filesystem だってば。

>環境によっては「ファイル」の概念の無いものがある (組み込み機器とか)
>ましてやディレクトリなんてものを扱うための C/C++ 言語規格なんてものはない
確かに。が、標準C/C++ライブラリには、環境依存するはずのファイルを扱う仕組みが既
存です。ですから組み込みか否かに関係なく、ファイルの1種であるディレクトリに対す
る基本操作が標準で用意されていても不思議ではないと思ったんです。

>お役に立てなかったようで申し訳ないです。（かき回しただけか）
いいえ、そんな事ないです。わざわざ時間を割いて頂けただけでも有難いです。

>boost::filesystem
そうですねぇ。次期標準C++ライブラリに組み込まれるであろうboostですから、
今から標準として扱ってもいいかもしれませんね。

> が、標準C/C++ライブラリには、環境依存するはずのファイルを扱う仕組みが既
存です。
C++の方はわからないけど、Cだとファイルじゃなくてストリームではないかな
だからストリームとして表現できないディレクトリは対象ではないと

>ストリームとして表現できないディレクトリは対象ではない
確かにその通りかもしれませんね。なら、C言語時代のファイル処理部分は、
STREAM構造体のsopen()とかsclose()にしてくれたら良かったなぁ(^^;そうすりゃ言葉の
一貫性は保てる。（私にとって、ですけど．．．）
代償として「ストリームって何だよ？」という、言葉の理解の難しさの問題が発生します
けど。