- Boost - lists.boost.org

Re: [boost] [Boost-users] [review][fixed_string] FixedString review starts today
by Peter Dimov 28 Nov '19

28 Nov '19

> I would "precondition" `op+=( char const (&)[ M ] )` (and op=) by failing > at compile time when M > N, because the size is known, but in > fixed_string's case, the size isn't known. No I wouldn't. :-) The size isn't known in this case either. It's better to diagnose_if the whole thing.

1 0

[STLInterfaces] only three operations?
by Andrzej Krzemienski 28 Nov '19

28 Nov '19

Hi, While the formal review of STLInterfaces has not yet started, some early feedback may be of help. The idea to implement relational operators from binary operator- for random_access_iterator looks too clever for me. Maybe this deserves a mention in the documentation it is from operator- that the library will generate all relational ops. For non-contiguous random_access_iterators (like in deque) it might be suboptimal to do it this way: a directly provided operator== might be faster than the one synthesized from operator-. Of course, I can provide the 6 relops operators myself, but I could have only 2 if the facade were capable of generating operator!= from operator== (and similar). Could operator!= for random_access_iterator be generated from operator!= ? Regards, &rzej;

3 5

[FixedString] Deniz' review
by Deniz Bahadir 27 Nov '19

27 Nov '19

This is my review of Krystian Stasiowski and Vinnie Falco's FixedString library. The important question and its answer upfront: - Do you think the library should be accepted as a Boost library? I think it should be ACCEPTED into Boost. It is a very small (almost trivial) library and in the beginning I was not sure if it really should go into Boost. However, for me it looks like a useful building-block, so I vote ACCEPT. And if I remember correctly Vinnie said he is already having some other libraries using it which he wanted to propose for Boost later, so there seem to be some real use-cases for it already. Besides, Boost already has some other smaller building-block libraries, so FixedString should be in good company. On a side-note: It would be helpful for the Boost library documentation overview (e.g. https://www.boost.org/doc/libs/1_71_0/) to allow more views/sort-orders for listing available Boost libraries than the views/sort-orders which are already there. (Having "building-blocks" and especially "newer C++ standard features for C++03" or similar "standard compatibility" categories for the Boost libraries comes to mind.) OK, now back to the review. - What is your evaluation of the design? The overall design looks straight forward. `boost::fixed_string`'s API resembles that of `std::string` and only the internal representation differs largely. This looks like the correct design for the aimed purpose of this library (to provide a dynamically resizable string with compile-time fixed capacity.) - What is your evaluation of the implementation? The implementation looks solid and also straight forward. However, I have some remarks to make which you can read further down in this email. - What is your evaluation of the documentation? The documentation is quite small, except for the reference section. This, however, should be fine considering the very simple and small focus which FixedString has. Regarding the "Iterators" section, it was not clear to me on first read for which string type the iterators are invalidated when moving/swapping. I think, `boost::fixed_string` is meant and not `std::string`, but that was not obvious from first read and the wording should probably be improved there to be unambiguous. (Maybe make this clear by speaking of "FixedString" or "fixed_string" instead of just "string".) - What is your evaluation of the potential usefulness of the library? For the use-cases mentioned in the "Motivation" section of the documentation it seems to be useful. All other use-cases I could think of are specializations of the mentioned use-cases. - Did you try to use the library? With what compiler? Did you have any problems? No, I have not tried to use the library. However, I am curious to know if Boost.String_Algorithms can operate on `boost::fixed_string`, too. If not, it would be nice for the code of FixedString and/or Boost.String_Algorithms to be modified in such a way that they can inter-operate with each other. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I read the documentation, but the reference section I merely visually scanned through. (I assume, there are no mistakes in it, as they mainly resemble the API of `std::string`.) I looked at the implementation but did not look at all function implementations in all depths. I, however, looked at the CMakeLists.txt file, too, and have some remarks for it (see below). Overall, I probably spent about 1.5 hours for the review, not including the writing of this email. - Are you knowledgeable about the problem domain? Only as far as it gets if you are a general user of `std::string`. I have the following additional remarks: * `boost::to_fixed_string` / `boost::detail::max_digits`: - Is the returned `boost::fixed_string` type of `boost::to_fixed_string` large enough to also hold the (plus) sign of an unsigned integer (if a user might want to append it later)? (Reading the comment and implementation of `boost::detail::max_digits` I assume the answer is yes.) Maybe, make this clear in its reference documentation. * "boost/fixed_string/config.hpp": - At the top of this file we have `#define BOOST_FIXED_STRING_USE_BOOST`, which therefore makes all following conditional definitions always use Boost equivalents of standard library types internally. Is it really desired to have it hard-coded here? Shouldn't the user decide if s/he wants to use Boost compatibility types instead of the ones coming from the standard library? * Filenames - I do not really like, that all files have the same name "fixed_string.hpp". There is the main one in "boost/fixed_string", another one in "boost/fixed_string/detail" and a third one in "boost/fixed_string/impl". I would prefer these files having some (at least slightly) different names. * "CMakeLists.txt": - This CMakeLists.txt file is written in Traditional CMake (old style CMake) although requiring CMake 3.5.1 which knows how to handle Modern CMake. You should consider using Modern CMake instead. - You should leave `CMAKE_CXX_FLAGS` untouched. It is for the user of the library, not for the developer! - Similar, set requirements for a specific minimum required C++ version using the `CXX_STANDARD` property instead of hard-coding it into `CMAKE_CXX_FLAGS`. - You should probably replace usage of `include_directories` with `target_include_directories` on the specific targets. - Similar for `add_definitions` and `link_directories`. - Using `file(GLOB...)` for globbing sources is dangerous and CMake might not always realize that some sources have changed. (see note at: https://cmake.org/cmake/help/latest/command/file.html#glob) - In general, I am not sure if that CMakeLists.txt file should have been part of the review, but I recommend to provide a useful and more modern one if this is going to become a part of Boost, too. Best regards, Deniz

