Subject: Re: [boost] Formal Review Request: Boost.String.Convert
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2009-02-18 17:56:08
On Wed, Feb 18, 2009 at 2:47 PM, Andrey Semashev
> Emil Dotchevski wrote:
>>>>> And what if I write my own class outer_bar that owns bar and also want
>>>>> ostreamable? I would have to duplicate my operator<< in order to call
>>>>> to_string or to_wstring, wouldn't I?
>>>> You can define template operator<<
>>> How is that?
>> What do you mean how? You just define a template operator<< and the
>> library-supplied to_string/to_wstring templates will bind to it,
>> assuming the user's calls to_string or to_wstring doesn't bind to a
>> better overload of to_string/to_wstring.
> Which of the to_string/to_wstring functions should I call from the
> operator<< template?
If all you want is to implement operator<< template in terms of
to_string/to_wstring, you won't have to do that because the library
will do it for you. That is, if I give you a foo overload of to_string
only, but you want to use operator<< for foo, all you'd have to do is
include the appropriate header from the library and foo.hpp, and then
you can call operator<< as needed, which in this case will forward
your call to to_string.
>>>> or you can define non-template
>>>> std::string overload of operator<< only. The user would still be able
>>>> to call to_wstring, which will bind to a wstring overload if it's
>>>> available. If not, the generic to_wstring overload will call the
>>>> std::string operator<< overload, and then convert the result to
>>> But I will lose generic ostreamability for my class then.
>> Even that's not necessarily true, as the library can provide generic
>> ostream template operator<< overload that's implemented in terms of
>> to_wstring or to_string or other available operator<< overloads.
> It looks like you suggest that the library should implement wide streaming
> capability for all classes that it can reach (i.e. those have the narrow
> operator<<). Somehow, I don't quite like that kind of a "helping hand". I
> suspect it may introduce problems with efficiency, as it will have to
> unnecessarily transcode strings.
If this inefficiency is a problem, it can be easily addressed by
introducing the appropriate optimal overloads. If not, you're arguing
Reverge Studios, Inc.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk