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

From: Vladimir Prus (ghost_at_[hidden])
Date: 2005-05-11 01:03:54

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