[multi_index] FYI: Experiences with the Boost.MulitIndex container
Hi, I am using the Boost MultiIndex container in conjunction with the Microsoft Visual C++ 7.1 compiler. I encountered an runtime exception during some tests of my application. I made the mistake, that I tried to construct an index as a separate object instead of using a reference to the respective index. The MultiIndex documentation highlights this issue: "Note that get returns a reference to the index, and not an index object. Indices cannot be constructed as separate objects from the container they belong to, so the following // Wrong: we forgot the & after employee_set::nth_index<1>::type const employee_set::nth_index<1>::type name_index=es.get<1>(); does not compile, since it is trying to construct the index object name_index. This is a common source of errors in user code." I could reproduce the exception by using the MultiIndex example basic.cpp from the Boost 1.32.0 release. Unfortunately, Microsoft Visual C++ 7.1 compiles the above mentioned line without an error or warning. During the execution of the example an exception will be thrown while processing the following line: std::copy(i.begin(),i.end(),std::ostream_iterator<value_type>(std::cout)); within the function template print_out_by(). Regards, Jochen.
Jochen Hammann <jochen.hammann <at> realtech.com> writes:
Hi,
I am using the Boost MultiIndex container in conjunction with the Microsoft
I encountered an runtime exception during some tests of my application. I made the mistake, that I tried to construct an index as a separate object instead of using a reference to the respective index.
The MultiIndex documentation highlights this issue:
"Note that get returns a reference to the index, and not an index object. Indices cannot be constructed as separate objects from the container they belong to, so the following
// Wrong: we forgot the & after employee_set::nth_index<1>::type const employee_set::nth_index<1>::type name_index=es.get<1>();
does not compile, since it is trying to construct the index object name_index. This is a common source of errors in user code."
I could reproduce the exception by using the MultiIndex example basic.cpp from the Boost 1.32.0 release. Unfortunately, Microsoft Visual C++ 7.1 compiles the above mentioned
Visual C++ 7.1 compiler. line without an error
or warning.
Hi Jochen, In conformant compilers, index constructors are protected and the error shows at compile time (try with GCC if you have it handy.) Unfortunately, these constructors have to be made public on those compilers for which the defect macro BOOST_NO_MEMBER_TEMPLATE_FRIENDS is set: this includes all of the MSVC familiy, even the 8.0 version :( Other than that, have you experienced any difficulty, problem, do you have any suggestion for improvement? Users' feeback is much appreciated. Regards, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
I too have just started to use it and can see many applications (it is very kewl) - I have one quick question: I am using the "boost::multi_index::sequenced<>" to index my list and would like the ability to get the actual numeric number for the index (I am using to store the zorder for a list of renderers) at the moment I do the following: UniqueIDIndex & index = m_pos.get<1>(); //Index on UniqueID UniqueIDIndex::iterator it1 = index.find(id); //Fast get based on UniqueID GraphItemRendererContainer::iterator it2 = m_pos.project<0>(it1); //Get "Index" index return std::distance(m_pos.begin(), it2); //Calculate actual position in index Is there any "better" way? Thx, Gordon. "Joaquin M Lopez Munoz" <joaquin@tid.es> wrote in message news:loom.20050217T115101-159@post.gmane.org... Jochen Hammann <jochen.hammann <at> realtech.com> writes:
Hi,
I am using the Boost MultiIndex container in conjunction with the
I encountered an runtime exception during some tests of my application. I made the mistake, that I tried to construct an index as a separate object instead of using a reference to the respective index.
The MultiIndex documentation highlights this issue:
"Note that get returns a reference to the index, and not an index object. Indices cannot be constructed as separate objects from the container they belong to, so the following
// Wrong: we forgot the & after employee_set::nth_index<1>::type const employee_set::nth_index<1>::type name_index=es.get<1>();
does not compile, since it is trying to construct the index object name_index. This is a common source of errors in user code."
I could reproduce the exception by using the MultiIndex example basic.cpp from the Boost 1.32.0 release. Unfortunately, Microsoft Visual C++ 7.1 compiles the above mentioned
Microsoft Visual C++ 7.1 compiler. line without an error
or warning.
Hi Jochen, In conformant compilers, index constructors are protected and the error shows at compile time (try with GCC if you have it handy.) Unfortunately, these constructors have to be made public on those compilers for which the defect macro BOOST_NO_MEMBER_TEMPLATE_FRIENDS is set: this includes all of the MSVC familiy, even the 8.0 version :( Other than that, have you experienced any difficulty, problem, do you have any suggestion for improvement? Users' feeback is much appreciated. Regards, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
Hi Gordon, Gordon Smith <schmoo2k <at> hotmail.com> writes:
I too have just started to use it and can see many applications (it is very kewl) - I have one quick question:
I am using the "boost::multi_index::sequenced<>" to index my list and would like the ability to get the actual numeric number for the index (I am using to store the zorder for a list of renderers) at the moment I do the following:
UniqueIDIndex & index = m_pos.get<1>(); //Index on UniqueID UniqueIDIndex::iterator it1 = index.find(id); //Fast get based on UniqueID GraphItemRendererContainer::iterator it2 = m_pos.project<0>(it1); //Get "Index" index return std::distance(m_pos.begin(), it2); //Calculate actual position in index
Is there any "better" way?
I'm afraid not, unless you store the position by other means. Take into account that this is very inefficient (linear time.) Recently I proposed adding random-access indices, in the spirit of std::vectors, which would allow to calculate the position of an element in constant time. But these indices, if they finally make it into the lib, won't be available anytime soon --not in Boost 1.33, at least. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
Joaquin M Lopez Munoz wrote:
Hi Jochen,
In conformant compilers, index constructors are protected and the error shows at compile time (try with GCC if you have it handy.) Unfortunately, these constructors have to be made public on those compilers for which the defect macro BOOST_NO_MEMBER_TEMPLATE_FRIENDS is set: this includes all of the MSVC familiy, even the 8.0 version :(
Other than that, have you experienced any difficulty, problem, do you have any suggestion for improvement? Users' feeback is much appreciated.
Regards,
Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
Hi Joaquín, thanks for your reply. As I wrote in the original mail, I am developing with the Microsoft Visual C++ 7.1 compiler. Starting with the Boost.MultiIndex container, I wrote some examples to get familiar with the container. After some problems with long symbol names (you have helped me in another thread) the examples work very well. By using the Boost.MultiIndex container in my project, I encountered internal compiler errors. I tried to reduce the symbol length by declaring new structs which derive from the ordered indices and the key extractors, respectively, but this didn't help. Now, I am using the member_offset<> extractor, which solves the problems. Unfortunately, I was not able to reproduce the internal compiler error with some example code. BTW: The Boost.MultiIndex is a great container. Regards, Jochen.
Jochen Hammann <jochen.hammann <at> realtech.com> writes:
As I wrote in the original mail, I am developing with the Microsoft Visual
Starting with the Boost.MultiIndex container, I wrote some examples to get familiar with the container. After some problems with long symbol names (you have helped me in another thread) the examples work very well. By using the Boost.MultiIndex container in my
C++ 7.1 compiler. project, I encountered
internal compiler errors. I tried to reduce the symbol length by declaring new structs which derive from the ordered indices and the key extractors, respectively, but this didn't help. Now, I am using the member_offset<> extractor, which solves the problems. Unfortunately, I was not able to reproduce the internal compiler error with some example code.
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 PS: The preview version has not yet been tested for MSVC 7.1, though I'm confident you won't find any problem. PPS: This is a preview version, so please don't stick with it. The opimizations mentioned will make it into the final version for Boost 1.33.
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:
Hi Joaquín, unfortunately, I am very busy at the moment. Nevertheless, I have downloaded both files and try to get some time for the tests. I will keep you up-to-date. Regards, Jochen.
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.
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
Joaquín Mª López Muñoz wrote:
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?
I suppose you mean, that I should remove type1 and type2 parts and leave only type3? If that is correct, than these are the results of the test: 1) The test (foo.cpp) - as attached to the posting - compiles without any errors, if the /vmg option is *deactivated*. 2) The test (foo.cpp) - as attached to the posting - fails to compile with an internal compiler error, if the /vmg option is *activated*. As you expected, the internal compiler error occurs in the file 'is_base_and_derived.hpp' at BOOST_STATIC_CONSTANT() within the following struct: template<typename B, typename D> struct is_base_and_derived_impl2 { struct Host { operator B const volatile *() const; operator D const volatile *(); }; BOOST_STATIC_CONSTANT(bool, value = sizeof(bd_helper<B,D>::check_sig(Host(), 0)) == sizeof(type_traits::yes_type)); }; 3) I have removed the type1 and type2 parts and have leaved the type3 part. Now, the test (foo.cpp) compiles without any error, regardless of the /vmg compiler option. To ensure, that I have not misunderstood you, the following code shows the modifications I made to foo.cpp: #include <boost/config.hpp> #include <boost/type_traits/is_base_and_derived.hpp> #include <boost/multi_index/member.hpp> struct marker{}; template<typename T> struct is_marked { BOOST_STATIC_CONSTANT(bool,value=(boost::is_base_and_derived<marker,T>::value)); }; struct foo { int x; }; struct bar:private marker { }; //typedef is_marked<int> type1; //typedef is_marked<boost::multi_index::member<foo,int,&foo::x> > type2; typedef is_marked<bar> type3; int main() { //bool b1=type1::value; //bool b2=type2::value; bool b3=type3::value; return 0; } I hope I could help you. Regards, Jochen.
Jochen Hammann ha escrito:
3) I have removed the type1 and type2 parts and have leaved the type3 part. Now, the test (foo.cpp) compiles without any error, regardless of the /vmg compiler option. To ensure, that I have not misunderstood you, the following code shows the modifications I made to foo.cpp:
Sorry, i meant removing type1 and type3. Anyway, please find attached a new snippet that removes the dependencies from Boost.MultiIndex. Could you please give it a try? If this still fails, I'll submit a bug report to the maintainers of Boost.TypeTraits, where the error actually belongs. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
Joaquín Mª López Muñoz wrote:
Sorry, i meant removing type1 and type3. Anyway, please find attached a new snippet that removes the dependencies from Boost.MultiIndex. Could you please give it a try? If this still fails, I'll submit a bug report to the maintainers of Boost.TypeTraits, where the error actually belongs.
I have tested the new attached file foo.cpp. The file could be compiled without any errors with *deactivated* compiler option /vmg. The compilation of the file fails with the following internal compiler error, if I compile it with *activated* option /vmg. 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 Hope this helps. Regards, Jochen.
Jochen Hammann ha escrito:
Joaquín Mª López Muñoz wrote:
Sorry, i meant removing type1 and type3. Anyway, please find attached a new snippet that removes the dependencies from Boost.MultiIndex. Could you please give it a try? If this still fails, I'll submit a bug report to the maintainers of Boost.TypeTraits, where the error actually belongs.
I have tested the new attached file foo.cpp. The file could be compiled without any errors with *deactivated* compiler option /vmg. The compilation of the file fails with the following internal compiler error, if I compile it with *activated* option /vmg.
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
Hope this helps.
I've issued an problem report at the developers mailing list, and an answer has just come in. I cannot test the proposed patch as I don't have MSVC 7.1 handy. Would you mind going at that thread and giving the patch a try? http://lists.boost.org/boost/2005/04/24532.php Thanks in advance, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
Joaquín Mª López Muñoz wrote:
I've issued an problem report at the developers mailing list, and an answer has just come in. I cannot test the proposed patch as I don't have MSVC 7.1 handy. Would you mind going at that thread and giving the patch a try?
I have patched the file 'is_base_and_derived.hpp'. Your test (foo.cpp), my example (posted within this thread) and my main project could be compiled and built without any errors even with activated /vmg option. I think this confirm the tests of Aleksey Gurtovoy and John Maddock as posted to the Boost developer newsgroup. Thank you very much for your help and your efforts. Regards, Jochen.
participants (4)
-
Gordon Smith -
Joaquin M Lopez Munoz -
Joaquín Mª López Muñoz
-
Jochen Hammann