From: Mike (mike.dev_at_[hidden])
Date: 2020-09-24 11:06:16
> Gesendet: Donnerstag, 24. September 2020 um 11:57 Uhr
> Von: "Andrzej Krzemienski via Boost" <boost_at_[hidden]>
> Hi Everyone,
> I have heard this claim a number of times: json::value is suitable for a
> vocabulary type. I am not sure what that actually means: no templates?
> Guarantee that layout or mangled symbol will never change? Anything else?
I'm sure there exist different interpretations of that term, but the most
important aspect for me has *nothing* to do with implementation stability,
but that it is the common way to represent some type of information
in the various interfaces across the larger c++ eco system.
I.e. it is part of the common vocabulary used. E.g. std::string_view
can be considered the vocabulary type for string parameters, and even
if I use my custom string implementation internally for some reason,
I'll make dam sure that my interface accepts std::string_view and returns
something that can at least be implicitly be converted to std::string_view.
Having such common vocabulary types that represent more complex
data than just numbers and strings could greatly facilitate the integration
and composition of mutliple different libraries, because I don't have to
translate the data from the "language" spoken by lib Foo to
the "language" used by lib Bar in order to hand the output from one
to the other.
E.g. we unfortunately don't have a real vocabulary type for vector data
(in the mathematical sense). So, if I want to use GLM to do some linear
algebra computation and then display the result in a Qt GUI,
I'll - at some point - have to translate from glm::vec2 to QVector2D,
or some such. If both libs would use the same vocabulary (at least
in their interface), like a std::vec2, I could just pass the result from
the glm computation directly to my GUI code without translation
(and the associated danger of introducing bugs or loosing data).
One of the big strengths of c++ is the ability to create data types that
"feel" the same as native types (a.k.a value-types), but ever time we
want to hand data from one library to another we either have to
decompose the data types to their fundamental components (and even
strings can not always be forwarded directly) or write everything as a
Whether c++ is in need of a JSON vocabulary type and if Boost.JSON
does provide a good one is a question I unfortunately can't answer yet
(otherwise I'd have written a review), but imho the worth of that library
should not just be measured by whether it is suited as a general
vocabulary type for the whole c++ eco system, but if it provides a
sound (doesn't necessarily need to be optimal) basis for building
higher level libs on top of it in the future (inside and outside of boost).
(e.g. implementing JSON based internet protocols).
P.S.: one word about templates as vocabulary types:
The danger is that you effectively get not one type to represent
e.g. JSON data, but one for each possible instantiation and you are
back to square one (think about std::string, vs std::wstring, vs
std::u8string). For vector data on the other hand, 2D and 3D
vectors represent different kinds of data, so having different types
is OK and using a single template instead of repeating the same logic
N times makes sense. The chrono duration types are a bit in-between
in this regard as there are many different types, but at least conversion
between them is relatively easy or even implicit.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk