Boost logo

Boost :

From: Keith Burton (kb_at_[hidden])
Date: 2002-09-20 09:10:45

-----Original Message-----
From: boost-bounces_at_[hidden]
[mailto:boost-bounces_at_[hidden]] On Behalf Of Vladimir Prus
Sent: 20 September 2002 12:54
To: boost_at_[hidden]
Subject: Re: [boost] Filesystem Library: Formal Review

>Keith Burton wrote:
>> If one uses
>> string relative_path("libs/locale");
>> that is a relative path is remains a string until converted to a (
>> absolute ) path. The conversion to absolute can be relative to any
>> absolute path.
> path x(...) ;
> string relative_path("libs/locale");
> x << relative_path

>How will the third line work? Currently, relative_path will be
>to path, which will make it absolute in your scheme. Also, joining too
>relative paths will become less convenient.

Works correctly if operator << ( const string & ) is defined

> string relative_path("libs/locale");
> string relative_path2("ru_RU.KOI8-R");

> relative_path += "/" + relative_path2 ;

The requirement to compose / decompose relative paths is a limitation of
my approach. Is this a symptom of a real problem or a symptom of the
conventional view that relative and absolute paths are the same thing?
I obviously believe the latter and the problems caused by treating
relative and absolute paths as the same thing out way the need for a
change of mind set.

>> With regard to the UI , the absolute path may be unpleasant but it
>> also be the saviour as it explains why the operation failed if the
>> current directory was not as expected when the relative path was
>> converted to absolute.

>But the programmer should be able to choose, I think.

Agreed but as the programmer is in control and need not use the text of
default message I do not see a problem.

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