C++ and directories

[Edward Hvarregaard]

newby here

I am having trouble getting started in C++ I have done some programming in
PASCAL where I had no problem finding the commands needed to deal with
directories, files and attributes. where can I find the similar commands
for C++ ?

The startup code I need must do the following

If "C:\SSF\ProgramFiles\Exch.txt" does not exist
then Setup

Setup needs to be a function that creates missing path elements and an
empty "Exch.txt" file

Thanks

Ed

 

[Ian Collins]

newby here

I am having trouble getting started in C++ I have done some programming in
PASCAL where I had no problem finding the commands needed to deal with
directories, files and attributes. where can I find the similar commands
for C++ ?

The startup code I need must do the following

If "C:\SSF\ProgramFiles\Exch.txt" does not exist
then Setup

Setup needs to be a function that creates missing path elements and an
empty "Exch.txt" file

If boost filesystem doesn't meet your needs, use the C filesystem
interface provided by your platform.

 

[Nobody]

I am having trouble getting started in C++ I have done some programming
in PASCAL where I had no problem finding the commands needed to deal with
directories, files and attributes. where can I find the similar commands
for C++ ?

The C++ language isn't tied to a specific platform. Consequently, it
doesn't include features which are platform-specific. Directories are such
a feature: not all platforms have them, and those that do can have wildly
different semantics.

So you need to use either a third-party library (e.g. boost::filesystem),
or the platform's native OS functions (e.g. opendir/readdir/closedir on
Unix, FindFirstFile/FindNextFile/FindClose on Windows).

 

[Jens Thoms Toerring]

If boost filesystem doesn't meet your needs, use the C filesystem
interface provided by your platform.

Perhaps a bit of extra information, extending on what Ian Collins
wrote, may help: not all systems have a notion of directories
(or files) in the sense you're probably used to. And if C++
would require functions to exist that handle directories and
files in the manner you were expecting it there couldn't be a
C++ compiler for those kinds of systems. Thus such functions
weren't made an integral part of C++ (Pascal may be able to
deal with this problem in a different way since it was origi-
nally intended as a "learning language" and probably wasn't
meant to be available on somewhat more "exotic" systems).

So you either have to use the functions that your system
supplies you with for these purposes. Since it looks a bit
as if you're using Windows perhaps the information at

http://msdn.microsoft.com/en-us/library/aa364407(v=VS.85).aspx

(and below, especially "Directory Managment" and "File Managment")
could be useful for you. Otherwise asking in a newsgroup about
programming under Windows could be a useful option.

But if you want to be more system-inpedendent then there's
the boost library ian mentioned that tries to do just that,
see

http://www.boost.org/doc/libs/1_41_0/libs/filesystem/doc/index.htm

Regards, Jens

 

[Juha Nieminen]

The C++ language isn't tied to a specific platform. Consequently, it
doesn't include features which are platform-specific. Directories are such
a feature: not all platforms have them, and those that do can have wildly
different semantics.

So you need to use either a third-party library (e.g. boost::filesystem),

I can't help but to notice the slight contradiction: First it's pointed
out that handling directories and file listings is very system-dependent
(and hence by implication impossible to write code for in a portable way),
and immediately after that a portable generic file system library is
suggested.

Anyways, is there a reason why the C++ standard couldn't include a
library similar to boost::filesystem?

 

[Marc]

Anyways, is there a reason why the C++ standard couldn't include a
library similar to boost::filesystem?

There is a proposal pending for the next revision of the standard.

 

[Jens Thoms Toerring]

I can't help but to notice the slight contradiction: First it's pointed
out that handling directories and file listings is very system-dependent
(and hence by implication impossible to write code for in a portable way),
and immediately after that a portable generic file system library is
suggested.

Anyways, is there a reason why the C++ standard couldn't include a
library similar to boost::filesystem?

According to the documentation it is in the process of being made
part of the C++ standard:

A proposal, N1975, to include Boost.Filesystem in Technical
Report 2 has been accepted by the C++ Standards Committee.
The Boost.Filesystem library will stay in alignment with the
TR2 Filesystem proposal as it works its way through the TR2
process.

I guess that, due to the C background of C++ (C doesn't have
a portable interface for directory and file managment) it was
not considered to be necessary for C++ to have one. And then
this is a non-trivial problem and probably there wasn't a re-
ference implementation that really worked like Boost.Flile-
system seems to do and, as far as my understanding of the
standarduzation prozess goes, getting something into the
standard without a reasonable reference implementation normally
doesn't happen. And even with a reference implementation it's
still a long process...
Regards, Jens

 

[Stefan Ram]

Anyways, is there a reason why the C++ standard couldn't include a
library similar to boost::filesystem?

See also:

http://www.purl.org/stefan_ram/pub/c++_standard_extensions_en

(first published 2003-09-02).

 

[Jorgen Grahn]

newby here

I am having trouble getting started in C++ I have done some programming in
PASCAL where I had no problem finding the commands needed to deal with
directories, files and attributes.

Which Pascal? I doubt Wirth's original Pascal had such things -- IIRC
it barely had strings.

/Jorgen

 

[Jorgen Grahn]

I can't help but to notice the slight contradiction: First it's pointed
out that handling directories and file listings is very system-dependent
(and hence by implication impossible to write code for in a portable way),
and immediately after that a portable generic file system library is
suggested.

Perhaps boost::filesystem doesn't have to work /everywhere/ where
there's a C++ compiler? I haven't checked.

(Personally I don't think I'd use a standard and generic file system
interface if there was one -- not unless there was a straight 1:1
mapping to the Unix file system. That's the single target environment
for my code, and I know it well.)

/Jorgen

 

[Bo Persson]

newby here

I am having trouble getting started in C++ I have done some
programming in PASCAL where I had no problem finding the commands
needed to deal with directories, files and attributes. where can I
find the similar commands for C++ ?

The startup code I need must do the following

If "C:\SSF\ProgramFiles\Exch.txt" does not exist
then Setup

Setup needs to be a function that creates missing path elements
and an empty "Exch.txt" file

Thanks

Ed

The easiest way to see if a file exists is to try to open it! If that
fails, it doesn't exist.


Bo Persson

 

[Jorgen Grahn]

The easiest way to see if a file exists is to try to open it! If that
fails, it doesn't exist.

Or something else is wrong, or as it should be. I hate it when a
program claims a file doesn't exist, just because it cannot do some
random operation with it.

/Jorgen

 

[Nobody]

Anyways, is there a reason why the C++ standard couldn't include a
library similar to boost::filesystem?

A third-party library has more leeway. It's up to the third-party
developer whether "it sort-of works, on common platforms" is good enough.
If e.g. an OS vendor complains that the interface is a poor match for
their OS's filesystem semantics, the boost developers can just say
"tough luck". But the ISO standardisation process is rather more involved.

 

[Juha Nieminen]

A third-party library has more leeway. It's up to the third-party
developer whether "it sort-of works, on common platforms" is good enough.
If e.g. an OS vendor complains that the interface is a poor match for
their OS's filesystem semantics, the boost developers can just say
"tough luck". But the ISO standardisation process is rather more involved.

Not everything even in the current standard is something that *must*
work on every system in existence.

For example, where does the output of std::cout (or printf from that
matter) go? There actually *are* systems which have no concept of
standard output streams, and std::cout/printf can hence fail (for example
printf returns the amount of printed characters for this precise reason).

However, std::cout/printf work in the vast majority of systems, and
programs written using them are usually not even intended to be run on
those obscure (usually embedded) systems that have no support. (Have you
ever seen a "hello world" program in C or C++ that actually checks that
printing succeeded? The fair assumption can be made that if you have
a system with no standard output you wouldn't be running such a program
on it anyways.)

(Ok, the printing can fail for other reasons as well, eg. if standard
output is redirected to a file and an error happens. Of course trying to
handle this kind of error from the program itself would be quite difficult.)

I think a file system library is feasible even for the C++ standard,
especially if it includes means to check that the target architecture
has proper support.

 

[Nobody]

Not everything even in the current standard is something that *must*
work on every system in existence.

For example, where does the output of std::cout (or printf from that
matter) go?

It doesn't have to "go" anywhere. An implementation can discard anything
written to cout/cerr and consider cin as being initially at EOF.

However, on most platforms which actually have files, there's enough
commonality to make it worth defining a basic interface. Even on systems
which don't have files, stringstream still works.

I think a file system library is feasible even for the C++ standard,
especially if it includes means to check that the target architecture
has proper support.

Unlike streams, filesystems differ greatly in their semantics. E.g.
single root (Unix) versus multiple drives and UNC paths (Windows), the
types of object which can exist on a filesystem, whether links are
supported and whether they're transparent (hard links) or a distinct type
(symbolic links), whether filenames are composed of bytes (Unix) or
characters (Windows), whether filenames are case-sensitive, whether a file
can be renamed or deleted while it is open, what information is stored
about a file, whether files are versioned (VMS), ...

The differences just between Unix and Windows are enough that even fairly
trivial cases end up requiring #ifdef'd code to handle the differences.
And once you move beyond the most common platforms, you're usually on your
own.

 

[Edward Hvarregaard]

This is my first post and I would like to say thanks to all who have taken
the time to respond to it

I Hope this will do it

Thanks

Ed

 

[Nick Keighley]

If so then shouldn't it be the case that if a std directory lib is
standardised it should work on all systems that have a file directory
system?

Obviously it would be up to common sense to decide that its not going to
work on a system with no file directories, just as is the case with the STD
I/O not working on a system without an I/O system.

I don't see why it shouldn't work even with no directories. The
library just behaves as if everything is in root and there happen to
be no directories present

 

[Nick Keighley]

  Not everything even in the current standard is something that *must*
work on every system in existence.

  For example, where does the output of std::cout (or printf from that
matter) go? There actually *are* systems which have no concept of
standard output streams, and std::cout/printf can hence fail (for example
printf returns the amount of printed characters for this precise reason).

  However, std::cout/printf work in the vast majority of systems, and
programs written using them are usually not even intended to be run on
those obscure (usually embedded) systems

such as Windows.

non-console applications usually don't send std::cout to anywhere
sensible