ambiguity of operator<< in display_expr

[Maxim Yanchenko <Maxim.Yanchenko@…>]

from here: ​http://cpp-next.com/archive/2010/09/expressive-c-playing-with-syntax/comment-page-1/#comment-1134

struct A {};
struct B:A {};
std::ostream& operator<<( std::ostream& out, const A& ) { return out << "this is A!"; }

If you do

proto::display_expr( map( A(), 1 ) );

it works, but if you do

proto::display_expr( map( B(), 1 ) );

it doesn't compile due to ambiguity introduced by hidden_detail_::operator<< that does this nice typeid output.

The patch for boost/proto/debug.hpp against 1.44.0 (works for me) and last revision 66440 (not tried to compile, just by analogy) is attached.

[Maxim Yanchenko <Maxim.Yanchenko@…>]

patch against 1.44.0

[Maxim Yanchenko <Maxim.Yanchenko@…>]

patch against rev. 66440

[Maxim Yanchenko <Maxim.Yanchenko@…>]

patch against 1.44.0

[Maxim Yanchenko <Maxim.Yanchenko@…>]

patch against rev. 66440

[Maxim Yanchenko <Maxim.Yanchenko@…>]

The patches <xxx>.2.patch are slightly simpler and cleaner than the first submitted (can't delete them myself, so please feel free to delete). There is a self-written has_ostream_shift<T> trait, not sure if we already have one in Boost. If so, please feel free to replace with the blessed one.

[Eric Niebler]

Attempted fix in [67366]. Let's see how the new display_expr tests fare on trunk.

[Peter Schüller <schueller.p@…>]

sorry to say that, but [67366] broke something:

define the following function inline solves the problem (line 105 in debug.hpp):

        inline std::ostream &operator <<(ostream_wrapper sout_wrap, named_any t)

otherwise I get duplicate symbol definitions if I use spirit in two compilation units:

/...path.../proto/debug.hpp:105: multiple definition of `boost::proto::hidden_detail_::operator<<(boost::proto::hidden_detail_::ostream_wrapper, boost::proto::hidden_detail_::named_any)'

[Eric Niebler]

oops. should be fixed in [67386]

[Eric Niebler]

(In [67387]) fix ambiguity in display_expr, fixes #4910