Boost logo

Boost :

Subject: Re: [boost] [filesystem] Version 3 request for comments
From: Beman Dawes (bdawes_at_[hidden])
Date: 2009-02-11 10:50:38


On Sun, Feb 8, 2009 at 5:12 AM, Walter Landry <wlandry_at_[hidden]> wrote:
> Beman Dawes <bdawes_at_[hidden]> wrote:
>> A prototype implementation of version 3 of Boost.Filesystem is available
>> for comment.
>
> This was also true in the old version, but one thing that bothers me
> is that the filesystem library defines a number of types:
> regular_file, directory_file, fifo_file, symlink_file, etc. Why does
> it append "_file" to the end of all of the names? Why is it not just
> regular_file, directory, fifo, symlink, etc.? The corresponding
> identification functions are named is_directory and is_symlink, which
> seems inconsistent.

It is inconsistent. _file was appended to avoid polluting the
namespace with enumeration constant names "regular", "directory", etc,
that might later be needed for other purposes.

In C++0x, the preferred practice for such constants is probably going
to be to use a scoped enum:

  enum class file_type
  {
    status_unknown,
    file_not_found,
    regular,
    directory,
    symlink,
    block,
    character,
    fifo,
    socket,
    type_unknown
  };

That's a lot more satisfying. We can emulate that approach in C++03 like this:

#ifndef BOOST_NO_SCOPED_ENUM

enum class file_type
{
    status_unknown,
    file_not_found,
    regular,
    directory,
    symlink,
    block,
    character,
    fifo,
    socket,
    type_unknown
};

typedef file_type file_type_enum;

#else
namespace file_type
{
  enum types
  {
    status_unknown,
    file_not_found,
    regular,
    directory,
    symlink,
    block,
    character,
    fifo,
    socket,
    type_unknown
  };
}

typedef file_type::types file_type_enum;
#endif

Is such a scoped enum approach worth taking?

I haven't made up my mind; I'd like to think about it for a few days
and also see what could be done to preserve existing code.

>
> Cheers,
> Walter Landry
> wlandry_at_[hidden]
>
> p.s. I noticed that you changed the names of "nlink" and "readlink" to
> the more clear names "hard_link_count" and "read_symlink". This might
> be needlessly confusing for those familiar with Unix, but even Ken
> Thompson said that, if he had to do it over again, he would have
> spelled "creat" with an "e" ;)

I really prefer the clearer names:-)

Thanks,

--Beman


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk