Martin von Loewis wrote:
>
> Christopher Eltschka <celtschk@physik.tu-muenchen.de> writes:
>
> > > You'd have to define what a directory is, first. So if you want POSIX,
> > > you already gotit: readdir(3).
> >
> > A directory is a persistent container of files and directories.
> [...]
> >   class direntry
> >   {
> >   public:
> >     string name() const throw(std::exception);
> >     bool is_dir() const throw();
> >   };
>
> Now what about Windows NT, where each directory entry might have two
> names: a short one, and a long one? (and where you typically only want
> to display one or the other, but not both?)

Probably the implementation would return the long name (which
can be considered as the "real" name when working under WinNT),
and a vendor specific extension would be used to return the
short name (f.ex string direntry::__shortname()).

>
> What about symbolic links which point to a directory? Should is_dir
> return true or false for them?

Implementation defined. Or maybe a topic for a POSIX standard.

>
> How do you get the root directory?

On Unix, DOS, OS/2, WinXX:

  directory root_dir("/");

On DOS, OS/2 WinXX you can also do:

  directory root_dir("\\");

On other OSs, the root directory may have another name.

> What about drive letters?

On DOS, OS/2, WinXX:

  directory drive_A_root("A:\");

What did you think the constructors taking a string are for?

>
> I don't actually want to get into a long debate about this specific
> API, so there is no need to defend it - I just think that this (or
> anything else in that area) would cause a lot of discussions, and
> people would be unhappy, no matter what the outcome of the discussion
> is.

With this attitude, I guess lots of things in the C++ standard
could not have gotten in. Remove everything from C++ which needed
much discussion, and from the rest everything some people are
unhappy with. How much does remain? I suspect not very much.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Martin von Loewis wrote:

> Now what about Windows NT, where each directory entry might have two
> names: a short one, and a long one? (and where you typically only want
> to display one or the other, but not both?)

I guess the short name is there only for DOS 8.3 compatibility.

I guess that there is an official name.

> What about symbolic links which point to a directory? Should is_dir
> return true or false for them?

Symbolic links can either be considered as directories, but then:
- you can get directory loops
- what if a link points to a non-existent directory ?

> How do you get the root directory? What about drive letters?

This one is easy. They are clearly directories.

I think that you should have a look at the dir_it Boost
library:

  http://www.boost.org/libs/dir_it/

--

Valentin Bonnard
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Christopher Eltschka <celtschk@physik.tu-muenchen.de> writes:

> > You'd have to define what a directory is, first. So if you want POSIX,
> > you already gotit: readdir(3).
>
> A directory is a persistent container of files and directories.
[...]
>   class direntry
>   {
>   public:
>     string name() const throw(std::exception);
>     bool is_dir() const throw();
>   };

Now what about Windows NT, where each directory entry might have two
names: a short one, and a long one? (and where you typically only want
to display one or the other, but not both?)

What about symbolic links which point to a directory? Should is_dir
return true or false for them?

How do you get the root directory? What about drive letters?

I don't actually want to get into a long debate about this specific
API, so there is no need to defend it - I just think that this (or
anything else in that area) would cause a lot of discussions, and
people would be unhappy, no matter what the outcome of the discussion
is.

Regards,
Martin
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Martin von Loewis wrote:
>
> "Ken Hagan" <K.Hagan@thermoteknix.co.uk> writes:
>
> > I would hold back on this one. If you want pthreads, you've already
> > got it. I would personally prefer to see more effort on separating the
> > core language from the library. (It isn't clear whether something like
> > std::uncaught_exception is implemented by the compiler vendor or
> > the library vendor.) Next after that would be some portable way of
> > navigating a directory tree.
>
> You'd have to define what a directory is, first. So if you want POSIX,
> you already gotit: readdir(3).

A directory is a persistent container of files and directories.
For each entry, it contains (at least) a name, and a way to get
on the entity (file or directory) connected with that name.

A simple interface could be:

namespace std
{
  class direntry
  {
  public:
    string name() const throw(std::exception);
    bool is_dir() const throw();
  };

  class directory
  {
  public:
    typedef (implementation defined) iterator;
    directory(string name) throw(std::exception);
    directory(direntry entry) throw(std::exception);
    ~directory() throw();
    iterator begin() const throw();
    iterator end() const throw();
    string name() const throw(std::exception);
    direntry find(string name) const; // see below
  };
}

where iterator::value_type is std::direntry.

directory::iterator would just be an input iterator
or maybe a forward iterator.

std::filebuf would get an additional constructor which
takes a std::direnty object.

If d is an object of type direntry, and d.is_dir() is false,
then std::filebuf(d) and std::filebuf(d.name().c_str())
should be equivalent.

If d is an object of type direntry, and d.is_dir() is true,
then std::directory(d) and std::directory(d.name().c_str())
should be equivalent.

On systems with no directories, creating a directory
object would always fail. On systems with directories,
the information provided with this interface should
always exist.

In addition, there should be a "C string" constant

namespace std
{
  char dirsep[];
}

which contains all allowed directory separators, with the
main separator (i.e. the one most commonly used) first.

That is, on Unix it would just be "/", on DOS, Win and OS/2
it would be "\\/", and on other systems it would be something
else. On systems not supporting directories, it would be
the empty string.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]