Re: [boost] Re: Design for a file system library

From: Jan Langer (jan_at_[hidden])
Date: 2002-02-24 09:22:19

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.

> >in the document it says "A standard set of attributes is encouraged."
> >i tried to address this in
> >http://groups.yahoo.com/group/boost/files/filesystem/Attributes.html
> >but noone was interested in discussing it :-(
>
>I'm very interested in it, but didn't feel I could discuss it (or dir_it or
>several pathname postings) without first understanding the overall design
>requirements and goals.  If it looks like the way we want to go, I'll help
>with the Win32 implementation.
>
>I've also been trying to understand the Boost Property Map Library
>http://www.boost.org/libs/property_map/property_map.html.  Have you looked
>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.

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

is there a need for an type like dietmars dir_entry?
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
twice.

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

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.

what about proper names for the functions you mentioned in the
requirements?

-- 
jan langer ... jan_at_[hidden]
"pi ist genau drei"