Re: [boost] Formal Review Request: Boost.String.Convert

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
<andrey.semashev_at_[hidden]> wrote:
> Emil Dotchevski wrote:
>
>>>>> And what if I write my own class outer_bar that owns bar and also want
>>>>> to
>>>>> be
>>>>> ostreamable? I would have to duplicate my operator<< in order to call
>>>>> either
>>>>> to_string or to_wstring, wouldn't I?
>>>>
>>>> No.
>>>>
>>>> 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
>>>> wstring.
>>>
>>> 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
premature optimization.

Emil Dotchevski
Reverge Studios, Inc.
http://www.revergestudios.com/reblog/index.php?n=ReCode