Boost logo

Boost :

From: Beman Dawes (bdawes_at_[hidden])
Date: 2002-03-01 14:23:46

I've just reviewed a series of helpful postings on attribute related issues
from Jan Langer, Jeff Garland, Dylan Nicholson, and Robert Stewart, re-read
Dietmar Kühl's dir_it documentation , and the Boost Property Map docs
(updated version in CVS).

For dir_it see

For updated version of Property Map, see*checkout*/boost/boost/libs/property_map/property_map.html?rev=1.12&content-type=text/plain


(The focus is on functionality, first, then usability.)

* The Attributes concept being discussed is very similar to Dietmar's
original basic_dir_entry. I'll call it directory_entry for ease of
discussion; that would actually be the typedef name for

Because a directory_entry contains all the detail attributes, it can be
created once and then queried/modified repeatedly, solving many of the bulk
read/write problems posed in discussions. A "commit" or similar function
is definitely needed to fully solve these problems. Since set() functions
would work on directory_entry rather than names, the fact that a
directory_entry commit() is needed to actually apply the attributes back to
the external directory will be much less surprising.

* In Dietmar's design, directory_entry was only related to a
directory_iterator by the fact that both use the same opaque representation
class. There was no containment or inheritance relationship. Since a
directory_entry couldn't be gotten from a directory_iterator, functions
such as set/get had to be overloaded for both. I found that part of the
design confusing. As we add additional functions, those overloads become
more of a problem, particularly if we need still more overloads to improve
usability. See below.

It seems to me other relationship alternatives are well worth exploring:
  (1) directory_entry is the value_type for a directory_iterator, or
  (2) a directory_entry is contained within a directory_iterator,
      and is publicly exposed, either directly or by access functions, or
  (3) a directory_iterator is inherited from directory_entry.

(1) is more in keeping with the usual practice. Both (1) and (3) ease
overloading functions (See next bullet). (3) saves having to write "*" to
get at the directory_entry from a style (1) iterator, and leaves "*" free
to be used to get just the filename.

* For many of the free functions like remove/move/etc, we will want to be
able to call with several argument types. Relationships 1, 2, and 3 each
need to be evaluated in terms of how complicated they make the overloading
of the free functions. The two argument functions may be the worst
cases, but for simplicity just consider:

    remove( "my_file" );
    remove( my_file_string );
    remove( my_dir_iter ); // or remove( *my_dir_iter ) with (1)
    remove( my_dir_entry ); // same overload as prior with (3)

* Unless I'm really missing something, the Boost Property Map Library
should be used at least for the tags and traits. If there is something
wrong with the Boost Property Map Library, we should fix it rather than
rolling our own. I personally dislike "get" and "set" as function names,
preferring "property" for both, but that is a different issue.



Boost list run by bdawes at, gregod at, cpdaniel at, john at