Boost logo

Boost :

From: Beman Dawes (bdawes_at_[hidden])
Date: 2002-02-25 10:39:34

At 01:32 AM 2/25/2002, mfdylan wrote:

>> >>bool move(name_t source, name_t dest);
>> Not sure if this should be called rename or move. Specs need to be
>> out if the target is a different volume than source.
>move is generic enough to cover both, IMO.

That's the trouble with "move"; it is so generic it can be confusing. But
it is certainly OK for now as a working name.

> Under POSIX it would mean
>calling rename() and if that fails, copy then remove. NT
>has "MoveFile" has builtin.

I know, but the question isn't how to implement on specific systems, but
how to specify in a way that will be portable to most operating systems.

>> >>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
>But absolutely necessarily. You can't implement absolute() with it.

How absolute() does its job internally is an implementation detail; that
isn't a good argument for exposing getcwd/chdir.

>I guess if the only access to the current working dir is by calling
>absolute(".") I'd live with it but I wouldn't be happy.
>chdir is useful for a few limited purposes, as long as you ensure all
>relative paths are kept to one thread. It's also useful when forking
>child processes, but in that case you need a specialised interface,
>because under NT you have to do it quite differently. I already
>started work on a class for forking subprocesses, not sure if I
>posted anything here.

Everything you at talking about is non-portable. "." for example. Fine if
you want to do that in your own program, but I'd like that sort of
non-portable thinking not to seep into the interface.

>> >>[permission details]
>> >
>> >these should be implemented as attributes but since we actually
>> >know which attributes should be supported at all and which
>> >of accessing them is used, its too early to think about details.
>> Agreed. Rather than proposing signatures, work on filling out
>> attribute table is what is needed now.
>We still need agreement on what form owners and groups should take.
>I just finally completed my code for properly determining the fully
>qualified owner and groupname for *any* file, and as far as I can
>tell, you actually need the filename in order to do it. It's over
>200+ lines of code ...

I'm not ready to think in terms of code yet; I don't fully understand the
attribute/permissions/etc requirements yet.

>> >
>> >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.
>I thought about that but do we want/need that sort of dependency?

Reinventing a common need may cut dependencies, but that isn't likely to
fly with something as basic as time, IMO.


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