Subject: Re: [boost] [containers] Clarifications on incomplete type support?
From: Mikael Persson (mikael.s.persson_at_[hidden])
Date: 2014-09-24 15:04:46
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk