From: Beman Dawes (bdawes_at_[hidden])
Date: 2005-06-08 21:48:39
"Vladimir Prus" <ghost_at_[hidden]> wrote in message
> On Thursday 19 May 2005 01:26, Beman Dawes wrote:
>>... 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
>> >convertion on plain char* and whar_t* pointers. I find this somewhat
>> >to believe.
>> Windows, for one.
> Could you be more specific? Which transformation done by the filesystem
> be approximated with the call to MultiByteToWideChar or
It is the "approximated" that is the concern. An approximately correct path
isn't good enough. Users expect exact rather than approximate behavior.
>> Although that is really beside the point. The worry is
>> the need for conversions when a path changes from wide to narrow, or visa
> Why is it a worry?
Some conversions are lossy. That is, they are not full reversible. So on
unnecessary round trip can lose data.
>> >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,
>> 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,
> converts all user-provided paths into internal representation anyway. And
> isn't Java, that uses single-string type, works on such low-memory devices
> mobile phones?
Phones that support Java are hardly "low-memory" devices. Regardless, as the
cost of memory declines, what constitutes undue memory use changes. So you
are correct to point out that this is a minor and declining concern.
>> 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
> also templates", everybody will say.
There is a proposal outstanding to add std::string overloads to many of the
existing library classes. It isn't just the filesystem library than is
further entrenching std::basic_string in the standard.
If you want to argue for a runtime polymorphic string class that can change
it's internal representation as needed, that's fine. But the way to prove
the point is to develop and popularize such a class. Then a library like
Boost.Filesystem would have a base to build on. But it doesn't seem to me
that Boost.Filesystem is the place to do experiments with dynamically
>> >> >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
>> >> >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
>> >> >conversion, the library is unusable with other code that uses
>> >> >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.
> 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
> over time?
I do very much hear that argument, and find it a very strong argument
indeed. But I don't see that as a problem to be solved at the level of
Boost.Filesystem. Rather, a replacement for std::basic_string that offers
runtime polymorthic self-configuration and interoperability. That is the
place to start development IMO. Not in Boost.Filesystem. Boost.Filesystem is
an innocent bystander that simply uses the std::basic_string compile-time
polymorphism because that is the current standard.
>> >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
>> 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.
There is already an example of a user defined path based on strings of longs
(which was a real-world example mentioned by someone in the LWG).
I'll do another example, where the string type is std::wstring, but the
external encoding is user supplied.
>> 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,
> won't be possible to add yet another path type.
People sometimes argue that it is premature to standardize some library
component because a better one is just around the corner. The shared_ptr
proposal had to fight that battle, for example. The LWG evaluates each
proposal on its merits, as perceived at the time the proposal is considered.
Once in a very great while, a proposal comes along that is good enough to
cause removal of some component that was already accepted. The STL proposal
was good enough to justify the remove of a now-forgotten dynamic vector
called dynarray that was already voted in. If a much better string class
comes along, well, then a filesystem library will be one of many libraries
that will have to adapt to accommodate it.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk