[Boost-users] Re: [multi_index] FYI: Experiences with the Boost.MulitIndex container

From: Jochen Hammann (jochen.hammann_at_[hidden])
Date: 2005-04-20 06:48:13

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.

Regards,

     Jochen.