Jochen Hammann ha escrito:
Joaquin M Lopez Munoz wrote:
Yep, the problem with symbol names length was raised in the very review. At the time I didn't think much can be done to shorten symbols, but today I've got good news :) The preview version at the Sandbox files section
multi_index_140205_plus_hash_part_1.zip multi_index_140205_plus_hash_part_2.zip
includes optimizations to produce *much* shorter symbol names. In case you have time to do the test, I'd appreciate if you download the preview and try to compile your project, reverting to member<> instead of member_offset<>. Do you see any improvement? For better results, you can try deriving the "indexed_by" part:
struct my_indices: indexed_by< ...
{};
typeded multi_index_container< my_element, my_indices
my_mic;
This technique, combined with the optimizations provided in the preview version, should reduce symbol names down to something almost human-readable. If you finally do the test, please do report back. Thank you!
JoaquÃn M López Muñoz Telefónica, Investigación y Desarrollo
Hi JoaquÃn,
please excuse the very long delay for this reply. I have made some tests with the new Sandbox files
multi_index_030305_plus_hash_part_1.zip multi_index_030305_plus_hash_part_2.zip.
I wrote a small example application and I tried to use the Boost.MultiIndex container like I do in my main project. First of all, I was not able to reproduce the internal compiler error (Microsoft Visual C++ 7.1) that occurred during the compilation of my project. After a lot of tests I decided to copy the Visual Studio project settings to my example application.
The internal compiler error occurs, if the compiler option /vmg is set. This option is also set within my main project. Because I obtained the core of the project from a colleague, I do not know, why this option was set. I have tried to reproduce the internal compiler error with a simple example (see the following code):
#include <boost/multi_index_container.hpp> #include <boost/multi_index/member.hpp> #include <boost/multi_index/ordered_index.hpp> #include <boost/multi_index/key_extractors.hpp> #include <string>
using boost::multi_index_container; using namespace boost::multi_index;
struct SElement { long element1; long element2; };
typedef boost::multi_index_container<SElement, indexed_by<ordered_non_unique<member<SElement, long, &SElement::element1> > > > EntityMap_t;
int main() { EntityMap_t entityMap;
return 0; }
If I compile this example with activated /vmg option, the following internal compiler error occurred:
D:\Libraries\DLLs\Boost\Boost_1_32_0\inc\boost\type_traits\is_base_and_derived.hpp(127) : fatal error C1001: INTERNAL COMPILER ERROR (compiler file 'msc1.cpp', line 2701) Please choose the Technical Support command on the Visual C++ Help menu, or open the Technical Support help file for more information
If I deactivate the /vmg option, the example compiles without any error. During this test I encountered something, that might be of interest for you. If I use tags within the MultiIndex declaration, the example compiles without any error - even if the /vmg option is set (see the following code):
#include <boost/multi_index_container.hpp> #include <boost/multi_index/member.hpp> #include <boost/multi_index/ordered_index.hpp> #include <boost/multi_index/key_extractors.hpp> #include <string>
using boost::multi_index_container; using namespace boost::multi_index;
struct STag { };
struct SElement { long element1; long element2; };
typedef boost::multi_index_container<SElement, indexed_by<ordered_non_unique<tag<STag>, member<SElement, long, &SElement::element1> > > > EntityMap_t;
int main() { EntityMap_t entityMap;
return 0; }
This code compiles, regardless of the compiler option /vmg.
The information you're giving is very interesting! The fact that the problem does not appear when using tags seems to hint at a nasty complication with the joint use of boost::is_base_and_derived and pointers to members as used in boost::multi_index::member. I've attached a simple test case. Would you mind compiling it with and without /vmg? If it fails with /vmg, would you mind removing the type1 and type2 parts and leaving only type2? If we're able to isolate the problem maybe there's still time to make some sort of fix into Boost 1.33. Otherwise, I'll comment on this on the compiler specifics section. Thanks for your help! Joaquín M López Muñoz Telefónica, Investigación y Desarrollo