|
Boost : |
From: Vinnie Falco (vinnie.falco_at_[hidden])
Date: 2019-09-09 21:42:10
On Mon, Sep 9, 2019 at 2:04 PM Ion Gaztañaga via Boost
<boost_at_[hidden]> wrote:
> ...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:
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk