From: Jan Langer (jan_at_[hidden])
Date: 2002-03-03 12:55:39
On Sun, 3 Mar 2002, Dietmar Kuehl wrote:
>> i think thats a possible solution. this opaque type should be impl.
>> defined and act nearly like a string.
>No! It shall be impossible to act directly on this type: That's
>effectively a consequence of being opaque anyway :-) That is, the
>type is only declared in user visible headers. It definition resides
>in private implementation files for the directory iterator and the
>directory entry. One major benefit of this hiding is that operating
>system specific declaration do not leak into user's applications.
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.
>> so the posix impl. can typedef it to string, because the name is the
>> only attribute related information one usually gets during iteration
>> (except the inode number and a unusable type information)
>It shall hold the file attributes. The file name is just one of these.
>There is other data like access permissions, file type, size, access
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.
>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.. in your
implementation the dir_it always called stat to retrieve the file
attributes but i think this is not needed.
-- 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