Boost logo

Boost :

From: Beman Dawes (bdawes_at_[hidden])
Date: 2002-03-02 10:58:07

At 07:41 AM 3/2/2002, Jan Langer wrote:

>On Fri, 1 Mar 2002, Beman Dawes wrote:
>>* In Dietmar's design, directory_entry was only related to a
>>directory_iterator by the fact that both use the same opaque
>>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
>>more of a problem, particularly if we need still more overloads to
>>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,
>> (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 "*"
>>get at the directory_entry from a style (1) iterator, and leaves "*"
>i would drop (3), because inheritance means an is-a-relation and an
>iterator is not a value-type but usually a pointer to a value type.
>>to be used to get just the filename.

(1) is really the only practical candidate, so please ignore the
others. Even if (3) works (and you may be right that it doesn't), it is
just too kinky for what should be a pretty pedestrian library. (2) results
in convoluted syntax ( "itr->directory_entry->filename()" rather than
"itr->filename()" for common usages, yet I can't see any offsetting

>please explain why there is a need for a relationship between
>directory_entry and directory_iterator at all.

If there is no public relationship, I see several problems:

* The model of a directory_iteratory iterating over only the filename seems
wrong to me. The attributes are attributes of the directory entry, not the
iterator. It more or less forces all directory_entry operations to be
performed as non-member functions, which seems limiting. For example, a
post from Jeff Garland pointed out that sometimes what is required from an
iterator is full pathname rather than filename. What could be more natural
than having both pathname() and filename() directory_entry members? There
is no natural way to do that with directory_iterator::value_type of just a
string returning the filename.

* Every library or user supplied function (remove, copy, move, foo, ...)
has to overload arguments on the iterator type (which I consider a burden
and unneeded complication), or failing that, force users to write uglier

      foo( get<pathname>( itr ) ); // ugly for required attributes.

      foo( itr->pathname() ); // better

* I'm guessing the "no relationship" model is harder for users to
understand. I know it confused me for a fairly long time, as I kept
looking for a relationship that wasn't there.

Your question is certainly valid; I don't think it is an open and shut
case. But to me iterators should just iterate and be dereferenced; they
shouldn't also be a direct gateway to attribute property maps. That's
confusing two separate concepts.


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