- Boost - lists.boost.org

Cache Size
by Matt Borland 01 Oct '20

01 Oct '20

A recurring discussion in Boost.Math has been needing a cross-platform way to query the L1D cache size of a machine. I have most of a solution in a [personal repo](https://github.com/mborland/cache). It did not make sense to us to have this in Boost.Math because it would be useful outside of that scope, but we did not know where it should go. Is there an existing library where this would fit? If necessary I can roll it into a library submission that exposes the functionality of CPUID. Matt

3 3

[review][json] My review
by Gavin Lambert 30 Sep '20

30 Sep '20

- Do you think the library should be accepted as a Boost library? Yes, my vote is to ACCEPT this library. - What is your evaluation of the design? Much has been debated recently on the merits of push parsers vs. pull parsers. Boost.JSON provides both a push parser (SAX-like interface) and a DOM parser (which is somewhat pull-like but I don't think is technically either kind). It does not provide a "real" pull parser, which are sometimes more efficient for deserialisation into custom types; the SAX parser can somewhat do that but is not composable, which makes it harder to use in practice, unless I'm missing something (this is usually why I end up never using SAX parsers). If so, I'd like to see a more complete example where the handler delegates part of the parsing to a class that in turn delegates part to another class (as with reading typed sub-values). I don't think this is currently possible. So I think I can understand some of the debate around this point; while I don't think it's strictly necessary that this particular library implement that, if it doesn't then another library will end up having potentially competing types and the natural Boost.Json name will already be taken. Personally, however, I don't think this is sufficient reason to block acceptance of this library. Direct pull parsing doesn't mesh well with JSON, due to the requirement to tolerate reordered keys, so any non-defective parser would have to have something DOM-like under the hood anyway. (Some kind of cache, if not necessarily a traditional DOM.) As such it should be sufficient to use json::value itself as part of a pull-like parsing interface. Regarding the SAX parser specifically, I dislike the *_part methods in the callback interface. I feel that these should be removed and only the final form retained, called only when the complete text of the value has been determined. I don't feel it is ever sensible to call back with a partially-parsed value (unless I am misunderstanding what these are for, but there is little explanation in the docs, and I wasn't able to get them called at all in my test). I also don't see the point of supplying a size argument to on_key* and on_string, as this can be read from the string_view argument instead. The various number methods don't pass this separately. Similarly, having a bool return as well as an error_code output argument seems peculiar; one or the other should be sufficient, as is it just invites inconsistency. parser.write() is incremental but basic_parser.write() is not, which seems odd. I assume this means that parser is storing an incrementally populated buffer of the full document rather than _really_ incrementally parsing. parse/parser do not appear to support consuming only part of the supplied input as a complete JSON value (returning how much was consumed), which is useful for streams where multiple objects are concatenated without explicit separation. Regarding other aspects of design, I haven't drilled down in great detail but the basic interface seems reasonably sound, other than the concerns raised above. I have mixed feelings on the initializer-list construction method -- I like that there is some method of doing this, and it seems like idiomatic C++ (particularly regarding how key-value pairs appear), but also very non-JSON -- an array of objects ends up having three nested braces. But I don't have any specific suggestion for improvement. - What is your evaluation of the implementation? It seems unfortunate (though understandable, due to heap allocation) that you cannot declare a json::value / json::object as constexpr, for cases where you do want some kind of constant reference object (e.g. a schema description). You can somewhat work around this by declaring the JSON as a constexpr string_view and later parsing it to a non-constexpr json::value, but that seems a bit awkward (and potentially bad-perf-prone if someone parses it multiple times). Otherwise I didn't really look into the implementation at all. - What is your evaluation of the documentation? Overall, good, if perhaps a bit sparse on some aspects. One pet peeve however is that most of the examples appear to be written as if "using namespace boost::json" is in effect, which I feel both encourages bad practice and makes it harder to distinguish which types are provided by the library vs. exist only for the example. This is especially confusing in the examples for tag_invoke, but not only there -- another example of confusion are the aliases for types present in both boost and std namespaces. I strongly recommend going through and changing these to explicitly use a json:: namespace prefix on all library types (including the boost/std aliases). Brevity is useful, but not at the expense of clarity. The "Using Numbers" section of the docs appears to be entirely blank. "serializer can be used to incrementally serialize a value incrementally" (redundant words are redundant) (On a related note, an example use case for serializer is listed as "ensure a fixed amount of work is performed in each cycle", but the only means of control is the length of the provided buffer. I guess this is equating work to number of characters output, which seems dubious. But I have no specific objections.) - What is your evaluation of the potential usefulness of the library? The library seems well suited for JSON as inter-process/network data interchange, other than perhaps the omission of partial input parsing. It seems less suited for JSON as configuration file -- while it can parse such files (via common extensions such as ignoring comments and trailing commas) it lacks means to pretty-print and to round-trip the comments, which would be essential if writing back a config file intended for human use. However while supporting this use case would be nice, I don't consider it mandatory. - Did you try to use the library? With what compiler? Did you have any problems? I tried it out with MSVC 2017 in standalone header-only mode, though only with a few small examples. The basic_parser examples do not compile out of the box -- with the suggested json.hpp and src.hpp includes there are link errors with basic_parser symbols. Additionally including basic_parser.hpp resolves these but starts complaining about missing max_{key,string,array,object}_size members of the handler type, which are not documented. After these are supplied then it works as expected. I don't see why these should be needed, however. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? Roughly four hours over a few days reviewing docs and trying some small experiments. - Are you knowledgeable about the problem domain? I have some apps that use JSON as both interchange and configuration storage formats, although most of these do not use C++. So, "somewhat".

9 23

Review Manager needed for Boost.Lambda2
by Peter Dimov 30 Sep '20

30 Sep '20

Greetings, Some time ago I wrote a blog post, https://pdimov.github.io/blog/2020/07/22/a-c14-lambda-library/, which described how a simple lambda library can be implemented in ~50 lines using the facilities already available in C++14's <functional> standard header. I turned this into a mini-library, https://github.com/pdimov/lambda2, and I'd like to submit that to Boost. I'm looking for a review manager. The library is trivial, so managing the review should be as easy as theoretically possible for a Boost review. Thanks in advance.

7 20

new macros
by Gero Peterhoff 29 Sep '20

29 Sep '20

Hello Developer, can you please provide these 2 macros: - BOOST_HAS_LIB_INT128 - BOOST_NO_INT8_T and there is another bug in boost::is_unsigned with char8_t. See https://godbolt.org/z/o8z1aq thx Gero

1 0

[review][JSON] json::value as a vocabulary type
by Andrzej Krzemienski 26 Sep '20

26 Sep '20

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? My understanding of a "vocabulary type" is that it should be usable (not necessarily with maximum efficiency) for *any* usage. In the case of JSON that would mean that I should be able to represent any value that corresponds to a valid JSON when converted to text. I do not think that json::value can claim that without the ability to serialize arbitrarily big numbers. I understand that the goal of the library is to address the most common cases, and big numbers do not fall into this category. I am just saying that the name "vocabulary type" may not be accurate here. Regards, &rzej;

11 25

Changing virtual memory amount in Appveyor and Travis CI tests
by Edward Diener 25 Sep '20

25 Sep '20

Is it possible through .yml file for Appveyor and Travis CI to change the amount of virtual memory when running a CI test. I am running CI tests for Boost PP which heavily use the preprocessor, and some of the extended tests I am running fail on both Appveyor and Travis CI with out of memory conditions while on my own local computer, with about 32 GB of ram, the tests succeed. I think in the real world most users now have at least 32 GB of ram or more, while these virtual environments in Appveyor and/or Travis CI probably run their tests with much less overall virtual memory than an average user would have.

4 12

Re: [boost] Endorsement, review manager sought for Boost.Describe
by Peter Dimov 24 Sep '20

24 Sep '20

> Vinícius dos Santos Oliveira wrore: > > Hi Peter, > > > > could you consider using "compile-time strings" such as Hana's? I don't > > have much use for a const char* in TMP algorithms. > > The descriptor strings are "compile-time". This, for instance, works. ... Here's how you can get a Hana string: #include <boost/describe.hpp> #include <boost/mp11.hpp> #include <boost/hana.hpp> #include <cstddef> using namespace boost::describe; using namespace boost::mp11; enum E { v1 }; BOOST_DESCRIBE_ENUM(E, v1) constexpr std::size_t strlen_( char const * s ) { std::size_t n = 0; while( *s++ ) ++n; return n; } template<class D, std::size_t... I> constexpr auto to_string_impl( index_sequence<I...> ) { return boost::hana::string_c<D::name[I]...>; } template<class D> constexpr auto to_string() { return to_string_impl<D>( make_index_sequence<strlen_(D::name)>() ); } using D = mp_first< describe_enumerators<E> >; constexpr auto st = to_string<D>(); #include <typeinfo> #include <cstdio> int main() { std::printf( "%s\n", typeid(st).name() ); }

1 0

Endorsement, review manager sought for Boost.Describe
by Peter Dimov 24 Sep '20

24 Sep '20

I would like to submit a C++14 reflection library, Describe, to Boost and I'm looking for endorsements and a review manager. The library is at https://github.com/pdimov/describe and the documentation is at https://pdimov.github.io/describe/doc/html/describe.html. Some examples of what the library enables are given at https://pdimov.github.io/describe/doc/html/describe.html#examples. The purpose of Describe is to establish a standard way of annotating (describing) user-defined types (enums, structs and classes), so that types can be described once, and then their descriptions can be used from other libraries. At the moment, the practice is for each library to invent its own ad-hoc annotation/description mechanism.

7 9

[nowide] cxx11_moveable_fstreams target
by Sean Farrow 24 Sep '20

24 Sep '20

Hi All, By way of context to the following query, I am trying to update the VCPKG boost port to v1.74. I noticed that the nowide library now has a jam file that has the following import statement: import ../../config/checks/config : requires ; Due to the way VCPKG works, I'm copying the config directory to where it is expected and then changing the import statement. But I then get a message that it can't find the cxx11_moveable_fstreams target. Does the nowide build process rely on any other parts of boost config? If not, where is the cxx11_moveable_fstreams defined? I should say that I'm new to the boost build system, so any help is apreciated. Thanks, Sean.

5 9

[review][JSON] The library name...
by Andrzej Krzemienski 24 Sep '20

24 Sep '20

Hi Everyone, Looking at the reviews of Boost.JSON, a number of them fall into a distinctive pattern: reviewers are saying "you did not implement important parts of JSON parsing/serializing", and the authors' reply is "this was not the design goal". My hypothesis is that this is caused by the library name. Simple "Boost.JSON" makes a promise (at least I read it this way) "this is Boost's response to JSON-related problems". And the library does not fulfil that promise. In a sense, the name misguides the potential users who need an answer, sometimes in less than 10 seconds, to the question, "is this library going to address my need?". Maybe the library would encounter a wider consensus if it was called Boost.JSON_Value, or Boost.JSON_DOM. And if the first introductory sentence in the documentation read, "this library provides a type with Regular interface that can represent JSON contents, and provides a convenient way to serialize and then deserialize it fast and possibly in chunks." Alternatively, maybe we can consider the reviewed library as a candidate for a sub-library in a more general module of JSON. Much like Boost.Math aggregates a number of math-related components, we could treat this library as one of a number of components in a more general Boost.JSON_Toolkit library. Regards, &rzej;

1 0