<joaquin <at> tid.es> 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