[multi_index]Got warnings in VC7.1
Hi,
I used multi_index in the simple way: int<->int unique mapping. But in
VC7.1, warning level 4, I got many warnings for:
\boost_1_33_1\boost\multi_index\detail\ord_index_node.hpp(453): warning
C4510: 'boost::multi_index::detail::ordered_index_node<Super>' : default
constructor could not be generated.
I have read the doc of multi_index, and tried to turn off "\Gm", but the
problem is still. When compiled it in VC8.0 under warning level 4, these
warnings disappeared. It seems that, the template support in VC7.1 is not so
good. My test code is listed in the end of this article. How to get rid of
them? (...>_<... The webpage argues me about top-posting, so I cannot put them
on).
Another thing is about compile time. If multi_index is employed, the compile
time will be greatly increased (slower 10 times in VC7.1, 3 times in VC8.0).
Furthermore, the message generated by compiler is extremely long. I usually get
lost in it. ^_^ Is there any way to simplify them? Such as using struct T:S
rather than typedef in multi_index library?
Finally, I have a question on the design of
template
Hello Shenlei
----- Mensaje original -----
De: ShenLei
Hi, I used multi_index in the simple way: int<->int unique mapping. But in VC7.1, warning level 4, I got many warnings for: \boost_1_33_1\boost\multi_index\detail\ord_index_node.hpp(453): warning C4510: 'boost::multi_index::detail:: ordered_index_node<Super>' : default constructor could not be generated.
I have read the doc of multi_index, and tried to turn off "\Gm", but the problem is still. When compiled it in VC8.0 under warning level 4, these warnings disappeared. It seems that, the template support in VC7.1 is not so good. My test code is listed in the end of this article. How to get rid of them? (...>_<... The webpage argues me about top-posting, so I cannot put them on).
(Well, you seem to have forgotten to attach the test code, but I think I don't need it to answer.) These C4510 warnings are hopefully avoided in what will become Boost 1.34. You might want to check by downloading a snapshot of the current CVS at: http://www.boost-consulting.com/boost.tar.bz2 Does this solve your problem? Anyway, particularly bothering (and totally uninformative) warnings like this can always be shut up using a #pragma warning(disable:xxx).
Another thing is about compile time. If multi_index is employed, the compile time will be greatly increased (slower 10 times in VC7.1, 3 times in VC8.0).
Yep, Boost.MultiIndex subjects compilers to severe stress :( although your figures seem to indicate they're getting much better at compiling metaprogramming stuff. Have you tried turning precompiled headers on? This usually has a dramatic (positive) impact on compile times.
Furthermore, the message generated by compiler is extremely long. I usually get lost in it. ^_^ Is there any way to simplify them? Such as using struct T:S rather than typedef in multi_index library?
Yes, there's a tecnhique called type hiding which can be used here. It is explained at: http://boost- consulting.com/boost/libs/multi_index/doc/compiler_specifics.html#type_ hiding
Finally, I have a question on the design of template
struct member; In practice, the user of "member" should provide the SAME type of PtrToMember to the template arguments (Class & Type). If feeded with some wrong types, errors message for the hell will be sent out. ^_^ Is there any way to improve it? Such as simply member , and let the compiler to deduce the type of this memberpointer?
As you point out, *seems* like the compiler ought to be able
to deduce the type without the user explicitly providing it,
but unfortunately this is not possible with current C++ mechanisms.
Once we've got typeof in a couple of years some techniques can
be devised so that something like the terser member
Thank you.
Thank you for using Boost.MultiIndex. Hope this helps, come back if you have further problems.
ShenLei
Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
Thank you very much! My questions are all solved now. This multi_index is much better than the bid_map you posted on CodeProject. I love it!
participants (2)
-
"JOAQUIN LOPEZ MU?Z"
-
ShenLei