Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #8881 > unrolled thread

C++ and directories

Back to article view | Back to comp.lang.c++

Contents

  C++ and directories "Edward Hvarregaard" <edwardh@shaw.ca> - 2011-08-15 17:49 -0700
    Re: C++ and directories Ian Collins <ian-news@hotmail.com> - 2011-08-16 12:55 +1200
      Re: C++ and directories jt@toerring.de (Jens Thoms Toerring) - 2011-08-16 11:15 +0000
    Re: C++ and directories Nobody <nobody@nowhere.com> - 2011-08-16 11:57 +0100
      Re: C++ and directories Juha Nieminen <nospam@thanks.invalid> - 2011-08-16 11:42 +0000
        Re: C++ and directories Marc <marc.glisse@gmail.com> - 2011-08-16 11:49 +0000
        Re: C++ and directories jt@toerring.de (Jens Thoms Toerring) - 2011-08-16 11:58 +0000
        Re: C++ and directories Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-08-16 16:02 +0000
        Re: C++ and directories Nobody <nobody@nowhere.com> - 2011-08-17 13:09 +0100
          Re: C++ and directories Juha Nieminen <nospam@thanks.invalid> - 2011-08-17 13:02 +0000
            Re: C++ and directories Nobody <nobody@nowhere.com> - 2011-08-17 18:11 +0100
            Re: C++ and directories "Paul" <pchristor@yahoo.co.uk> - 2011-08-18 20:38 +0100
              Re: C++ and directories Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-08-23 01:03 -0700
            Re: C++ and directories Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-08-23 01:06 -0700
    Re: C++ and directories Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-08-16 15:24 +0000
    Re: C++ and directories "Bo Persson" <bop@gmb.dk> - 2011-08-17 12:39 +0200
      Re: C++ and directories Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-08-17 11:39 +0000
    Re: C++ and directories "Edward Hvarregaard" <edwardh@shaw.ca> - 2011-08-22 10:06 -0700

#8881 — C++ and directories

 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 

[toc] | [next] | [standalone]

#8882

On 08/16/11 12:49 PM, Edward Hvarregaard wrote:
>   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.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#8906

Ian Collins <ian-news@hotmail.com> wrote:
> On 08/16/11 12:49 PM, Edward Hvarregaard wrote:
> > 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.

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%28v=VS.85%29.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
-- 
  \   Jens Thoms Toerring  ___      jt@toerring.de
   \__________________________      http://toerring.de

[toc] | [prev] | [next] | [standalone]

#8905

On Mon, 15 Aug 2011 17:49:55 -0700, Edward Hvarregaard wrote:

> 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).

[toc] | [prev] | [next] | [standalone]

#8908

Nobody <nobody@nowhere.com> wrote:
> 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?

[toc] | [prev] | [next] | [standalone]

#8910

Juha Nieminen  wrote:

>   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.

[toc] | [prev] | [next] | [standalone]

#8911

Juha Nieminen <nospam@thanks.invalid> wrote:
> Nobody <nobody@nowhere.com> wrote:
> > 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?

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
-- 
  \   Jens Thoms Toerring  ___      jt@toerring.de
   \__________________________      http://toerring.de

[toc] | [prev] | [next] | [standalone]

#8929

On Tue, 2011-08-16, Juha Nieminen wrote:
> Nobody <nobody@nowhere.com> wrote:
>> 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.

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

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#8978

On Tue, 16 Aug 2011 11:42:39 +0000, Juha Nieminen wrote:

>   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.

[toc] | [prev] | [next] | [standalone]

#8981

Nobody <nobody@nowhere.com> wrote:
> On Tue, 16 Aug 2011 11:42:39 +0000, Juha Nieminen wrote:
> 
>>   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.

  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.

[toc] | [prev] | [next] | [standalone]

#8996

On Wed, 17 Aug 2011 13:02:34 +0000, Juha Nieminen wrote:

>>>   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.
> 
>   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.

[toc] | [prev] | [next] | [standalone]

#9056

"Juha Nieminen" <nospam@thanks.invalid> wrote in message 
news:4e4bbbea$0$4367$7b1e8fa0@news.nbl.fi...
> Nobody <nobody@nowhere.com> wrote:
>> On Tue, 16 Aug 2011 11:42:39 +0000, Juha Nieminen wrote:
>>
>>>   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.
>
>  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.

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. 


--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

[toc] | [prev] | [next] | [standalone]

#9219

On Aug 18, 8:38 pm, "Paul" <pchris...@yahoo.co.uk> wrote:
> "Juha Nieminen" <nos...@thanks.invalid> wrote in message
>
> news:4e4bbbea$0$4367$7b1e8fa0@news.nbl.fi...
>
>
>
>
>
> > Nobody <nob...@nowhere.com> wrote:
> >> On Tue, 16 Aug 2011 11:42:39 +0000, Juha Nieminen wrote:
>
> >>>   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.
>
> >  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.
>
> 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

[toc] | [prev] | [next] | [standalone]

#9220

On Aug 17, 2:02 pm, Juha Nieminen <nos...@thanks.invalid> wrote:
> Nobody <nob...@nowhere.com> wrote:
> > On Tue, 16 Aug 2011 11:42:39 +0000, Juha Nieminen wrote:
>
> >>   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.
>
>   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


> 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.

[toc] | [prev] | [next] | [standalone]

#8928

On Tue, 2011-08-16, Edward Hvarregaard wrote:
>  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 <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#8974

Edward Hvarregaard wrote:
> 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

[toc] | [prev] | [next] | [standalone]

#8977

On Wed, 2011-08-17, Bo Persson wrote:
> Edward Hvarregaard wrote:
>> 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

> 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

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#9179

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



"Edward Hvarregaard" <edwardh@shaw.ca> wrote in message 
news:_8j2q.43956$nj1.56@newsfe19.iad...
> 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
> 

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c++

csiph-web