Re: [Boost-users] build times and Boost.MultiIndex 2

From: joaquin_at_[hidden]
Date: 2008-06-05 12:40:06

gast128 escribió:
>  <joaquin <at> tid.es> 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 <boost/multi_index_container.hpp>

  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 <boost/multi_index_container.hpp>

  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