Boost logo

Boost :

From: Vinnie Falco (vinnie.falco_at_[hidden])
Date: 2020-09-17 19:09:11

On Thu, Sep 17, 2020 at 11:10 AM Andrzej Krzemienski via Boost
<boost_at_[hidden]> wrote:
> I recommend to *ACCEPT* the library into Boost.

Thank you for your time and thoughtful comments.

> 3. String has two sections "Member Functions":

That's a bug in the doc toolchain, the 2nd section is "Static Member
Functions" (max_size is static)

> 4. Documentation for value::operator= seems corrupt:
> * it has sections with no content

Just a case of missing text, fixed here:


> 5. Examples of input JSON-s contain a lot of escape characters in string
> literals, like in

I'm not happy with this section at all, it needs a rewrite.

> 6. Some functions (like operator== or swap(x, y)) are naturally part of
> class interface, even though they are not member functions. It is annoying
> and confusing that rather than being listed along with the class they
> belong to they are instead listed separately as "free functions"

Yes I know what you mean, and this is a limitation of the doc scripts
I am using. `operator==` is an inline friend to accelerate overload
resolution, but `swap` is not. I can make `swap` an inline friend as
well, if that doesn't cause any problems (with respect to the rules of

> 2. Boost.JSON provides its own string type. This begs a lot of design
> questions for `json::string`. Is it a better replacement for std::string?
> std::string provides the following capability:
> ...
> json::string does not. How do I do a similar thing with json::string?

json::string is a better replacement for std::string for use as a type
in the variant, because it is optimized to work with the library. As
for the initializer_list<char> overloads, well - I have my doubts that
these are used outside of toy examples, but if a user complains then I
guess we would add them.

> 3. string::swap() has a strange precondition: you cannot swap an object
> with itself

Just open an issue and explain how you think self-swap, self-move, and
self-assignment should work and I will make the changes.

> 4. I do not like the 2-state-switch mechanics of BOOST_JSON_STANDALONE. It
> assumes that a user either wants a no-Boost version or that she wants a
> package: all Boost components.
> But what if I am using C++14 and I want to use std::error_code and
> Boost-emulated memoty_resource and string_view? What If I use Boost version
> and C++17 and want to use std::string_view?
> Maybe you can additionally provide macros for turning Boost-emulation
> libraries one-by-one? I mean, one for string_view, one for error_code, and
> one for memory_resource.

Well, I don't like having two versions of error_code, two versions of
string_view, two versions of memory_resource, two versions of Asio,
and so on. If 90% of the C++ community was using C++17 or later,
Boost.JSON might *only* have the standalone mode. In other words, I
would probably not support boost::system::error_code and other Boost
types. This of course is assuming that Asio was using the std
equivalents rather than the Boost versions which it currently uses.

Practically speaking, C++11 and C++14 have enough users that
supporting them makes sense. Thus what I have done is create two
modes. The "standalone" mode, which users must opt-in to, and the
Boost mode which is what you get by default. Note that these are two
distinct libraries with their own set of symbols. Both versions can
co-exist in the same executable, without getting link errors. This is
accomplished through inline namespacing.

At some point, Boost is going to have to holistically address this
issue of having its own substitute types for commonly used std types.
But for now I think it is best that users make a choice to either go
all-in on Boost types, or simply go with C++17 and have all-std types.
I would like to avoid enabling users to proliferate more code that
mixes and matches the Boost types with the std types.


Boost list run by bdawes at, gregod at, cpdaniel at, john at