Re: [boost] Filesystem attributes

From: Dietmar Kuehl (dietmar_kuehl_at_[hidden])
Date: 2002-03-03 14:42:20

Hi,
Jan Langer wrote:

> but which ability has your opaque (perhaps i don't know what does opaque
> mean in this context) type a simple string doesn't have.

Looking up "opaque" at <http://dict.leo.org/> yields, amoung others,
the translation "blickdicht" which is a pretty good match. Basically,
it is a type which is just declared but not defined. The pimpl idiom
makes use of the same approach. Of course, it is defined somewhere but
this definition is only accessible to the implementer of component, not
to its users.

> why do you want to mix the identification of the file with the storage
> and access of its attributes. IMO the task of the property-map.

Don't confuse property maps with maps: A property map is basically a
facility which provides access to some properties of some entity. This
will most often just access members of the entity provides as key. It
may as well make a lookup as is done in 'std::map' but this is more an
exception than the rule.

For each file attribute, a unique property map is used. For the file
properties supported directly be the library, these property maps just
access a member of the otherwise opaque tpye. Internally, this stores
the result obtained from walking a directory (eg. with POSIX a 'DIR*')
and a cache for the file attributes (eg. with POSIX a 'struct stat').
The file name is just one of these attributes. The object of the opaque
type is the identification, not the file name.

>>The opaque type would be useful for users only as a key to corresponding
>>property maps accessing the various file attributes.
>>
> 
> yes, thats exactly what string should do in a posix impl..

No. That would be unnecessary ineffecient it would still be necessary
to store the directory walking status somewhere.

> in your
> implementation the dir_it always called stat to retrieve the file
> attributes but i think this is not needed.

If I'm really doing this in my implementation, then it is a bug. It
may be due to the desire to get a working implementation first and
improving performance later... I thought I had implemented a cache for
the file attributes. This is what should happen, however.
-- 
<mailto:dietmar_kuehl_at_[hidden]> <http://www.dietmar-kuehl.de/>
Phaidros eaSE - Easy Software Engineering: <http://www.phaidros.com/>