RE: [boost] Filesystem attributes

From: Jan Langer (jan_at_[hidden])
Date: 2002-03-03 08:14:40

On Sat, 2 Mar 2002, Jeff Garland wrote:
>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.

i thought a little while about the relation between attributes and
iterator. but i failed to put dietmars opinion into this scheme. this is
the result, let me know if i'm totally wrong:

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).

>> 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.

-- 
jan langer ... jan_at_[hidden]
"pi ist genau drei"