RE: [boost] Filesystem attributes

From: Jeff Garland (jeff_at_[hidden])
Date: 2002-03-02 22:08:38

> From: Dietmar Kuehl [mailto:dietmar_kuehl_at_[hidden]]
> Hi,
> Beman Dawes wrote:
>
> >       foo( get<pathname>( itr ) );  // ugly for required attributes.
> >       foo( itr->pathname() );       // better
>
>
> Position and property access are two orthogonal things which should
> not be lumped into just one entity! Most of the problems concerning
> iterators in the standard library are from the misconception that
> iterators should do both positioning and property access: The standard
> iterators are implementing two completely separate concepts.
> You are doing the same to the directory iterator. I think this is rather
> wrong, especially as the set of attributes applicable to things like
> directory entries is not at all fixed!

Maybe I'm missing something fundamental, but an iterator needs to point at some
sort of type.  All Beman is suggesting is that the type be something like the
following(forgeting the templated string for a minute):

  //fundamental capabilities of all directory entries
  class directory_entry
  {
   public:
    std::string pathname() const;
    std::string filename() const;
    bool is_directory() const;
  };

My point from day 1 in this thread is that something like the above are the bare
essential required for portable programming with directories and files and
therefore I believe clear justification for keeping them apart from the
remaining optional properties.

> For example, I would consider it
> reasonable to define a file attribute "is_graphic" for an application
> dealing with graphics objects (jpegs, gifs, etc.). Do you really
> consider it better to do something like this
>
>    if ( get<is_graphic>( itr ) ) // is_graphic(itr), ...
>      process( itr->pathname() );
>
> than
>
>    if ( get<is_graphic>( itr ) )
>       process( get<pathname>( itr ) );

I suppose either would be fine, but the difference makes the non-portable code
( get<is_graphic> ) stand out.

> The reason that the directory iterator has a value type at all is just
> that iterators [falsely] need value types in the first place! The file's
> name is more or less an arbitrary choice which comes in handy for simple

The name is still a string value, no?

> > 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.
>
>
> Iterators confuse two separate concepts! Separating property access from
> object identification clears things up. Of course, everybody is now used
> to iterators confusing these two things liberally but this should be
> corrected since it causes all kinds of problems. To me the only question
> is how the interface is effectively supposed to look like. The question
> is not whether iterators and property maps should be separated: That's a
> given! For me, at least...

Again, I don't see the confusion since the object provides the property access
not the iterator.  There is another factor here that I think we are forgetting.
The pure functional approach is going to need to access the disk again for each
property lookup since the only thing the iterator can hold is the name.  As a
result, performance will certainly suffer.  It would be really nifty if a
programmer could customize at compile time the properties retrieved with each
direntry....

Jeff