On Wed, Feb 18, 2009 at 2:47 PM, Andrey Semashev <andrey.semashev@gmail.com> 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