Re: error: ambiguous overload for 'operator <<' in ...

[Bernd Strieder]

Hello,

glen wrote:

> On Thu, 26 Oct 2006 22:43:44 +0200, Ulrich Eckhardt wrote:
> 

>> Several things:
>> - You didn't provide a minimal example.
>> - You didn't provide the errormessage.
>> - The last semicolon is wrong.
>> - Your indentation is inconsistent, making it harder for the reader.
>> - Your code invokes undefined behaviour on an empty container.
>> 
>>> apparently it doesn't know what to do with a simple string
>> 
>> Well, anyways, your operator's signature matches _EVERYTHING_,
>> including a character literal.
>> 

> Thanks for pointing out everything I did wrong without giving me any
> help.  Much appreciated.

He did his very best to help you with all the information you gave.

> - the error message is in the subject line

What does an error message help, which is not reproducible?

> - sorry that the indentation was inconsistent
> - I provided an example.  It wasn't minimal enough for you?

How much work has to be done, before someone willing to help has
extended this example to a point, where your compiler run can be
reproduced? How much time do you expect somebody can offer?

> - Thanks for pointing out the empty container problem, that at least
> was a useful comment.

There were more useful comments, but without the exact piece of code in
a form compilable everywhere nobody will be able to help you, because
to help reproducing the exact problem is necessary in most cases.

> 
> Let me try again, this time with a sample which is not my code:
> 
> Code:
>   friend inline ostream& operator<<(ostream& os, const Range& range)
>     {
>       os << "Range("; // << range.first() << "," << range.last() <<
>       ","
>       //           << range.stride() << ")";
> 
>         return os;
>     }

This is again code which does not compile as is. There are missing
includes, there are missing class definitions, and whatever. It could
easily cost half an hour or more to get the code to a point, where
helping you might be possible. With a minimal complete example, you
might get precise answers within seconds.

Another important point of minimal examples is, that by creating one you
most often find the cause of the problem, yourself.

> 
> Error:
> /usr/include/blitz/range.h:173: error: ambiguous overload for
> $-1òøoperator<<òù in òøos << "Range("òù

You'd better check what you copy and paste. Better use output from the
compiler redirected into a file or from a plain shell. The error
message is completely worthless as is. Better give all information and
code to reproduce the error message.

The following long list of overload candidates is output to see, what
the compiler considered but failed to select one from. You get it
everytime there was a problem with that.

> /usr/lib/gcc/x86_64-redhat-linux/4.1.1/../../../../include/c++/4.1.1/bits/ostream.tcc:241:
> note: candidates are: std::basic_ostream<_CharT, _Traits>&
> std::basic_ostream<_CharT, _Traits>::operator<<(long int) [with _CharT
> = char, _Traits = std::char_traits<char>] <near match>
...
> /usr/lib/gcc/x86_64-redhat-linux/4.1.1/../../../../include/c++/4.1.1/bits/ostream.tcc:657:
> note:                 std::basic_ostream<_CharT, _Traits>&
> std::operator<<(std::basic_ostream<_CharT, _Traits>&, const _CharT*)
> [with _CharT = char, _Traits = std::char_traits<char>]

> 
> Does anyone know what is going on here?

I don't know exactly, because I cannot reproduce your problem. You have
to be careful with overloading operator<<, you have to regard the
overloads already existing. The STL contains ostream_iterator to output
the values of a range of iterators using std::copy. The pure existence
of this might suggest, that the people designing the STL have been
aware of the problem of printing the contents of a container, but
extending the streams-library in that direction has not been easily
possible, which is just what you are trying now.

So I think what you are trying is not an easy task, and you will
probably have to read quite a few books on templates and iostreams
before you can do anything properly in that direction, without banging
your head into concrete. I read books on extending the streams library
some years ago and decided to not start it. There is more to the
overall problem, than a few postings here can help with.

Bernd Strieder