iterate over the files of a directory

[Torsten Mueller]

I have to port a program from Windows to HPUX. It has an algorithm
iterating over files of a directory and all of it's subdirectories
using _findfirst() and _findnext() on a structure called _finddata_t.

What are possible replacements for this on HPUX (aCC) or other UNIXes?
I need just a function name I could look for.

Thank you.

T.M.

 

[Rolf Magnus]

I have to port a program from Windows to HPUX. It has an algorithm
iterating over files of a directory and all of it's subdirectories
using _findfirst() and _findnext() on a structure called _finddata_t.

What are possible replacements for this on HPUX (aCC) or other UNIXes?
I need just a function name I could look for.

That should have been asked in a Un*x newsgroup like comp.unix.programmer.
It's off-topic here, since clc++ is only about ISO C++.

Anyway, here's the answer:

man opendir
man readdir

 

[Donovan Rebbechi]

That should have been asked in a Un*x newsgroup like comp.unix.programmer.
It's off-topic here, since clc++ is only about ISO C++.

Anyway, here's the answer:

man opendir
man readdir

To make it more topical (-; ... IIRC, boost has a class for doing this

Cheers,

 

[Jeff Flinn]

I have to port a program from Windows to HPUX. It has an algorithm
iterating over files of a directory and all of it's subdirectories
using _findfirst() and _findnext() on a structure called _finddata_t.

What are possible replacements for this on HPUX (aCC) or other UNIXes?
I need just a function name I could look for.

See http://www.boost.org/libs/filesystem/doc/index.htm which has been ported
to many compiler/OS combinations.

Jeff Flinn

 

[Torsten Mueller]

See http://www.boost.org/libs/filesystem/doc/index.htm which has
been ported to many compiler/OS combinations.

Yes, sure, there's Boost. But I just want to iterate over some files.
I dont want to make my program dependent on a large 3rd party library
including all the multipurpose stuff and regular expressions. My
approach is indeed the function family containing opendir, readdir and
closedir I found now in my include directory.

Interesting that Watcom did implement these functions also for Windows
and other operating systems while MS has it's own C-functions not
conforming to any standard.

T.M.

 

[Rapscallion]

I have to port a program from Windows to HPUX. It has an algorithm
iterating over files of a directory and all of it's subdirectories
using _findfirst() and _findnext() on a structure called _finddata_t.

What are possible replacements for this on HPUX (aCC) or other UNIXes?
I need just a function name I could look for.

opendir, closedir, readdir, rewinddir ...
http://docs.hp.com/en/B2355-60105/directory.3C.html

 

[Rapscallion]

See http://www.boost.org/libs/filesystem/doc/index.htm which has been ported

to many compiler/OS combinations.

I thought libraries like MFC, ATL, WTL, BOOST, Pthreads, QT, ... are
off topic? Not so??

 

[Rolf Magnus]

Yes, sure, there's Boost. But I just want to iterate over some files.
I dont want to make my program dependent on a large 3rd party library
including all the multipurpose stuff and regular expressions.

I guess you haven't actually looked into it, otherwise you'd know that boost
is not one big library, but rather several independent small ones, with the
filesystem part being one of those.

My approach is indeed the function family containing opendir, readdir and
closedir I found now in my include directory.

Interesting that Watcom did implement these functions also for Windows
and other operating systems while MS has it's own C-functions not
conforming to any standard.

That's not really surprising to me. Watcom aimed at portability, which
Microsoft never really cared about.

 

[Rolf Magnus]

I thought libraries like MFC, ATL, WTL, BOOST, Pthreads, QT, ... are
off topic? Not so??

Usually, yes, though boost is kind of an exception to it, because it is
designed to work closely together with the C++ standard library, and
because parts of it will probably go into the next version of the C++
standard library.

 

[Torsten Mueller]

I guess you haven't actually looked into it, otherwise you'd know
that boost is not one big library, but rather several independent
small ones, with the filesystem part being one of those.

Indeed another part of my application uses Boost 1.31. I have it in my
project directory. There must be more than 2000 header files in it ...

Sure, at the end the really linked portion of code may be small,
depending on the code I really use from the Boost library. But why
should I use it? Just to avoid these three silly function calls? Or to
get an object oriented approach of my 20 lines of code in a single
function?

T.M.

 

[Richard Herring]

Indeed another part of my application uses Boost 1.31. I have it in my
project directory. There must be more than 2000 header files in it ...

Sure, at the end the really linked portion of code may be small,
depending on the code I really use from the Boost library. But why
should I use it?

Because it offers a solution to a problem you actually have?

Just to avoid these three silly function calls? Or to
get an object oriented approach of my 20 lines of code in a single
function?

Well, why not? It's three function calls and 20 lines of code less to
maintain, and the cost is approximately nil if you're already using the
library anyway.

 

[Kristo]

Usually, yes, though boost is kind of an exception to it, because it is
designed to work closely together with the C++ standard library, and
because parts of it will probably go into the next version of the C++
standard library.

While Boost is not considered to be strictly off-topic here, it's worth
noting that it is not strictly on-topic either. For now, Boost
questions still need to go to the Boost mailing list.

Kristo

 

[Rapscallion]

Usually, yes, though boost is kind of an exception to it, because it is
designed to work closely together with the C++ standard library, and
because parts of it will probably go into the next version of the C++
standard library.

I see. All libraries are treated equal. Just one is treated more equal.

 

[Torsten Mueller]

Because it offers a solution to a problem you actually have?

No. After I got the answer opendir, readdir and so on would be a
function family solving my problem it took my 20 minutes to implement
the whole algorithm. I could not have been faster using Boost or _any_
other class library.

Well, why not? It's three function calls and 20 lines of code less
to maintain,

The replacement of my code by other code leads to "code less to
maintain"?

In my experience many people tend to use multiple libraries. If they
get a new programming task they go into the Internet immediately to
look for a library "that solves the problem". Especially many young
developers do not know any other way. They don't even think about
implementing an algorithm themselves. And they really don't think
about dependencies (on software providers, on the software's versions
and patches, on compilers, on platforms), about maintenance (perhaps
for a runtime period of 10 years!), about portability, about
performance and other aspects. Today a very markable aim of
developement communicated especially by managers is just a short
developement time regardless of the result ...

I have several reasons to remain independent in this case. I have
several reasons to use libraries in other cases. It depends just on
many conditions. The use of a library is never the one and only and
also not always the best solution in a given situation.

and the cost is approximately nil if you're already using the
library anyway.

Yes but exactly this condition was _not_ given. I did not use the
Boost library in this program and I do not want to change this.

T.M.

 

[Richard Herring]

No. After I got the answer opendir, readdir and so on would be a
function family solving my problem it took my 20 minutes to implement
the whole algorithm.
I could not have been faster using Boost or _any_
other class library.

for ( directory_iterator p(path), e; p!=e; ++p)
{
// do something with *p;
}

The replacement of my code by other code leads to "code less to
maintain"?

Unless you're proposing to take over the maintenance of the Boost
filesystem library, yes. It's more *configuration* to maintain, and
that's important, but that's not the same thing.

[snip rant]

I have several reasons to remain independent in this case. I have
several reasons to use libraries in other cases. It depends just on
many conditions. The use of a library is never the one and only and
also not always the best solution in a given situation.

Indeed. I'm just offering one reason for using the library.

Another would be platform-independence. After all, it was the difference
between *nix and Windows functions that led you to post the question in
the first place.

Yes but exactly this condition was _not_ given. I did not use the
Boost library in this program and I do not want to change this.

Ah. So when you said

Indeed another part of my application uses Boost 1.31.

you didn't mean what I thought you meant.

 

[Rolf Magnus]

No. After I got the answer opendir, readdir and so on would be a
function family solving my problem it took my 20 minutes to implement
the whole algorithm. I could not have been faster using Boost or _any_
other class library.

I wonder whether by "port a program from Windows to HPUX", you mean that
both versions will be maintained further or that the Windows version gets
replaced with the HPUX version. In the former case, or of the program is
supposed to ever be ported to another platform, the usage of boost has the
advantage that you don't need to maintain two (or more) separate versions
of your code for the platforms.

The replacement of my code by other code leads to "code less to
maintain"?

The replacement of your own code by a library that has been tested
extensively? Yes, it does.

In my experience many people tend to use multiple libraries. If they
get a new programming task they go into the Internet immediately to
look for a library "that solves the problem".

I think that's reasonable. That's what libraries are there for. Why
re-invent the wheel? Why adding more code that needs to be maintained,
documented and tested than necessary?

 

[Default User]

I see. All libraries are treated equal. Just one is treated more equal.

A situation that causes some of us to protest occasionally, albeit with
little effect.



Brian