The compiler keeps complaining it cannot understand one operator<< manipulator if it is in one order, but accepts it if it is in a different order or statement. But the error code is cryptic, it finds the correct function signature among candidates but gets lost in a string of parenthesized signatures that make little sense because it does not say exactly where it got lost. So, this code passes well:

HWND h = NULL;
box << manipulator(h);

This chain also passes well:

HWND h = NULL;
char *XXX = "";
box << manipulator(h) << XXX;

But this code fails:

HWND h = NULL;
char *XXX = "";
box << XXX << manipulator(h);//different chain order OK!

In general it gives error or passes dependending on the order of insertions when order of insertions (and objects inserted) should not matter.

It would be easier if the compiler gives a clearer error code, but as it stands the compiler is even trying to synthesize an operator+ and includes a coma (,) operator.

no match for 'operator<<' in 'std::operator<< [with _Traits = std::char_traits<char>](((std::basic_ostream<char, std::char_traits<char> >&)((std::basic_ostream<char, std::char_traits<char> >*)(&box))), ((const char*)XXX)) << manipulator [with typet = HWND__*](h)'

Can anyone explain what is the compiler trying to say here?

What does your manipulator look like?

8}

template<class typet> manipulator_omanip<typet> manipulator(typet __c);
box& operator<<(box &os, manipulator_omanip<HWND> m);

This is another failure example:

HWND h = NULL;
char *XXX = "";
box << XXX << 1 << h << manipulator(h);

And this is the error message:

no match for 'operator<<' in '(+(+std::operator<< 
[with _Traits = std::char_traits<char>]
(((std::basic_ostream<char, std::char_traits<char> >&)
((std::basic_ostream<char, std::char_traits<char> >*)(&box))), 
((const char*)XXX)))->std::basic_ostream<_CharT, _Traits>::operator<< 
[with _CharT = char, _Traits = std::char_traits<char>]
(1))->std::basic_ostream<_CharT, _Traits>::operator<< 
[with _CharT = char, _Traits = std::char_traits<char>]
(((const void*)((void*)h))) << shower(typet) [with typet = HWND__*]()'

You can see how the error message begins with prefix (+(+std::... It seems the compiler is trying to synthesize an operator+ method! box is derived from ostrstream, so basic type insertors operator<< are already defined. There are also two -> operators, but all pointers are implicit and char * should be interpreted not as a pointer to object but as a basic type. So it seems the compiler is outputting directly a expression tree but after it already went through the wrong path. I do not find a way to parse this tree to make sense of where is it that the compiler takes the wrong path. Then follows a long list of candidate operator<< methods, including those of all classes with an operator<< defined, and the correct signature for the insertor it should invoke:

box& operator<<(box&, manipulator_omanip<HWND__*>)

Overall it looks like the compiler is getting lost after finding the correct signature and discarding it, so it would be a bug in the compiler nonetheless, but it also seems that it may be expecting some additional declaration to patch the declaration form the correct expression tree. It is desirable to be able to use the manipulator with argument as the last operation in the statement to control the statement flush dynamically on the same object box, and to be able to call all the insertions in a single statement to simplify if/else logic. As is the scheme is usable but only breaking the insertion statement into different statements.

This article has been dead for over six months. Start a new discussion instead.