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 is 7 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. 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. 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 As explained in the referred to section, hiding B.MI to the implementation files is one of the reasons why this utility is provided. Please report back if this works for you.
It is not something Boost can do much about it, but it as least an irritating point to put it mildly. It greatly cost productive hours to wait for builds to finish.
Something for the c++ committee? c# seems to have a superior build system...
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. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo