Boost logo

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, gregod at, cpdaniel at, john at