Re: How to build a string on the fly, using std::ostringstream? [Reposting]

On Apr 26, 3:46 pm, Niels Dekker - no return address
<nore...@[EMAIL PROTECTED]
> wrote:
>>     inline S& operator << (const T& v) {
>>       using ::operator <<; // Note: Ugly disambiguation.
>> [...]
>> This works for me in practice. But you may stumble into problems
>> caused by less-than-perfect forwarding (e.g. ambiguities).
>
> Can you please explain?

The problem is lookup. The application of the << operator inside my
template doesn't cause the same lookup as if it where applied directly
to the stream at the user call site. The operator calls happen in two
different scopes where different entities may be visible.

Usually this isn't a problem though since well-designed operator
overloads rely on argument-dependent lookup (ADL) to find the right
overload; i.e. by putting the operator overload in the same namespace
as the argument type.

It is only a problem where using a stream directly would also cause a
lookup failure. But, while explicit using declarations would solve the
problem in the latter case, it has no effect with my proxy class. For
example,

   using foo::bar::operator <<;
   ostringstream os; os << foo::t (); // ok
   string s = S () << foo::t (); // error

Here the S::operator << implementation will fail to find the
foo::bar::operator << overload for foo::t while direct application
will.

My using ::operator << declaration alleviates the problem in some
cases only, i.e. when the operator can be found in the global
namespace. I went back and looked closer at the particular places in
my code where it was needed, and I've now found better solutions. I
have thus removed the using declaration.

There may also be cases where the operator is ambiguous inside S while
not in the client scope. I've seen this in places where I had many
namespaces opened. More explicit namespace usage resolved the
problems.

> All I can think of is getting into troubles,
> because of an operator<< overload that would have a non-const reference

Sorry, bad use of terminology on my part. I was thinking about lookup
and not argument forwarding. There are solutions to argument
forwarding (such as adding more operator overloads to S). So far I've
not found it an issue; even with that simple single overload.

Regards,
Vidar Hasfjord

-- 
      [ See http://www.gotw.ca/resources/clcm.htm
for info about ]
      [ comp.lang.c++.moderated.    First time posters: Do this! ]