RE: [boost] Filesystem attributes

From: Jeff Garland (jeff_at_[hidden])
Date: 2002-03-03 11:09:37

> there are three different things:
> 	(1) - an iterator, returning an object of type (2)
> 	(2) - an object to identify a file uniquely, constructed from
> string, be convertible to string
> 	(3) - an object which grants access to attributes, constructed from (2)
>
> jeffs and bemans approach is to mix (2) and (3) into one object and call
> it directory_entry. but they are right that the functionality of this
> object is essential. although it can be divided into two objects each
> taking a part of this functionality.
>
> my point of view is it to separate the three things and let (2) be of
> type string, since it is stated in the initial requirements that a
> string is the unique identifier for a file (with impl. defined format).

Ok, I see but there is still something missing -- I'll address that in response
to Dietmar....

> >> 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.
>
> why is is_graphic not portable. is we have previously defined an
> attribute is_graphic, it is very portable.

Perhaps.  It depends on the implementation.  If it peaks inside the file to
figure out the format than it may be possible to make this 'attribute' portable.
However, I'm not really discussing that case.  The case I'm interested in is
attributes retrieved from the operating system.  These are in general not
portable.  So if the OS provides a way to add an attribute called is_graphic and
have programs get/set it without accessing the file contents then this code is
clearly non-portable.

Jeff