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