6 10

Suggested policy for dropping C++03 support in Boost libraries
by Peter Dimov 26 Nov '19

26 Nov '19

We need a policy on phasing out C++03 support in Boost. C++03 support is holding us back. It impedes development, increases maintenance costs, increases dependencies, and increases compilation times. Library authors and maintainers need to have an approved mechanism for dropping C++03 support in their libraries. The suggested way forward is to allow library authors to declare C++03 support deprecated via a notice in the documentation and a message issued at compile time, then be allowed to drop C++03 support no earlier than three Boost releases later. For instance, a library may declare C++03 support deprecated in Boost 1.73, and drop it no earlier than in Boost 1.76. More at https://pdimov.github.io/articles/phasing_out_cxx03.html.

12 21

Beginner's guide
by Siddhartha Sen 26 Nov '19

26 Nov '19

Could anyone help me get started? This is my first time contributing to open source. I am proficient with C++11 and C++14(Not so much with 17 though). Also, I am not sure whether this is useful or not but I have a very keen interest in algorithms and problem solving techniques in general. Any help would be appreciated.

3 2

Re: [boost] [Boost-users] Interest in a C++20 Unit Testing Framework?
by Krzysztof Jusiak 25 Nov '19

25 Nov '19

Thanks for your valuable feedback. I added initial versions of tutorial and user-guide to README. It's not ideal yet but it's a start. * https://github.com/boost-experimental/ut#tutorial * https://github.com/boost-experimental/ut#user-guide I also updated benchmarks with Boost.Test-1.71.0 (static library). I didn't add Boost.LightweightTest though as it's just assertions (no tests/suites/etc...) so it makes it difficult to compare due to missing features. * https://github.com/boost-experimental/ut#benchmarks I hope that helps a bit. Thanks again, Kris On Fri, Nov 22, 2019 at 1:17 AM Richard Hodges via Boost-users < boost-users(a)lists.boost.org> wrote: > It looks very interesting. The idea of not using macros is very appealing > to me. > > From looking at the examples, I get the feeling of "I could probably use > this". > > However, as the other commenters have mentioned, without a tutorial and > full reference it's difficult to judge whether it's ready for use in > production. > > Are there plans to develop this? > > > > > On Thu, 21 Nov 2019 at 16:24, Krzysztof Jusiak via Boost-users < > boost-users(a)lists.boost.org> wrote: > >> Hi, >> >> I was wondering whether there is any interest in exploring a C++20 single >> header/single module, macro-free Unit Testing Framework with no >> dependencies? >> >> Github: https://github.com/boost-experimental/ut >> >> Additional links: >> - Try it online: https://godbolt.org/z/uVDxkW >> - Benchmarks: https://github.com/boost-experimental/ut#benchmarks >> - How it works?: https://github.com/boost-experimental/ut#how-it-works >> >> Thanks, Kris >> _______________________________________________ >> Boost-users mailing list >> Boost-users(a)lists.boost.org >> https://lists.boost.org/mailman/listinfo.cgi/boost-users >> > > > -- > Richard Hodges > hodges.r(a)gmail.com > office: +442032898513 > home: +376841522 > mobile: +376380212 > > _______________________________________________ > Boost-users mailing list > Boost-users(a)lists.boost.org > https://lists.boost.org/mailman/listinfo.cgi/boost-users >

