Boost logo

Boost :

From: Beman Dawes (bdawes_at_[hidden])
Date: 2008-07-05 07:33:24


Emil Dotchevski wrote:
> On Fri, Jul 4, 2008 at 2:14 PM, Sebastian Redl
> <sebastian.redl_at_[hidden]> 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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk