On Mon, Sep 9, 2019 at 2:04 PM Ion Gaztañaga via Boost
...I think it's a good idea, it seems a really useful container. To ease the maintenance, I think we should merge container::string and container::static_string implementations to reuse as much as code as we can.
I've been discussing this on the C++ Slack and I think a separate Boost library would be best. There is a growing clamor from users for more modularity from Boost. Having more fine-grained libraries would help with this. There are other benefits to having a separate library: - Separate repository has its own Travis compilation / time limits - Comprehensive valgrind / sanitizer tests will take less time - The tests on CI will take less time to complete in general - Coverage reports would be more meaningful (since they include less code) A one-line change to, f.ex. Boost.FixedString (provisional name) would have a faster turn-around time on CI than a one-line change made to Boost.Container. Another point worth discussing, is overall compilation performance. Once of the complaints about Beast is the heavy reliance on templated algorithms. Some of these Beast algorithms simply cannot be changed since they operate on concepts. However we identified parts of Beast that could be made into normal functions, and there is a preprocessor macro to allow those function definitions to be compiled into their own library. For example: https://github.com/boostorg/beast/blob/b7230f12f16fe7a9f7a1ece5be1f607c85524... For static_string (alternatively named: fixed_string) it should be very practical to make most of the implementation consist only of ordinary (non-template) functions, at least for the most common template parameter of char_traits<char>. We could make the header-only compilation mode also available via macro as shown above. This will make static_string very lean in terms of compilation resources and increase the appeal of the library. Regards