[json] [text] Multiple, custom string tyypes

From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2020-06-15 11:18:28

sob., 13 cze 2020 o 18:42 Vinnie Falco via Boost <boost_at_[hidden]>
napisał(a):

> On Fri, Jun 12, 2020 at 10:36 AM Rainer Deyke via Boost
> <boost_at_[hidden]> 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;