sob., 13 cze 2020 o 18:42 Vinnie Falco via Boost <boost@lists.boost.org> napisał(a):
On Fri, Jun 12, 2020 at 10:36 AM Rainer Deyke via Boost <boost@lists.boost.org> wrote:
String layer: overall, a solution looking for a problem.
I created boost::json::string to use instead of std::string for a couple of reasons:
1. It uses a type-erased, reference counted memory resource instead of Allocator template parameter 2. The class is laid out a certain way to greatly minimize its size 3. The class layout is optimized to keep the size of the enclosing variant (the JSON DOM value type) small 4. The API is the same for all C++ versions (unlike std::string) 5. It is not a class template
I would like to know what are the exact _technical_ benefits of Boost.Text's String layer, beyond "because I don't like std::string"
At least some of the bullets above indicate that you need a string type tailored to the performance characteristics of your library (which is fine). The details of performance/interface requirements of Boost.Text is a part of a more general problem: people will use different string-like types for various reasons; can they use their string in Boost.JSON? It should be possible to parametrize Boost.JSON with the string type. This does not have to necessarily compromise the goal of Boost.JSON of avoiding templates. You can provide a templated library, provide your string type, provide an explicit instantiation of your library template for your string type. This way users can include cheap headers and link with the precompiled sources. But other users can choose to use your library as a template. Template-ness would still be visible at the ABI level, but maybe that is not the problem? Regards, &rzej;