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

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
 >> >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.

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
 >twice.

Agreed.

 >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 
submission.

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

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

--Beman