|
Boost : |
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
>times, etc.
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