|
Boost : |
From: Beman Dawes (bdawes_at_[hidden])
Date: 2004-11-12 20:40:13
At 06:53 PM 11/12/2004, Peter Dimov wrote:
>Beman Dawes wrote:
>> At 02:26 PM 11/12/2004, Peter Dimov wrote:
>>
>>> I still don't get it. I guess that we need code. Either way, it is
>>> the user doing the conversion. They aren't helped one bit.
>>
>> Yes, either way the user has to supply the conversion code. But
>> without direct support, the user must call that code manually (or
>> more likely in a user written wrapper.) But if path directly supports
>> user conversions, then the conversion functions are called
>> automatically by path objects when needed, and that is a win for the
>> user.
>
>Let's illustrate this with an example. I have a path type X that stores
>UTF-8 and a path type Y that stores Shift-JIS, both are instantiations of
>basic_path<char, Tr> for some TrX and TrY.
>
>How do you envision the conversion being called (a converting
constructor,
>explicit, implicit, a dedicated function) and which of TrX and TrY will
be
>used for the conversion?
My prototype looks like this:
template< class String > class basic_path ...
{
public:
basic_path( const String & ); // uses default for path_traits<String>
basic_path( const String &, conversion_object ); // imbue non-default
...
(I've vague on type of conversion_object because it is still in flux)
So this design does not have any way to mix Shift-JIS and UTF-8.
The single path class design would allow mixing the two. In that design
conversion occurs at the time individual elements are appended, so
whichever conversions are in effect at the time are applied.
path p( L"..." ); // default UTF-8 in effect
p.imbue( Shift-JIS conversion ); // exact form undecided as of yet
p /= L"..."; // the leaf will be Shift-JIS encoded
The single path class design is more flexible.
--Beman
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk