Re: [Boost-users] [Proto] Vector Example Compilation Failure

Subject: Re: [Boost-users] [Proto] Vector Example Compilation Failure
From: Eric Niebler (eric_at_[hidden])
Date: 2011-01-03 09:59:03

On 1/2/2011 8:00 PM, Hossein Haeri wrote:
> Hi Erik,
> 
>> This is the same problem as last time, although you would need to
>> dig into BOOST_PROTO_DEFINE_OPERATORS to know that.
> 
> I see. Would it be too much trouble to ask for an explanation on how
> you got there from the compiler spew?

This was the error I got:

In instantiation of ‘std::_Vector_base<boost::proto::wildcardns_::_,
boost::proto::wildcardns_::_>’:
...
error: no class template named ‘rebind’ in ‘struct
boost::proto::wildcardns_::_’

That's saying that std::vector<_, _> cannot be instantiated, and it's
true because _ is not a valid STL allocator. std::vector<_, _> is a
valid Proto grammar element and if Proto is working as it should, that
type should not be instantiated. But it is. So it's the same problem as
last time.

Looking more closely, I see this in the instantiation backtrace:

5:   instantiated from ‘std::vector<boost::proto::wildcardns_::_,
boost::proto::wildcardns_::_>’
‘const int
boost::mpl::aux::template_arity_impl<std::vector<boost::proto::wildcardns_::_,
boost::proto::wildcardns_::_>, 1>::value’

This is very interesting. MPL's template_arity_impl should not be
causing the template instantiation. That makes me think the problem lies
there and not in Proto. That would make sense, since I don't ever
remember fixing this problem. You should check to see if newer versions
of Boost have a different implementation of template_arity_impl. Working
around the problem might be as simple as copying the new implementation.
This would be a very small and localized change.

>> I don't think gcc-4.5 was available when Boost 1.42 was released,
>> so it's not surprising there are problems. Would it be possible for
>> you to use a more recent version of Boost?
> 
> It would be a pain 'cause I need to port a lot of things. (Proto is
> not the only part of Boost that we use.) Anyhow, the bigger pain is
> that I have no much clue about Proto error messages and our company
> is committed to be a long-term user of Proto. Therefore, learning how
> to demystify Proto error messages is of much importance to me and I'm
> ready to pay the porting price if that's what it takes. :D But,
> seriously, have you ever thought of including a section or two on how
> to do that in the Proto documentation?

I'm afraid there is little I can tell you to help in the general case.
If there is a bug in Proto, or in MPL, or in GCC, you're going to get a
whopper of an error. In this particular case, a little extra knowledge
of how C++ templates work would have served you well. You can see the
type std::vector<_,_> in the error and know that it's not a valid
instantiation. The tricky part is that realizing that it's OK to
/mention/ this type (as Proto does) as long as you don't instantiate it.
If it gets instantiated, it's a bug.

Realizing it's a bug is the first step. Tracking it down usually goes
like this:

1) Examine the backtrace to see where it's coming from. In this case,
from template_arity_impl which, unfortunately for you, is an
undocumented implementation detail of MPL.
2) Preprocess the code first and compile it. That helps to see through
macros like BOOST_PROTO_DEFINE_OPERATORS.
3) If all else fails, post a question here. I'll help if I at all can,
and if not maybe someone else will.

> The other (sort of related) thing is that it's come to my attention
> that Fusion knowledge comes very handy in Proto development. 

Often times, yes.

> This is
> though not encouraged at all and I don't really think that the
> documentations of Fusion and Proto are that nicely tied.

Suggestions for improvement are welcome.

-- 
Eric Niebler
BoostPro Computing
http://www.boostpro.com