From: Beman Dawes (bdawes_at_[hidden])
Date: 2002-02-24 21:22:40
At 07:43 PM 2/24/2002, Jan Langer wrote:
>On Sun, 24 Feb 2002, mfdylan wrote:
>>--- In boost_at_y..., Beman Dawes <bdawes_at_a...> wrote:
>>> At 04:29 PM 2/23/2002, mfdylan wrote:
>>>
>>> Have you looked at the way attributes are handled in Dietmar's and
>>Jan's
>>> submissions? See their entries in
>>> http://groups.yahoo.com/group/boost/files/filesystem/
>>
>>Btw these are the functions I have currently. I like the idea of
>>unifying the attribute set/get interface however, so I will almost
>>definitely change this.
>
>i assume your name_t is just for simplicity and is actually
>basic_string.
>
>>bool exists(name_t name);
>
>i'm not sure whether this should be an attribute or a free function. the
>requirements say its a free function and i'd IMO prefer that.
It seems to me that it should be a free function.
The actual signature I'm assuming for all these free functions is the form:
template< typename CharT >
bool exists( const basic_string<CharT> & x );
Where x is path, dirpath, filepath, dirname, filename, or name, as defined
in the requirements. So for exists(), the argument is "path", since it can
be a directory or file path. The semantics are much clearer that way.
>>bool remove(name_t name);
No return. Should throw if error. Other than exists(), all the free
functions should throw on error.
>>bool move(name_t source, name_t dest);
Not sure if this should be called rename or move. Specs need to be worked
out if the target is a different volume than source.
>>bool mkdir(name_t name);
Let's use real names. make_directory in this case.
>>bool copy(name_t source, name_t dest);
Wasn't in the requirements, but probably useful enough to justify.
>>string_t getcwd();
>>bool chdir(name_t name);
No, not without a lot of discussion. Go back and read the
requirements. Globals are too evil to just casually toss into the hat.
>
>this seems to be a good set for the free functions for directory and
>file operations. some of them are already mentioned in the
>requirements. i am going to implement them for posix (its quite
>easy).
>
>>size_type size(name_t name);
>>bool readable(name_t name);
>>bool writeable(name_t name);
>>bool executable(name_t name);
>>time_type modified(name_t name);
>>time_type accessed(name_t name);
>>bool is_directory(name_t name);
>>bool chown(name_t name, string_t owner, string_t group);
>>bool chmod(name_t name, int mode);
>>string_t owner(name_t name);
>>string_t group(name_t name);
>>int mode(name_t name);
>
>>[permission details]
>
>these should be implemented as attributes but since we actually don't
>know which attributes should be supported at all and which mechanism
>of accessing them is used, its too early to think about details.
Agreed. Rather than proposing signatures, work on filling out Jan's
attribute table is what is needed now.
>>struct time_type
>>{
>> time_type(time_t secs = 0, long nsecs = 0) :
>> m_secs(secs), m_nsecs(nsecs)
>> { }
>> time_t seconds() const { return m_secs; }
>> long nanoseconds() const { return m_nsecs; }
>> operator time_t () const { return m_secs; }
>>private:
>> time_t m_secs;
>> long m_nsecs;
>>};
>
>why should nanoseconds be supported? i just don't have an opinion
>on this.
Seems like we should hold off on time until Jeff Garland and his group get
their time library proposal done.
--Beman