On Sat, Sep 20, 2025 at 12:51 PM Ion Gaztañaga via Boost < boost@lists.boost.org> wrote:
I'll update the "Draft Development Plan for Boost.Container" ( https://docs.google.com/document/d/1VdMTheFUczC946dP3VKPseOoUq3sVKjU73oMvK8F...)
with these proposals. Of course, I'm open to new proposals/features.
Amazing document, even if people do not care about Container I suggest they read them for amazing collection of links it contains. Comments: 1. For B-Tree: could it support layout so that SIMD search for integers is possible? I mean at the level we compare multiple items and then check if we found one or we need to follow child pointers... maybe other implementations already do this 2. https://www.boost.org/doc/libs/1_89_0/doc/html/container/main_features.html#... seems potentially AMAZING for "real life"(aka huge) projects where extra include can kill compile times. I know document is about improvements(not to mention modules are gonna fix everything), not advertising but if I understand this correctly it can be huge advantage for some people. So maybe mention it. If anybody has real life experience with this please do share! 3. Discuss if different SSO buffer sizes types are movable or not. For example: will string with SSO max size 42 know to move from SSO of max size 32. Same for deque with diff block sizes... I presume answer is no, but I think it is worthwhile to say. 4. Document how can one run benchmarks on Container. I am not really a boost developer, but often I like to play with benchmarking code, so would be nice to know how hard/easy is to run some benchmarks on my machine. 5. should T in containers be constrained - I presume answer is no, since I presume concepts slow down compilation, but I thought it should be discussed, in case I presumed wrong :) 6. Are there any macro hacks to stamp out something(e.g. variadic templates emulation) whose cleanup would help with compile times. 7. Compile times - Unfortunately std:: implementors have privilege of including internal headers, Boost does not(although some people do tricks like declare std:: stuff or include internal headers and that can lead to breakages when std people reorganize internal headers). This means that generally std:/boost:: version of same thing do not cost same to compile, and often boost compile times are worse. 8. vector32: May be stupid idea with "noise" performance improvement, but I was always annoyed that vector uses 2 64 bit fields for size and capacity when(unless you use small types like char or short or int) my computer would ran out of memory before you could get vector that big. So for example vector32<std::string> can support up to 4GigaStrings(great unit) since it splits capacity and size in 2 32 bit fields(obviously data must be 64bit). This is all theoretical and I can not think of a benchmark where this improves performance that does not include realistic program. I mean I can "hack" a benchmark where with std::vector we spill out of L1 cache( if we have ton of std::vector) and we are in L1 cache with std::vector32, but seems very artificial. We would need RealLife™ application, typedef in std::headers std::vector to vector32 and see if anything noticeable happens with performance. I understand this is a ticking timebomb for certain usecases, but I guess people can make decision if they want the risk or not depending on their usecase. 9. resize_and_overwrite- ugly name, beautiful performance allegedly... I think it may be useful to add it so people can do std::format_to_n to SSO buffer of string without paying a copy(not to mention that if people use std::format std::string in it's api so you need to give them nice escape ;) ) 10. I asked people before on mailing list for std::optional<T&> API for Boost.Unordered, not a lot of fans although I was not the only proponent. C++ might get it <https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p3091r4.html#other-names-for-get>, but not before C++29... and it might get an uglier name than get. I still think it is great api for any associative container. 11. starts_with and ends_with for string. Issue here is that std:: has 3 overloads, one takes std::string_view, do you use boost or std::string_view? I would suggest std::one, but that makes the code C++17. Beside that implementation is trivial beside checking what happens for nullptr input. 12. Regarding support for pool in containers: might bet worthwhile to investigate if using indexes into a pool(as long as pool is contiguous) instead of pointers to save on child pointer sizes. I am aware it involves extra work to get final pointer. 13. Fuzzing would be nice, esp for rewrites, since we can presume users reported most of the bugs in older code, although obviously ideal is to fuzz everything. 14. SecureString - tbh I am worried about maintenance of this guy, it could be just my paranoia since IDK how elaborate future attacks(or compiler optimizations) might realistically be i.e. is it possible that secure erasure gets broken and it needs a hotfix asap. 15. GermanString - I would suggest picking better name, unless it really sticks in the community. https://www.reddit.com/r/programming/comments/1e5gzq2/comment/ldmj266/ Sorry for the manifesto, I do not expect you to go over each point and spend 20 min on each, this is just a quick dump of my first reactions when reading the document.