Emil Dotchevski wrote:
> On Fri, Jul 4, 2008 at 2:14 PM, Sebastian Redl
> <sebastian.redl@getdesigned.at> wrote:
>> Emil Dotchevski wrote:
>>> What is the rationale for providing path and wpath types instead of
>>> using a single path type?
>> 1) Narrow encoding paths always existed, because the fstreams took narrow
>> strings.
>> 2) wpath was added later by request, I believe. Also, because the narrow
>> encoding under Windows is never UTF-8 and thus can't ever represent all
>> paths, and the NT and CE kernels natively use UTF-16 (wide characters).
> 
> Yes, we need the ability for path objects to store "narrow" and
> unicode strings, and the ability to talk to the OS. This can be
> achieved by a single path type and a few conversion functions, can it
> not?

Yes.

Peter Dimov made that suggestion several years ago, and I've been 
thinking about it ever since. There was just recently a brief discussion 
of it on one of the C++ committee mailing lists. I want to tackle the 
design in the context of a unicode string that would then be used by 
path. Peter thinks it would be better to tackle the path problem in 
isolation.

But I won't have time to work on such a design until after the C++0x 
standard work slacks off. That should happen in the next three to twelve 
months, depending on when the committee actually decides to declare 
C++0x feature complete and ship a committee draft (CD) for public comment.

--Beman