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