Boost logo

Boost :

From: Beman Dawes (bdawes_at_[hidden])
Date: 2004-11-12 16:16:32

At 02:26 PM 11/12/2004, Peter Dimov wrote:

>Beman Dawes wrote:

>> (probably
>> because their O/S just traffics in raw chars, yet they need a wide
>> character encoding.) These users would be helped a great deal by
>> custom conversions.
>I still don't get it. I guess that we need code. Either way, it is the
>doing the conversion. They aren't helped one bit.

Yes, either way the user has to supply the conversion code. But without
direct support, the user must call that code manually (or more likely in a
user written wrapper.) But if path directly supports user conversions, then
the conversion functions are called automatically by path objects when
needed, and that is a win for the user.

>We have two OSes in use today. Windows, which takes either path or wpath,

>and POSIX et al, which takes only a path. If the user wants to
use >something that is neither a path or a wpath, he must convert it to one

Yes. Or more exactly, to "native_path_string_type" which is an
implementation defined typedef, AFAWK, always to std:string or

>There is nothing the library can do, and providing smoke and mirrors just
>to make it _seem_ that other paths are supported, when in reality they
>simply are not, is both a disservice and a needless complication. IMO.

I don't understand why you say they aren't supported. Is it because the
user is supplying the conversion functions?

>> One case where a custom conversion is required is for a user defined
>> string type. There isn't any default; the user has to supply the
>> conversion.
>The user needs to convert the user-defined string type to either path or
>wpath. This is not something that the filesystem library can, or should,
>for him; a function can handle this conversion easily.

Yes, of course. The question is whether the user calls the function
directly, or passes it to the library so that the library will call the
function when needed.

> This use case does
>not imply that there must exist a basic_path for every basic_string,
>such a basic_path is not a filesystem path. The filesystem simply does
>take user-defined strings, never will, and no amount of traitification
>change that.

The filesystem operational functions never see the user-defined strings.
Conversion has already occurred. The operational functions are not
templated and only deal with the native_path_string_type.

>Either way, we need examples before we can move the discussion forward.

I'll post proof-of-concept level code, but it will be several weeks.


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