Subject: Re: [boost] Formal Review Request: Boost.String.Convert
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2009-02-18 17:47:00
Emil Dotchevski wrote:
>>>> And what if I write my own class outer_bar that owns bar and also want to
>>>> 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
>>> 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. It's difficult to make
any hard statements at this point, but I also have a gut feeling that it
may also introduce ambiguities between the library-provided and the
user-provided operators. I'd prefer using templates.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk