writes:

gast128 escribió:

...

Dear all,

just refactored a component in our (large) application with use of Boost.MultiIndex. However using a test application it seems that by only including the Boost.MultiIndex header in the header files, the build time

...

times (700%) slower than without that header file.

Pulling Boost.MultiIndex to the cpp file is no option, because I need to export the iterator as well. Of course I can make a wrapper around the iterator as well (for the sole purpose to shield the inclusion of the Boost.MultiIndex header), but isn't this a little bit strange? Putting Boost.MultiIndex in the pch is also a no-op because, 1) every pch must be adjusted, 2) VC++ 7.1 chokes on that.

I'm sorry to hear that. B.MI is certainly a template intensive library and this is the price one has to pay to use it. PCHs should really be the approach to use, as improvements are generally dramatic. If globally changing PCHs is not acceptable maybe you can have a testing mode in your app that has B.MI included in PCHs, even if this is not the configuration for final builds. Well I tried, but I got a rare unrelated compile error in the middle of an STL

is 7 header. Mostly they are then related to out of memory conditions or crashes within the compiler. Btw, we already have a crowded pch file (with STL, iostream, some boost libraries etc.).

Regarding the advice given by Ovanes in a previous post, I'm afraid you probably can't get by using the forward header, as this does not define B.MI iterators.

I saw the file and it didn't specify the iterators.

Another option is to use pointers instead of iterators in your public interface so that you can move the B.MI headers to the cpp file; version 1.35 of B.MI provides a member function called iterator_to that allows you to pass from pointers to iterators:

http://www.boost.org/libs/multi_index/doc/tutorial/indices.html#iterator_to Thx, but I need the iterators for ...iteration. I can also swith back to std::map (or std::set); the use case here is to sort a container of (shared_ptrs of) objects on a member key. Using std::map or std::set is then either redundant or one get difficulties with key search (by using a dummy variable), just as specified in the documentation.

I think this a quality of implementation issue that the commitee can't do much about. Template metaprogramming is an accidental use of templates so generally compilers are not ideally suited to the heavy compile time activity it generates. Hopefully things are improving on this area largely due to the influence of Boost. I hope so too. The test program didn't use any Boost.MultiIndex: it had only the header files. Wouldn't it be possible in someway to optimize that (but I am not a compiler guru), by skipping extensive parsing of the header file?

wkr, me

gast128 escribió:

writes:

[...]

...

Another option is to use pointers instead of iterators in your public interface so that you can move the B.MI headers to the cpp file; version 1.35 of B.MI provides a member function called iterator_to that allows you to pass from pointers to iterators:

http://www.boost.org/libs/multi_index/doc/tutorial/indices.html#iterator_to

Thx, but I need the iterators for ...iteration. I can also swith back to std::map (or std::set); the use case here is to sort a container of (shared_ptrs of) objects on a member key. Using std::map or std::set is then either redundant or one get difficulties with key search (by using a dummy variable), just as specified in the documentation.

I see... this is not a solution then. Sorry. Maybe this is going too far, but you can hide B.MI iterators behind a type erasure boundary like adobe::any_iterator provides: http://stlab.adobe.com/classadobe_1_1any__iterator.html So, instead of your current // .hpp #include class my_class{ ... typedef multi_index_container<...>::iterator iterator; iterator foo(); }; you can write // .hpp // no multi_index includes class my_class{ ... typedef adobe::any_iterator<..., std::bidirectional_iterator_tag> iterator; iterator foo(); }; // .cpp #include my_class::iterator my_class::foo() { typedef multi_index<...>::iterator internal_iterator; internal_iterator it=...; return iterator(it); } The price to pay for hiding behind adobe::any_iterator is that iteration with this construct is slower than the original case (polymorphic calls are involved.)

...

I think this a quality of implementation issue that the commitee can't do much about. Template metaprogramming is an accidental use of templates so generally compilers are not ideally suited to the heavy compile time activity it generates. Hopefully things are improving on this area largely due to the influence of Boost.

I hope so too. The test program didn't use any Boost.MultiIndex: it had only the header files. Wouldn't it be possible in someway to optimize that (but I am not a compiler guru), by skipping extensive parsing of the header file?

(I'm not a compiler expert either.) AFAIK template compilation is implemented in two phases: the first one parses and validates the template. The second phase happens at instantiation time when the particular template parameters are fixed. Simply including the headers should only incur the cost of the first phase, but seems like in your case that phase alone is already very costly in terms of compilation time :( Joaquín M López Muñoz Telefónica, Investigación y Desarrollo