El 30/09/2025 a las 12:25, Ivan Matek via Boost escribió:
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:
Thanks Ivan, I missed your reply.
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
I'm not an expert at B-trees at all, but in general generic implementation (like abseil) don't support SIMD.
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.
In principle, they are different types, and the existing practice with small_vector does not support those operations. However, all small_vectors derive from small_vector_base which is movable and has to support the operation with different SSO optimizations. So maybe it's a doable and desired feature...
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.
The benchmarking part should be improved and simplified, yes. Having a new Boost.Bench library would certainly help instead of inventing our own machinery...
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 :)
Not sure if this feature offers enough advantages, I haven't received any feature request asking for this.
6. Are there any macro hacks to stamp out something(e.g. variadic templates emulation) whose cleanup would help with compile times.
If variadic templates are available, the all emulation code is not compiled, the preprocessor just skips all the machinery. I don't think compile times would be improved, probably the maintainance cost would be lower.
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.
It could be, but at least for some std implementation I think Boost container compile times are quite fast, and preprocessor produced code is in many times smaller. But of course, this varies a lot with the standard library type and version...
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
Already possible with Boost.Container for vector-like containers (vector, static_vector, small_vector, devector...)
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 ;) )
Ok, I missed this feature from C++23.
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.
Not a fan. For two reasons: - I don't like the idea of adding dependencies to containers. The beauty of the STL design was the iterator abstration that does not like a container with an external type. It's not a good design decision IMHO. - Some users would like to use boost::optional or other optional instead of the standard one.
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.
I missed those C++20 features, thanks. Maybe we can support a view-like template argument and support both.
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.
Seems quite specific in most cases pools are not contiguous...
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.
Right, we would need to lay out an strategy to select what code parts should we fuzz first to obtain significant results with the minimum effort.
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.
Right, I agree.
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/
Thanks for the link, definitely the "german" name does not transmit the idea behind.
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.
Many thanks for your review, I appreciate you time and effort, I think your comments will be very useful to improve the roadmap of the library. Best, Ion