Re: [boost] [containers] Clarifications on incomplete type support?

Subject: Re: [boost] [containers] Clarifications on incomplete type support?
From: Ion Gaztañaga (igaztanaga_at_[hidden])
Date: 2014-09-24 17:44:49

El 24/09/2014 21:04, Mikael Persson escribió:
> In the process of implementing my own fix for n3644, I had a chance to take
> a cross-section look into the inner workings of Boost.Container/Intrusive.
> I would just like to make a general observation about it. I find that there
> is a lot of stuff under there. I understand that a robust library like
> Container or Intrusive cannot be as simple under-the-hood as a naive
> re-implementation of STL containers (i.e., a basic naive re-implementation
> of std::vector might take a couple of hundred lines of code, while a more
> production-quality one will take significantly more code than that).
> However, I think it's important to keep compilation times in mind. When I
> originally switched my BGL code from STL containers to Boost.Container, I
> noticed a pretty significant (almost crippling) increase in compilation
> times and memory-consumption. I understand that it can be neat to have, for
> example, a single iterator class template to implement iterators for all
> node-based containers (list, slist, map, set, etc.), but it requires heavy
> template meta-programming to make that happen without too much run-time
> overhead, leading to an increase in compilation time and memory. I'm not
> sure that this trade-off is really to the advantage of the users. I've
> learned to favour simple mechanics under-the-hood even if it implies a
> certain amount of code repetition, instead of the fancier or more elegant
> TMP mechanics, which I have regretted using in the past due to compilation
> times, memory and bloated diagnostics and debugging. That's just an opinion

I'm a bit worried about compilation times and memory usage . However I 
haven't diagnosed where the problem lies and I have no much time and 
knowledge to investigate it. Any help is welcome. Do you notice this 
overhead in C++03 or C++0x compilers, in both modes? In c++03 compilers 
the preprocessor is also used to generate overloads of many functions 
(allocator_traits, emplace, etc.) and that might be also a problem.

In any case without measurements, we don't know where we waste the 
compilation time.

I don't know if measuring this overhead reliably is possible. 
Boost.Intrusive is also a bit heavy in metaprogramming, but at least 
vector should not rely on that. Which containers do you use in BGL?

> I thought I should share with you, and something for you to keep in mind
> for future coding iterations on the library (suggestion: create some
> comparative compilation time/memory benchmarks between STL implementations
> and the Boost.Container implementation, and try to aim to remain comparable
> to them).

The first step I was planning is reducing header dependencies for some 
classes. In any case you suggestion sounds reasonable and I'm very 
interested in having more feedback from Boost.Container users.

Best,

Ion