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

Subject: Re: [boost] [containers] Clarifications on incomplete type support?
From: Mikael Persson (mikael.s.persson_at_[hidden])
Date: 2014-09-24 15:04:46

Hi Ion,

I noticed that you fixed the issue comprehensively, replacing the quick fix
that I had made for it. Thank you very much for being so quick and
responsive with these issues. I would nominate you for the "best boost
maintainer award", if one existed!

My own code now works without any issue, thanks to your implementation of
n3644 compliance in Boost.Container/Intrusive.

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 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).

Thanks,
Mikael.