Boost logo

Boost :

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
>>> submissions? See their entries in
>>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
>>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
>>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; }
>> 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.


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