2 2

[review] [STLInterfaces] STLInterfaces review starts December 10
by Barrett Adair 23 Nov '19

23 Nov '19

The Boost formal review of Zach Laine's STLInterfaces library will take place December 10 - 19, 2019. Please consider participating in this review. The success of Boost depends on our robust library review process. STLInterfaces is a C++14 library targeting ISO standardization. The following templates are provided, all C++20-friendly: 1. iterator_interface - a modern version of the iterator_facade and iterator_adaptor parts of Boost.Iterator 2. view_interface - a pre-C++20 implementation of C++20's eponymous feature 3. container_interface - a tool to eliminate boilerplate when writing new containers. Code: https://github.com/tzlaine/stl_interfaces Docs: https://tzlaine.github.io/stl_interfaces/doc/html/index.html Thanks, Barrett Adair

1 0

icl
by Andreas Fislage 22 Nov '19

22 Nov '19

Hello all, I am new here... I recently used icl and ran into a rather surprising behavior: Assertion failed: (numeric_minimum<domain_type, domain_compare, is_numeric<domain_type>::value> ::is_less_than_or(upper(object), is_right_closed(object.bounds())) ), file ...\boost\icl\concept\interval.hpp, line 438 This is the code to produce the problem: #include <boost/icl/discrete_interval.hpp> int main() { boost::icl::discrete_interval<size_t> x{0, 0}; boost::icl::discrete_interval<size_t> y{0, 1}; boost::icl::contains(x, y); } Note that the assertion fails only with size_t not with int. What could be reason for this?

1 0

Boost serialization (bug?) issue with MSVC, with vector<shared_ptr> in several libraries
by Nicolas Guillot 22 Nov '19

22 Nov '19

We use boost serialization in ours projects, both on linux (gcc) and Windows. We encounter a problem only on Windows (for "every" versions of Windows (7 and 10) and of MSVC: Visual 2010 and 2015, ie. MSVC++ 10.0 _MSC_VER == 1600 or MSVC++ 14.0 _MSC_VER == 1900). *Here is the problem summarized*, but I need to give more details after: When I serialize a class - which have base class - and have 2 vector of shared_ptr of ClassB, with the same contents, and B inherits from the same base class the serialization works, but the deserialization doesn't ("input stream error"). The following image is here : https://i.stack.imgur.com/osoiF.png (if it's not displayed) [image: enter image description here] <https://i.stack.imgur.com/osoiF.png> Yes, it's very strange: - if I remove the base class, it works. - if I inline the serialization code (empty function) of the base class, it works. - if the 2 vectors don't have the same content, it works !! - if I register the ClassBase in the serialize method of ClassTest, it works. I.e.: // in ClassTest:template <class Archive>void serialize(Archive & ar, const unsigned int version) { ar.template register_type<ClassBase>(); ...} *Some details* *When it works* on linux, and when it works on Windows with ClassBase type registration in the archive, we have the same xml output. It's worth noting that: - boost_serialization is version 17 on Windows and 9 on linux (I didn't tried to update boost on linux yet). - On BaseClass xml tag, the tracking_level="1", so we have object_id. *And when it doesn't work* (once again: the serialization of ClassTest is OK, but cannot deserialized "input stream error"): - The main difference is in the serialization of ClassTest: the ClassBase part has no tracking_level. - However it's not the only cause, because if the vectors are differents (same 2 first items, and a third item in one vector), tracking_level of ClassBase in ClassTest part is "0". Last thing, if it can give you some clues: while we debugged our application, we noticed that the deserialization framework tries to deserialize a class into another. It makes me think the serialization framework is confused about the classe types identifications. Could it be a matter of dll linking? Of global static shared storage ? I've posted a visual studio solution here <https://1drv.ms/u/s!Aoy4ax0S3ZS5gkxv1UIvRUd32oVO?e=ACVi4c>. Thanks a lot for your help. And if any clarification is needed, I'm available of course !

2 3

[xpressive] Accept one line pull that's been outstanding for a couple years?
by Brian Kuhl 21 Nov '19

21 Nov '19

Hi Boost, We've been running nightly regression on this for years now at Wind River over a couple Boost releases. Any reason it can't be merged? https://github.com/boostorg/xpressive/pull/5 Thanks Brian

1 0