On Monday 02 May 2005 16:59, Beman Dawes wrote:
I recall we had a long discussion concerning basic_path vs. single path type. I don't think results of that discussion are present in i18n.html >essentially, there's no rationale for going with basic_path.
OK, I'll add rationale. Here is a first draft:
During preliminary internationalization discussion on the Boost developer's list, a design was considered for a single path class which could hold either narrow or wide character based paths. That design was rejected because:
* There were technical issues with conversions when a narrow path was appended to a wide path, and visa versa. The concern was that double conversions could cause incorrect results, that conversions best left to 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. It might be true that std::locale cannot do the same conversion as OS's fs layer but: 1. It's a bug in std::locale design/implementation 2. You don't need to use std::locale, you can use OS API
* The design was, for many applications, an over-generalization with runtime memory and speed costs which would have to be paid for even when not needed.
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 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. No operating will need to do any conversion, so runtime overhead is just checking of that flag. I find this overhead very small, compared to the size of memory allocated for path, and the amount of work done by path method. Not to mention that a single OS call is likely to be 1000 times more expensive that this single comparison.
* There was concern that the design would be confusing to users, given that the standard library already uses single-value-type strings, rather than strings which morph value types as needed.
I don't think we should stick to std::string design, given that most environments with good Unicode support (Qt, Java, .Net) use a single string type.
>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. And so basically, all libraries need to use wpath >everywhere. So, why do you need path at all?
Applications which need wide-character internationalization will use wpath or other wide-character basic_path types. Applications which don't need wide-character internationalization will use path. Both are needed - they serve different user needs.
I think you're missing my point. Yes, the decision for application can probably me made. But if I'm writing a library I don't know if it will be used by application that needs wide paths, or application that does not need wide paths. I have to decide which path type to use in the interface (I'm talking about binary interface specifically). But if there's no path<->wpath convertion, then whatever type I choose, some applications will have troubles using the library, because they would not be able to convert between path types on the library boundary. 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 - Volodya