Re: [Boost-users] [boost] [review] [text] Text formal review
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" Thanks
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;
On Mon, 15 Jun 2020 at 06:19, Andrzej Krzemienski via Boost-users < boost-users@lists.boost.org> wrote:
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).
Is fine, internally. The use of a custom string in 'the app' is not gonna improve speed as much as a better algorithm.
On Mon, Jun 15, 2020 at 4:18 AM Andrzej Krzemienski <akrzemi1@gmail.com> wrote:
can they use their string in Boost.JSON?
No. The design of the library explicitly avoids allowing customizability.
It should be possible to parametrize Boost.JSON with the string type.
This has been explored in other libraries, and I don't like the result. Here is nlohmann JSON's value type: template< template<typename, typename, typename...> class ObjectType, template<typename, typename...> class ArrayType, class StringType, class BooleanType, class NumberIntegerType, class NumberUnsignedType, class NumberFloatType, template<typename> class AllocatorType, template<typename, typename = void> class JSONSerializer > class basic_json { private: .... friend ::nlohmann::detail::parser<basic_json>; friend ::nlohmann::detail::serializer<basic_json>; ... <http://vinniefalco.github.io/doc/json/json/comparison.html#json.comparison.comparison_to_nlohmann_json> Thanks, but no thanks. As I said the library achieves its performance partly due to the layout of the different types used in the discriminated union, of which string is one. Users aren't asking for "using their own string type in the JSON DOM." What they want is the speed of RapidJSON, options for skipping comments, allowing trailing commas, and flexible parsing, and the interface quality of a Boost library. Thanks
On Mon, Jun 15, 2020 at 4:18 AM Andrzej Krzemienski <akrzemi1@gmail.com> wrote:
It should be possible to parametrize Boost.JSON with the string type.
Another problem with doing this, is that it breaks the invariant of Boost.JSON's DOM value type: * All child elements in a DOM will inherit the allocator of the root element. If we allow user-defined strings, first they probably won't work with storage_ptr (Boost.JSON's custom allocator container interface) and second they can break the invariant. My goal is for boost::json::value to be suited as a vocabulary type. Allowing customization works against that. An example of an existing useless customization point would be char traits in basic_string and/or basic_string_view. I don't want to create more. Thanks
participants (3)
-
Andrzej Krzemienski -
degski -
Vinnie Falco