Re: [Boost-users] [Proto] Vector Example Compilation Failure
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?
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? The other (sort of related) thing is that it's come to my attention that Fusion knowledge comes very handy in Proto development. This is though not encouraged at all and I don't really think that the documentations of Fusion and Proto are that nicely tied. TIA, --Hossein
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
Hi Erik, Thank you very much for the nice explanation. :)
I'm afraid there is little I can tell you to help in the general case.
You don't need to be that general then. Why not having a section which provides bullet-points like: "If you get an instantiation message for ..., then that's a bug because that certain MPL beast is only supposed to be checked without instantiation"? This would perhaps not result in a fully-fledged FAQ, but, it's a collection of tips with the same spirit.
2) Preprocess the code first and compile it.
Hmmm... How do I do that?
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.
Sure. Here are some suggestions: 1) Every now and then in the Proto documentation, you can add a short intermezzo which explains which Fusion creature is used in that specific point and how. 2) You might want to state Fusion as a pre-requisite for proper Proto knowledge. 3) After "Getting Started" and before "Fronts Ends...", you might stitch in a short summary of what Fusion is, what it does for Proto, and perhaps a quick hand-wavy explanation about the parts of Fusion that would be handy in development using Proto. Obviously, this will have links to appropriate corners in the Fusion documentation. On the other hand, the documentation of Fusion is rather a reference manual and you'd usually not learn how to program using a library by reading the mere reference... HTH, --Hossein
On 01/03/11 12:44, Hossein Haeri wrote: [snip]
2) Preprocess the code first and compile it.
Hmmm... How do I do that?
Use cpp, or, if the compiler is g++, use -E and capture the output, or use, IIRC, the flag -save-temps, which would save the preprocessed code in X.i where the compiled source is X.cpp, for any filename, X. If you want something readable, then I'd recommend passing the output from the above step through some reformatting program like indent on linux. HTH. -Larry
Dear Larry,
Use cpp, or, if the compiler is g++, use -E and capture the output, or use, IIRC, the flag -save-temps, which would save the preprocessed code in X.i where the compiled source is X.cpp, for any filename, X.
Wow! That's cool. :)
If you want something readable, then I'd recommend passing the output from the above step through some reformatting program like indent on linux.
Do you happen to know the Windows counterpart of that? MinGW32 would also do. TIA, --Hossein
On 01/03/11 15:51, Hossein Haeri wrote: [snip]
If you want something readable, then I'd recommend passing the output from the above step through some reformatting program like indent on linux.
Do you happen to know the Windows counterpart of that? MinGW32 would also do.
Sorry, no. -Larry
On Mon, 03 Jan 2011 19:28:17 -0600, Larry Evans wrote:
On 01/03/11 15:51, Hossein Haeri wrote: [snip]
If you want something readable, then I'd recommend passing the output from the above step through some reformatting program like indent on linux.
Do you happen to know the Windows counterpart of that? MinGW32 would also do.
Sorry, no. Try Astyle [1].
[1] <https://sourceforge.net/projects/astyle/> -- VH
On 1/3/2011 1:44 PM, Hossein Haeri wrote:
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.
Sure. Here are some suggestions:
1) Every now and then in the Proto documentation, you can add a short intermezzo which explains which Fusion creature is used in that specific point and how.
Fusion is used in *very* few places in Proto. Only unpack_expr and fold use any part of Fusion, and the reference for those make it pretty clear the dependence on Fusion.
2) You might want to state Fusion as a pre-requisite for proper Proto knowledge.
Let me ask you this: what about Proto specifically have you found difficult to understand without Fusion knowledge? I could focus my attention there.
3) After "Getting Started" and before "Fronts Ends...", you might stitch in a short summary of what Fusion is, what it does for Proto, and perhaps a quick hand-wavy explanation about the parts of Fusion that would be handy in development using Proto. Obviously, this will have links to appropriate corners in the Fusion documentation.
I'm not (yet) convinced it's necessary, and I certainly don't want to document Fusion even in hand-wavy terms. It's a maintenance burden to have to keep it in sync with the actual Fusion documentation. I wish our document toolchain made cross-linking in our docs easier. That's the way to go, IMO.
On the other hand, the documentation of Fusion is rather a reference manual and you'd usually not learn how to program using a library by reading the mere reference...
Yeah, the Fusion docs could use more users'-guide-ish docs for its high-level architecture, concepts, and common usages. -- Eric Niebler BoostPro Computing http://www.boostpro.com
participants (3)
-
Eric Niebler -
Hossein Haeri -
Larry Evans -
Václav Haisman