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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk