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

5 Jun 2008

      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

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

joaquin＠tid.es