Boost logo

Boost :

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

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