Re: [boost] [filesystem] i18n branch committed to CVS

From: Vladimir Prus (ghost_at_[hidden])
Date: 2005-06-03 07:13:03

On Thursday 19 May 2005 01:26, Beman Dawes wrote:

>  >> the operating system would be performed, and that the technical
>  >> complexity
>  >> was too great in relation to perceived benefits. User-defined types
>
> would
>
>  >> only make the problem worse.
>  >
>  >I think this statement is not proved. Essentially, you are saying that
>  >there's
>  >an operating system that performs some char->wchar and wchar->char
>  >convertions in path operations, but does not provide any API to do the
>
> same
>
>  >convertion on plain char* and whar_t* pointers. I find this somewhat hard
>  >to believe.
>
> Windows, for one. 

Could you be more specific? Which transformation done by the filesystem can't
be approximated with the call to MultiByteToWideChar or WideCharToMultiByte?

> Although that is really beside the point. The worry is 
> the need for conversions when a path changes from wide to narrow, or visa
> versa.

Why is it a worry? 

>  >I disagree. Consider that your current design does not allow to mix
>  >different
>  >path types at all. So, we should evaluate the performance of single path
>  >design only for the case where char/wchar_t are never fixed -- that is
>
> all
>                                                         ^^^^^ mixed?

Yes, "mixed".

>  >paths are created either from char, or from wchar_t.
>  >
>  >Then, the memory overhead is a single bool flag, telling if a path was
>  >created from char or whar_t.
>
> The memory overhead I was worried about wasn't user space for the bool, but
> the need to link in both narrow and wide versions of functions,
> particularly on low memory embedded systems.

Do you have the specifics? What OS/hardware do you have in mind? IIRC, Windows
converts all user-provided paths into internal representation anyway. And 
isn't Java, that uses single-string type, works on such low-memory devices as 
mobile phones?

> string
>
>  >type.
>
> A lot of people say they don't like the std::string design, but it is the
> standard for C++. Perhaps someday another string design will become
> popular, but that isn't even on the horizon AFAIKS.

And if boost::path is accepted into standard as templated class, then
any new string class will have even fewer chances. "Look, the path class is 
also templates", everybody will say.

>  >>  >Also I note that there's no conversion from basic_path<char> to
>  >>  >basic_path<wchar_t> or vice versa, as far as I can say. To recall my
>  >>  >argument
>  >>  >for conversion: say I have a library which exposes paths in the
>  >>
>  >> interface,
>  >>
>  >>  >should I use path or wpath in it? If I use path, then due to missing
>  >>  >conversion, the library is unusable with other code that uses wpath.
>
> So
>
>  >>  >I need to use wpath.
>
> Yes. It is the same situation as with std::string vs std::wstring. If you
> think your app may sometimes have to deal correctly with wide strings (or
> paths) you should use std::wstring (and wpath).

I keep on making the same argument over and over, but you don't hear it. If
I'm writing a library, I have no idea what kind of string the applications
will pass to the library. And BTW, what if application's requirements change
over time?

>  >Even if I provide both types in the interface, if there's no standard
>  >path<->wpath conversion, I'll have to either:
>  >
>  >- write such convertion myself
>  >- duplicate all code of the library -- for path and for wpath
>
> Partially in answer this very valid concern, I've exposed the wpath_traits
> conversion interface. I'm not sure that is a complete solution, but at
> least you wouldn't have to write the conversion code yourself.

Well, I don't understand how to use it. Can you stetck the code code to 
convert path to wpath and vice versa? The wpath_traits code seem to deal
with strings only.

> Please note that I'm not saying a single-path-type design is dumb or
> anything like that. It is just that it would be too big a leap without a
> lot of experimentation, trial use, etc. 

Then, probably it's too early to standardize boost::path. After it's in, it 
won't be possible to add yet another path type.

- Volodya