From: Jan Langer (jan_at_[hidden])
Date: 2002-03-02 14:24:37
On Sat, 2 Mar 2002, Beman Dawes wrote:
> >>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 "*"
>(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
i do also think that (1) is the best candidate of this three but not the
best at all.
> >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.
you mentioned the pathname as a member of directory_entry but i think
this is a property which is not needed. a function absolute() will do
the same and is useful for several other things.
foo (absolute (*itr));
or foo (compose (dir, *itr));
and pathname is actually no real property like size or is_directory. it
can also be part of the iterator itself. i think the public interface of
directory_entry would grow too large if all required attributes have
their own member-function (perhaps with some require and commit
foo (itr.pathname ());
another point is expensiveness. there is no way to do a simple and cheap
find operation in a directory like
std::find (begin, end, "file");
because on every iteration cycle a probable large property-map-objekt
must be build and destructed.
in general i think we should keep the four things
- file ops
- path ops
as much seperated from each other as possible. the user will be forced
to write a bit more but the design will be clearer and easier to learn.
of course i am not an experienced library programmer. i'm actually no
real programmer at all. though i will accept the result of the
discussion anyway because i trust in your experience but i'm not really
-- jan langer ... jan_at_[hidden] "pi ist genau drei"
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk