Boost logo

Boost :

From: Beman Dawes (bdawes_at_[hidden])
Date: 2002-02-24 21:01:27

At 09:22 AM 2/24/2002, Jan Langer wrote:

>On Sat, 23 Feb 2002, Beman Dawes wrote:
>> >davlet_panech mentioned a class syscall_error. i think this is quite
>> >useful since
>> >"Unless otherwise specified, operations throw exceptions if they do
>> >not complete successfully."
>> >and there is already such a class in the dir_it package.
>>Yes. I'm using the syscall_error (renamed filesystem_error) class from
>>dir_it in my experiments. I moved it to its own header. (I've also
>>renamed dir_it -> directory_iterator.)
>ok, can you provide the filesystem_error header so that i can use it
>too. since its a quite obvious class it should hardly be changed.

I've emailed the files to you privatedly.

>> >in the document it says "A standard set of attributes is encouraged."
>> >i tried to address this in
>> >
>> >but noone was interested in discussing it :-(
>>I'm very interested in it, but didn't feel I could discuss it (or dir_it

>>several pathname postings) without first understanding the overall
>>requirements and goals. If it looks like the way we want to go, I'll
>>with the Win32 implementation.
>>I've also been trying to understand the Boost Property Map Library
>> Have you
>>at that, and can you use it as mechanism?
>as far as i read its documentation it maps between objects. but the
>attributes should use a compiletime mechanism. but several changes need
>to be made to my current approach to fit the requirements.

My problem is that there seemed to be a lot of similarity between the two
approaches, but I just don't understand either well enough to know if you
should be using the property map stuff or not.

>what should be passed to the get?
>i would prefer a string with the meaning of path.

Yes, for sure. Perhaps there should also be a overload that takes a
directory_iterator, as discussed in other emails.

>is there a need for an type like dietmars dir_entry?

Not 100% sure yet, but right now I'd say no, at least as far as the public
interface. Keep it simple.

If you do provide a directory_iterator overload for get/set attributes,
there will be a need for internal communication. But should that be a
public interface? I'm not sure I can see any need.

>i think if everything is done with strings it isn't needed.
>but with such a type many performance issues can be solved (as you
>mentioned in your posting). if we need two attributes stat isn't called


>what should be returned by directory_iterator?
>path or name
>i'd prefer name because path can easily retrieved by compose.

Name. I'm very sure of that.

>is there another possible interface for accesssing attributes which
>should be considered?
>template <typename Attribute, typename C>
>Attribute::value_type get (std::basic_string <C> const &path)
> return Attribute::get (path);
>template <typename Attribute, typename C>
>void set (std::basic_string <C> const &path, Attribute::value_type
>const &v)
> Attribute::set (path, v);
>this allows easily to write user defined attributes and all the ugly
>performance relating and platfrom dependent things can be hidden in an
>attribute class.

I don't have a strong opinion on those issues yet. I'm really hoping
you'll continue to work on at least the attributes portion of the

>what about proper names for the functions you mentioned in the

I'll try to send you my first cut tomorrow.


Boost list run by bdawes at, gregod at, cpdaniel at, john at