- Boost - lists.preview.boost.org

[review][fixed_string] Andrzej's feedback
by Andrzej Krzemienski 05 Dec '19

05 Dec '19

Hi Everyone, This can hardly be called a review, as I didn't look thoroughly at the implementation. (I only checked what happens on the resize() over the capacity(), as this was not clear from the docs.) I think that ultimately the library would be a useful addition to Boost, however I would not like to rush it before its design is fully baked, and my impression is that it isn't yet. Therefore my recommendation would be to REJECT the library at this point, and encourage the authors to resubmit it for the second review once the design goals and design decisions have been clearly settled and communicated. My vision of a review is that we: 1. First evaluate the design goals, whether they are worth pursuing 2. Then we evaluate the design *against* those goals. 3. Then we evaluate the documentation and implementation *against* the design and goals. I cannot even go to #3, as to me #1 is missing some parts. There are different possible goals: 1. Treat this new string as many other STL sequence containers with variable size. In particular, users use it as if its max_size() were infinite, and are prepared that at some point an exception might be thrown. 2. Treat it as a "drop-in replacement" for std::string with no-heap-alloc guarantee. 3. Make something suitable for embedded systems where the user provides the guarantee: "I will never make the size() of this string go above this value. If I did, it would be plain clear that the program is not doing what it was supposed to." These goal 3 is in clear conflict with either 1 or 2. This becomes clear when we consider what should be the response to doing a resize() over capacity(): a precondition violation or a normal course of action signaled by an exception. The authors should make a choice which of these goals is not supported and communicate it clearly from the outset in the docs. I think this decision has already been made: the library was extracted from Boost.Beast and there the purpose must have been clear. It is just that it is not communicated in fixed_string library. Any decision is good. In C++ performance trade-offs are part of the contract (interface), so there is room in Boost for many strings: small strings, short codes, fixed size strings, fixed capacity strings. But for each library it should be clear what trade-offs were chosen and why. We have a situation that there exists static_vactor in Boost, which defines the resize() over capacity() to be a precondition violation. And fixed_string needs to provide some response to this fact: why did you choose a different design? I consider the choice of name to be part of the design: you cannot assign the name before you have decided on the goals. "static_string" might be a good name if you chose the same trade-offs as static_vector. But if you make different trade-offs, it might be better to use a different name. Making a resize() over capacity() a precondition violation is a *feature* useful for bug detection and I do not consider it a valid argument that "library will throw exceptions and if you never resize() over capacity() you will never see exceptions or std::abort()". If this is a precondition, then I expect of a library to put some BOOST_ASSERT() or _builtin_unreachable() in those paths to enable better bug detection. I find the goal "a drop-in replacement for std::string" invalid. You surely mean only a drop in replacement for some subset of usages. I guess this subset comes from the usage in Beast, and I would expect that it is clearly outlined what this subset is. One of the operations on strings that I use most often is operator+, so when I hear that this operation is not implemented in a class that claims to be a drop-in replacement for string, I see a contradiction. There might be valid reasons not to provide operator+, but the documentation cannot state that this is a drop-in replacement for std::string. I think that only after the above issues have been sorted out can we have a review of the implementation and the documentation. One remark about documentation is that I was not able to find what `resize()` over `capacity()` does. This is the most important information that I was after. anything else is more less intuitively clear from the analogy to std::string. I hope that this feedback doesn't sound discouraging. I appreciate the work Krystian and Vinnie have put into making this submission, and I would like to see this library ultimately included in Boost. Regards, &rzej;

7 27

iostreams gzip_compressor
by Kemin Zhou 05 Dec '19

05 Dec '19

I have been using the compressor and decompressor for a while now. One of the issues is the performance not sufficient for large data operations. The underlying zlib library is single-threaded, and there is a parallel version implementation at application level https://zlib.net/pigz/ pigz. When working with large file compression and decompression it usually take 8 hours to do the job. If I can use multi-threaded version then it usually can be done within one hour. There is a strong need to use multi-threading to speed up this process for me. I would appreciate that someone can implement this feature. If not I can work on this project. Not sure what's the best way to go about this. -- Kemin Zhou 858 366 8260

1 0

[fixed_string] Copying/comparing entire strucutre
by Phil Endecott 05 Dec '19

05 Dec '19

Dear All, Considering small-capacity fixed_strings like the example that I gave previously: struct NameAndAddress { static_string<14> firstname; static_string<14> surname; static_string<30> address_line_1; static_string<22> city; static_string<10> postcode; }; I have been looking at how best to copy and compare them. For small-capacity strings, and also for large-capacity strings when their size approaches the capacity, it will be quicker to unconditionally copy/compare everything, including the unused bytes beyond the end, rather than looping over just the current size. I've tried a very crude benchmark based on this: struct string { uint8_t size; std::array<char,N> data; }; extern void copy_all(string& dest, const string& src) { dest = src; } extern void copy_size(string& dest, const string& src) { dest.size = src.size; std::copy(src.data.begin(), src.data.begin()+src.size, dest.data.begin()); } Results will depend on the architecture but I found that for N < 64 it was probably always best to copy_all(). For N==255, time for copy_all() and copy_size() is about equal when the container is half full. Things are more complicated for operator== because of the unused bytes. It would be necessary to initialise everything to 0 and maintain that during e.g. erase() and assign(). I haven't tried to benchmark that but I suspect the trade-off would be similar. operator< is a mess due to endianness. I don't know whether any compilers or memcmp() implementations are smart enough to use byte-swap instructions to process data 4 or 8 bytes at a time. I don't think I'm suggesting that this should necessarily be implemented in fixed_string, at least not without lots more investigation, but it does illustrate more of the trade-offs that exist between different applications. Regards, Phil.

2 1

[ Review ] [ fixed_string ] Accept
by JeanHeyd Meneide 05 Dec '19

05 Dec '19

Dear Boost, This is a review of boost.fixed_string. It is my first review, so take it with a grain silo's worth of salt. ------------- Summary 📝 -------------- Accept fixed_string. It's about ---------------- What I Did ⚙️ ---------------- - I ran its tests, VS 2019 i686 and x86-64 | VS 2017 i686 and x86-64 | MinGW 9.2.0 i686 and x86-64 - I put it inside itsy.bitsy (https://github.com/ThePhD/itsy_bitsy) and used it as an underlying container in its tests. - I put it inside my private text repository as an underlying container to hold code units for several different encoding schemes and it work (https://github.com/ThePhD/text-dev | far-behind implementation at https://github.com/ThePhD/text) - I generally messed around with it in a basic main.cpp file and read the docstrings and docs while comparing it to cppreference. -------------- Strengths 💪 -------------- +1 - Follows std::string's container design nicely, making it easy to program around and know what to expect from the outset. (Side note: ignore whoever said to remove the initializer list ones: I used all of them. It's necessary to be considered a SequenceContainer (https://en.cppreference.com/w/cpp/named_req/SequenceContainer).) +1 - Works with all character types. char, wchar_t, char16_t, char32_t, and -- in C++20 mode -- char8_t for the compilers that have it. +1 - insert, erase, clear, push_back, push_front meet specification I flexed it by inserting it as part of itsy.bitsy's tests and using it as one of its sequence containers. +1 - docs are straightforward. +1 - iterators work just fine. I tested it using itsy.bitsy as an underlying container for a reference_wrap'd bit_view as well as a stress testing it under my phd::text implementation. It worked fine as an underlying container for UTF8, UTF16. UTF32, and UTF-7-EBCDIC storage. +5000 - Standalone. I wish more Boost libraries were packed this way. I can make it not depend on Boost as a whole; great for dropping into random codebases and using as a replacement. Also compiles faster for those of us who have C++17+ capable compilers. ------------------- Weaknesses 🤒 ------------------- -1 - Naming. fixed_string<500> works, wfixed_string<500> doesn't, basic_fixed_string<char, 5000> doesn't either. It uses a different naming scheme from the standard, and led me around in circles on first use until I forced myself to read the template head of the class declaration. But it's Boost, so we can afford to be different and stuff. Just don't do static_vector. :D -0 - operator+ I wanted it. It wasn't there. I can see why, since you would have to pessimistically expand the size to the max between the two. Do enough additions and you can explode the final result's stack size several, so this isn't really a loss. Besides,-0 is just 0 on any reasonable 2's complement machine. -0 - noexcept It's 2019, everyone's getting on the noexcept train. Don't let it leave you behind! -2500 - Constexpr is lacking. I could not compile any of itsy.bitsy's constexpr, compile-time, or static_assert tests. I could not compile any of the static_assert tests from latest private text development. This prevents a wide range of applications, including my failure to substitute boost.fixed_string for Hana's Fixed String implementation in CTRE and failure to use fixed_string as a compile-time buffer for encoded and decoded text. -------------- Misc. -------------- - I see you added subview, very nice. 👏 - substr should continue to return a fixed_string. - The empty optimization and size optimization is important. Don't listen to anyone who tells you fixed_string<0> should report false for std::is_empty_v<fixed_string<0>>. I spend LITERALLY MILLIONS OF YEARS (definitely literally) programming special __ebco<T, tag> or slapping [[no_unique_address]] on things to cut down on memory sizes. Please don't cause a cascade of bloated size with MSVC's current crappy base class """optimization""" rules (the new, better ones are still opt-in because yay, ABI breaks). The closer things are to being small enough or trivial enough that they get register-passed, the better. - Speaking of the size optimization, MSVC's standard string also employs a trick where they shove the size in the last CharT. May be of use to you here, but probably not worth the efforts. -------------- Unrelated -------------- The following is boring things not related to the review but stated here for extra flavor that can be completely ignored: - Boy that CMake file hurts my feelings. I fixed it up so I could use it with add_subdirectory. It promised me an easy integration and smacked me upside the head instead. But at least I could get the tests going soon enough. Maybe don't commit it, it gives the impression it's for public consumption (it's not). - Tests are slightly inscrutable, better names would be nice. - For constexpr: use a union of { char derp; CharT value; } and value-initialize the char. Provide iterators that walk over the union and on deref directly handle you the CharT& lvalue reference. .data() is unimplementable as constexpr like this but who cares: you have a constexpr begin() and that's what people should be using. .data() is for type-punning shenanigans. - You should turn up the warnings on MSVC: there's a few places where there's an implicit narrowing thanks to going from size_type (std::size_t) to smallest_width_t and MSVC gives a snippy warning. Overall, yay! Try to get the constexpr stuff in quick; that's what's going to make this library interesting to use for C++20 and beyond, and have Boost libraries start being things to look forward to, rather than representing the Old, Boring Establishment that I reach for when I hear the words "Sea Plus Plus Oh Three". Great Job, JeanHeyd Meneide

3 3

[release][proto]: MSVC 19.24.28314 (VS 2019 16.4.0) )won't compile proto's generate.hpp
by Löw, Tobias (STEAG Energy Services GmbH) 05 Dec '19

05 Dec '19

Hi, the latest MSVC version (shipped with VS 2019 16.4.0) doesn't compile boost/proto/generate.hpp since there is an old MSVC-fix, which is no longer needed, and now even produces errors. The "develop" branch of proto contains a fix for that since 2015 (!) but it never made it to the master branch. (https://github.com/boostorg/proto/issues/20) Could some please merge it over to make it into release 1.72 - would be really great! Tobias

1 0

[review][fixed_string] FixedString review starts Nov 25
by Joaquin M López Muñoz 05 Dec '19

05 Dec '19

The Boost formal review of Krystian Stasiowski and Vinnie Falco's FixedString library will take place November 25 - December 4, 2019. This is an early call for you to consider participating in the review. Feedback and constructive criciticism from experts and not-so-experts alike is very much welcome. FixedString being a relatively small and straightforward library, you will find it very easy to familiarize yourself with it and contribute back to the community. FixedString provides a dynamically resizable string of characters with compile-time fixed capacity and contiguous embedded storage in which the characters are placed within the string object itself. Its API closely resembles that of std::string. GitHub repository: https://github.com/18/fixed_string Online docs: https://18.github.io/doc/fixed_string If you feel like reviewing FixedString you can start now prepping --though I'd ask you to refrain from submitting actual reviews till Nov 25. Read the docs, download/fork the code, read/run it, maybe try integrating it into some project of yours, ask questions to the authors, preferrably on Boost or Boost Users mailing lists. The FixedString initiative arose from a very lively discussion within the community: https://lists.boost.org/Archives/boost/2019/09/246943.php , so I sincerely hope this review will be a fruitful, crowded one. Don't let me down! Best regards, Joaquín M López Muñoz Review manager for candidate Boost.FixedString

5 5

Generic Image Library
by Siddhartha Sen 05 Dec '19

05 Dec '19

Being new to this, I have tried looking up the functionalities of GIL. I was thinking of implementing the addition of negative image conversion as well to GIL, incorporating the usage of parallel programming using OpenMP library. Is there any demand for that? I feel that parallel programming will massively improve the computational efficiency of GIL.

2 1

[review][fixed_string] review period extended to Dec 8
by Joaquin M López Muñoz 05 Dec '19

05 Dec '19

After conversation with the review wizards, the review period for candidate Boost.FixedString is extended till Sunday, Dec 8. Hopefully this will allow for some more reviews to come in and for the ongoing discussions to stabilize. So, if you're considering to submit your review, now is the time to reserve some time to do so. Thanks to everybody who has contributed so far, it is a very productive review we're having. Joaquín M López Muñoz Review manager for candidate Boost.FixedString

1 0

Re: [boost] [fixed_string][review] Review of fixed_string
by Peter Dimov 05 Dec '19

05 Dec '19

> - everything should ideally be constexpr. The problem here is that > constexpr requires initializing all elements, and this will heavily > penalize runtime uses of f.ex. fixed_string<512>. On compilers with > __builtin_is_constant_evaluated (gcc 9, clang 9) we should use that; > otherwise, it might be worth it to create a specialization for N < some > suitable upper limit. Wait, I have an idea. template<std::size_t N> struct fixed_string { private: std::size_t size_ = 0; union { char first_ = 0; char data_[ N+1 ]; }; public: fixed_string() = default; }; Now default initialization sets just the first char to zero, as we want, and value initialization initializes all data_ to zero and is constexpr. auto f1() { fixed_string<24> s; return s; } auto f2() { constexpr fixed_string<24> s{}; return s; } https://godbolt.org/z/uhf4S4 I don't know if that's defined behavior or not, but if it isn't, it better be.

2 1

[review][fixed_string]
by Peter Koch Larsen 04 Dec '19

04 Dec '19

Dear boosters Here is my review of fixed_string > - What is your evaluation of the design? I have just completed a similar but much less ambitious design - about 700 LOC in total. The purpose is to replace char string[N] representing string in an ageing code base that is C++98 currently and partly embedded. My design does support a partial compatibility with std::string but that was not the primary goal. The interface compatibility of std::string is a nice feature, but I do not see a reason to attempt to make it a drop-in replacement. The non-compatibility with char[N] is missed by me and probably also some other in the embedded domain. It would be nice if fixed_string<N> had size = N + 1 for char types. > - What is your evaluation of the implementation? Nice and clean. As others have noted, constexpr and noexcept support would be nice. I would also prefer if I could have an option that does not require usage of exceptions, perhaps as a configuration option. Specifically, I would like to be able to control error handling (terminate instead of throw, ability to react to undefined behaviour). Also, I would like to have more forgiving functions that could return the status of failing operations. > - What is your evaluation of the documentation? Nice and clean. > - What is your evaluation of the potential usefulness of the library? If the interface could be extended, It could potentially be useful to many - and to me - if I manage to convince my company to ugrade to C++17. So to summarize: 1) compatibility with char[N]: this requires that the size member is removed. In my source, I still have an O(1) size implemented by having data[N] give the free space in the string. If data[N] == 255, this indicates that the real free size is stored in the elements data[N - 1] and below. There are many ways to encode that length portably. 2) append and assign could have companion functions, that behave in spirit like strncpy/strncat. I have named these function try_append and try_assign. 3) Errorhandling strategy available. > - Did you try to use the library? With what compiler? Did you have > any problems? No, just reading code. > - How much effort did you put into your evaluation? A glance? A quick > reading? In-depth study? About three hours reading and writing this comment. > - Are you knowledgeable about the problem domain? Yes. > > And finally, every review should answer this question: > - Do you think the library should be accepted as a Boost library? The constexpr and noexcept parts should be fixed and compatibility with char[] would be nice. But yes, it should be accepted.

1 0

How to handle NULL string for UTF conversion function
by Alexander Grund 04 Dec '19

04 Dec '19

Hi, in my work on Boost.Nowide I encountered a valid NULL string and am unsure how to handle it. Context: Every wrapper functions is basically implemented like: int fFOO(const char* s){ wstackstring const ws(s); // Converts UTF-8 to wchar-buffer/string return _wfFoo(ws.c_str()); } Similar functions like `std::wstring widen(string-or-const-char-ptr)` are provided which can be used like `return _wfFoo(widen(s).c_str());` in the example above. All was fine, because (IIRC) calling e.g. `fopen(NULL)` is not allowed anyway. However `freopen` DOES allow a NULL for the string. So now I'm left with a couple options and would like some opinions on them: 1. Make (w)stackstring aware of NULL input and if default constructed or with NULL return NULL for c_str(). Makes it easy to use as one could even say `return _wfFoo(wstackstring(s).c_str());` w/o any checks but would be inconsistent with the `widen` functions which convert the passed pointer into a std::(w)string and hence require != NULL 2. Disallow NULL (via assert) for all conversions and require manual checking. Best usage would then probably be to ditch the temporary and do `return _wfFoo(s ? wstackstring(s).c_str() : NULL);` 3. Just like 1. but rename (w)stackstring to e.g. (w)cstring (or ncstring/wcstring, or narrow_cstring/wide_cstring) to highlight that it acts like a C-String (and can be NULL as opposed to empty but never NULL) 4. Ditch stackstring entirely. It was complained about by Zach during the review although defended by the author as "stackstring is barely on-stack buffer optimization - it isn't general string and never intended to be so. It isn't in details because it can actually be useful outside library scope." So this would worsen performance a bit as usual SSO are to small for common filenames. Thanks for reading and any insight is welcome! Alex

6 5

[fixed_string] Gavin's review
by Gavin Lambert 04 Dec '19

04 Dec '19

This is my review of the proposed FixedString library. - Do you think the library should be accepted as a Boost library? Yes, I think it should be ACCEPTED into Boost. Regarding the bikeshedding of the library/class name itself, I prefer "fixed_capacity_string", as the most accurately descriptive name I can either think of myself or that I have read posted by others. I don't think we should be afraid of longer class names, even for vocabulary types. People can always alias them to something shorter to save typing. (Second choice would be "array_string", although that risks misinterpreting as "string_array", which is something entirely different. "stack_string" is another possibility, though might be misleading if contained within another object on the heap.) - What is your evaluation of the design? Overall, looks good. I agree with the motivations for creating such a type in the first place. I would prefer if it didn't reinvent some existing storage concepts already provided by boost::static_vector (and I don't entirely buy the "reduce dependencies" arguments); however there are some other justifications for this that I do consider valid (such as static_vector not being constexpr). As previously noted, I think implementing substr to return a string_view is a mistake; this will cause lifetime problems if someone tries to drop-in replace a std::string in existing code (which was one of the motivating use cases). I'm happy with this being implemented as a new method "subview". (Maybe std::string should do the same thing...) However I still disagree with the choice to also provide "substr" but with a fixed_string return type. Its semantics (with regard to the capacity of the returned string) are still sufficiently different from std::string as to make its usage confusing and poor-performance-prone. With the method omitted, someone attempting a drop-in-replacement will get an error and will need to decide how best to handle it (usually by using subview, but this may require other changes to extend lifetime, which is why spelling subview as "substr" was bad). And if they really want a copy of the substring, they can still do that via subview simply by assigning it to a fixed_string variable -- this would also require them to explicitly choose an appropriate capacity, which I regard as a good thing. For similar reasons to the above, my preference is also to entirely omit operator+ (as in the current design). The consumer can decide how to rewrite things to use operator+= instead. (While there are ways to implement operator+, as has been discussed, all of these come with hefty caveats and I don't think a compromise is sufficiently safe.) - What is your evaluation of the implementation? I did not have time to do more than glance at the implementation. Although I did previously note (thanks to Deniz for calling attention to it) that the unconditional #define BOOST_FIXED_STRING_USE_BOOST in config.hpp is not the correct usage for configuration defines in Boost. I also think that this could make better use of Boost.Config's existing defines -- while a stated goal was to also produce a standalone library, this could be done by using Boost.Config inside of Boost and using a standalone mini-config header with equivalent defines only for the standalone build. I'm also dubious about the division of implementation between three identically-named header files. Unless this is required for avoiding-ugly-docs reasons I think it would be preferable to merge these into a single header -- and perhaps only a single header, where Boost.Config is used. Finally, though, I wonder if perhaps a variation of this type should be implemented which has as storage only the array itself without a separate size member. This might better serve some serialization or I/O scenarios (as a drop-in replacement for a raw char array), although with the caveat that it would probably have to rely on strlen-equivalents and thus could not contain embedded nulls (which is why it should be a separate type, if implemented, as this is a larger departure from std::string). As this would also typically have a smaller capacity than other use cases it could do things like zero-init which might be too expensive for the general-purpose fixed_string, but which can be very helpful for serialization scenarios. - What is your evaluation of the documentation? The documentation is very short, but seems sufficient for the small scope of the class. - What is your evaluation of the potential usefulness of the library? I think it will be extremely useful. I do wonder if an immutable_string type would also be useful (especially for constexpr), but that could be a separate library. - Did you try to use the library? With what compiler? Did you have any problems? I did not try it. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? A quick reading. Probably a couple of hours in total spread over the entire review period. - Are you knowledgeable about the problem domain? Yes, I frequently work on code where heap allocation is constrained or disallowed. And with strings.

3 2

[review][fixed_string] FixedString review starts today
by Joaquin M López Muñoz 04 Dec '19

04 Dec '19

The Boost formal review of Krystian Stasiowski and Vinnie Falco's FixedString library starts today November 25 and extends up to December 4. Description FixedString provides a dynamically resizable string of characters with compile-time fixed capacity and contiguous embedded storage in which the characters are placed within the string object itself. Its API closely resembles that of std::string. Repo and docs GitHub repository: https://github.com/18/fixed_string Online docs: https://18.github.io/doc/fixed_string Review questions Here are some questions you might want to answer in your review: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? And finally, every review should answer this question: - Do you think the library should be accepted as a Boost library? I invite you to submit your review, either publicly to the developers or the users lists, or else, if for whatever reason you don't want to go public, directly to me. Thank you for investing your time on reviewing Krystian and Vinnie's work and for contributing to the advancement of Boost. Best regards, Joaquín M López Muñoz Review manager for candidate Boost.FixedString

11 39

Error handling benchmarks: LEAF, Boost Outcome
by Emil Dotchevski 02 Dec '19

02 Dec '19

I wrote a benchmark program for LEAF and Boost Outcome. Here are the results: https://github.com/zajo/leaf/blob/master/benchmark/benchmark.md

3 4

Reminder: Master branch closes for the 1.72.0 release on Wednesday
by Marshall Clow 02 Dec '19

02 Dec '19

See the calendar at https://www.boost.org/development/ -- Marshall P.S. Don't forget the release notes!

3 5

Interest in making template programming imperative?
by Tianjiao Yin 02 Dec '19

02 Dec '19

Hi there, Is there any interest in library that makes template programming imperative. Basically it provides following API VAR(T); // define a variable T SET(T, Type1); // Assign T = Type1 GET(T); // This macro will be expanded to Type1 SET(T, Type2); // Re-assign T = Type2 GET(T); // This macro will be expanded to Type2 The same idea applies to constexpr variable as well. I.e. it's possible to re-define constexpr variable after initialization, though this functionality is not implemented yet. - Github: https://github.com/Mizuchi/tm - Try it online: https://godbolt.org/z/yfQb4K Thanks, Tianjiao

1 0

Fixed String review
by Phil Endecott 02 Dec '19

02 Dec '19

Dear All, Here is my review of the proposed Fixed String library. In summary I think this would be a useful thing to have in Boost, but there are a few issues with the code as it currently stands. This is based on studying the code and docs and the previous mailing list discussions in September; I haven't actually tried to use the library. Firstly regarding the name, I would much prefer static_string for consistency with boost::container::static_vector and with P0843. Note that static_vector was the preferred name in an LEWG poll, according to P0843. It's true that "static" is an ambiguous word that does not really convey what is different about this string, but then neither does "fixed" in my opinion; "fixed capacity" would, but just "fixed" sounds more like "immutable" to me. On the subject of P0843, it it worth reading as it contains some useful links and rationale: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0843r2.html Also a more recent r3 update and reference implementation: https://github.com/gnzlbg/static_vector Here are the features that I think are missing, in no particular order; apologies if some of this does exist but I've missed it: - Much more of it should be constexpr. See P0980R1. That mentions that some of char_traits needs to be constexpr as a prerequisite, but even without that things like size() and empty() can be constexpr. There is also a question of whether all of the elements must be initialised (to 0) by the ctor to be constexpr, which could be costly for a large but sparse container, though it does mean that subsequent push_back()s don't need to store terminators; I don't understand all the issues involved here. (I note a comment in the docs suggesting the lack of constexpr may be temporary.) - In the same vein, more of it should be noexcept - why aren't empty() and size() ? - You can add a specialisation for size 0 that turns it into an empty struct. - You can add a string literal operator"". - You can add std::hash overloads. There are various possibilities for what should happen if the capacity is exceeded, including throwing an exception, asserting, and allowing undefined behaviour. I'm not sure what I would really prefer though I think I'd be more likely to assert() than to throw. See P0843r2 again which discusses this. Regarding your deviations from std::string: operator+ has been omitted because you consider it's not possible to determine a reasonable return type; isn't it just size N+M ? Do you reject that just because it could end up rather large after a sequence of additions? I'd agree if it were N*M but not really for N+M. Have I missed something? You've chosen to return a string_view from substr(). I think that's a bit dangerous; code that does "auto a = s.substr(...)" could end up with a dangling view when s is a fixed string; this makes it more difficult than it should be to migrate from one string type to another, or to write generic code. Regarding the docs, it would be great if the reference could have some highlighting (e.g. bright red?) for the few places where it differs from std::string. My own use for this sort of string has often been to store very large numbers of small strings when total memory usage has been a concern. (A good example would be an textual ID code of some sort, like a postal code or an airport code etc.) For this case, the 8-byte overhead for the size_t length field is a concern; I'd like a static_string<6> to need only 8 bytes total. I suggested changing this to the minimum size needed to store values 0 to N in the previous email discussion, but that hasn't been implemented. My initial thought was that static_string should be implemented on top of boost::container::static_vector<char>. My rationale for that was that static_vector is well-established and doesn't need to be re-implemented, and that a string_facade that adapts a vector<char>-like interface into a string-like interface would be a useful component in its own right. (I've tried to write something like this myself, but it gets tedious very quickly writing out all of those special string methods.) But then I discovered that actually boost::container::static_vector is not implemented as a simple size,data[] pair; apparently it contains pointers to its own storage. So it isn't even trivially- copyable. Now that I know that, I wonder if what we really need is a low-storage-overhead static_vector "done properly" (like the P0843 reference implementation), with a string_facade to make static_string from static_vector<char>. On balance, my view is that this proposal is promising but not quite ready yet. I suggest that the authors should be asked to come back in a few months with a revised version. My preferred design would be an improved static_vector and a string_facade that converts it into a static_string, but if they don't want to do that then simply tidying up the constexpr, noexcept and hash issues would be minimally sufficient. Regards, Phil.

9 23

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

02 Dec '19

> This one at least does something: > > http://quick-bench.com/g_-BAIENMHQ1Pi1d136FBdp0idQ > > It still measures nothing though; the string isn't actually written. Finally, this one actually bothers to write the characters: http://quick-bench.com/-FUFkLtQeEa3brMf-y139G3Bbcg Quickbenches aren't very representative.

1 0

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

02 Dec '19

> Wait, I forgot to increment the size! > > http://quick-bench.com/sI71NY7OpQ8ft27HpELko8q_4xM > > Not much improvement anyway. This one at least does something: http://quick-bench.com/g_-BAIENMHQ1Pi1d136FBdp0idQ It still measures nothing though; the string isn't actually written.

1 0

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

02 Dec '19

> > Zach Laine wrote: > > Ok, I tried this myself on Quickbench: > > > > http://quick-bench.com/WZPNHFBKI-hFxThBYRZVjndtBho > > I tried to fix that to add the null terminator, but as a result both > push_backs were entirely optimized away. > > http://quick-bench.com/DtPR9Yov1TSzUFeYRx0ipVvUYBk Wait, I forgot to increment the size! http://quick-bench.com/sI71NY7OpQ8ft27HpELko8q_4xM Not much improvement anyway.

1 0

Boost 1.69 on Fedora/PPC64LE: tests results
by REIX, Tony 02 Dec '19

02 Dec '19

Hi, I'm testing Boost v1.69 on Fedora 31 / PPC64LE , as explained at: https://www.boost.org/development/running_regression_tests.html And I see many errors: 1 Failed test out of about 11 Run tests: # cd status # ../b2 ... Passed 101532 tests Failed 10368 tests 90.7% of tests completed sucsessefully Passed 1188 tests Failed 15 tests 98.8% of tests completed sucsessefully I do not know what I made wrong. So, since I do not see any Fedora/PPC64LE machine in the BuildFarm: https://www.boost.org/development/tests/master/developer/summary.html I'd like to know where I could find the summary of the official tests of Boost 1.69 on Fedora/PPC64LE. Thanks/Regards, Tony Reix

1 0

Matrix Multiplication
by Siddhartha Sen 01 Dec '19

01 Dec '19

Having gone through quite a few libraries, the ones that intrigued me the most are Boost.Algorithms and Boost.GIL. I had an idea for Boost.GIl in fact. Basically what I wish to propose(please do correct me if it already exist) is a library that will have the functionality to convert a image to a negative one (I found the conversion of colour image to black and white functionality, but not this). Also, the process can be massively sped up by the incorporation of parallel programming paradigms like OpenMP. Do let me know what you guys think about this.

1 0

[fixed_string] Why "fixed" rather than "static"?
by Andrzej Krzemienski 29 Nov '19

29 Nov '19

Hi Everyone, First, I would like to thank Vinnie and Krystian for writing and sharing the library. While this is not a review, I would like to share a thought about the choice of name. Given that we have static_vector, which seems to be doing a similar thing, why was this library called fixed_string rather than static_string? I note that name fixed_string has some potential to mislead the users as it might imply that it is the size that is fixed (like "a string that always stores 2-letter country codes"). I am not saying that the name choice is wrong. I would just want to see the rationale. Regards, &rzej;

5 8

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

29 Nov '19

> and yes, you can write code that will be correct if op+= doesn't check. Maybe you can, but I apparently can't. This is what I just wrote: void my_append( fixed_string<512> & s, std::string_view s1, std::string_view s2 ) { if( s.size() + s1.size() + s2.size() > s.max_size() ) throw std::length_error( "" ); s += s1; s += s2; } Is this correct? (Spoiler: no.)

2 2

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

29 Nov '19

> https://godbolt.org/z/Z37Pmx > https://godbolt.org/z/CXHRKQ I forgot to maintain a 0 terminator in this sketch; it's even worse with it. .L5: add rax, 1 movzx ecx, BYTE PTR [rdx] cmp rax, 512 ja .L11 add rdx, 1 mov BYTE PTR [rdi+7+rax], cl mov BYTE PTR [rdi+8+rax], 0 mov QWORD PTR [rdi], rax cmp rsi, rdx jne .L5 https://godbolt.org/z/nhYZQY .L3: movzx ecx, BYTE PTR [rdx+rax] mov BYTE PTR [rdi+8+rax], cl add rax, 1 mov BYTE PTR [rdi+8+rax], 0 mov QWORD PTR [rdi], rax cmp r8, rax jne .L3 https://godbolt.org/z/pGJRWs

1 0

Re: [boost] [review][fixed_string] FixedString review starts Nov 25
by Peter Dimov 28 Nov '19

28 Nov '19

> Also, a synopsis section in the documentation might have been nice, to > allow one to see all the declarations in one place. (Admittedly, the main > header does serve that purpose somewhat.) I join the others in noting the pervasive lack of constexpr and noexcept. Even the default constructor isn't either. Can't think of a reason why it would throw. (The lack of constexpr is much easier to explain.) Also, Traits template parameters were wrong in C++98, and they remain wrong today, even though the committee has propagated that mistake into string_view.

2 1

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

Re: [boost] Jason is getting MARRIED!
by julien.blanc＠tgcm.eu 21 Nov '19

21 Nov '19

"Vinnie Falco" vinnie.falco(a)gmail.com – 21 novembre 2019 15:29 > Yep, the bench program and input files are here: thanks. I'll try to compile it for raspberry pi and report the results here. > > A 200MB file would be a good start to see how the library deals with large files. > > I don't have a 200MB JSON file, and I have doubts that it would > provide much more information than what we have already. I'd also > prefer not to put a 200MB file into the repository. The goal of this > library is to be in the same ballpark as rapidjson, it doesn't try to > be the top performer (in fact, rapidjson achieves its performance by > making usability tradeoffs which are unsuited for vocabulary types). > > However if someone wants to run the bench program on a 200MB file or > any other custom inputs and report the results, that would be great! Just made the test, and the validator performs well (memory consumption is about the size of the file, which i is expected since the whole file is read in memory), while the printer memory usage was huge (i had to stop it, but it was at that time already eating more than 1Gbyte memory, which is not expected). Regards, Julien

2 1

istream_iterator_limited
by Frederick Gotham 21 Nov '19

21 Nov '19

[MODERATOR: I tried to post this a week ago, but for some reason the word SPAM was prefixed to the subject line and so it didn't show up on the GMane server. I don't think many people actually saw it.] - - - - WHY I NEEDED THIS: I wanted to open a file using "ifstream", and then I wanted to read 32 bytes from the file and feed them directly into boost::algorithm::hex. Unfortunately I couldn't do this because 'hex' takes two iterators [begin,end), and there's no alternative function "hex_n". So I had to read the file into a string first, and then pass the string to 'hex'. - - - - THE IDEA I CAME UP WITH: Open the file using "ifstream", and then use a special iterator that will stop reading from the file after 32 bytes, with syntax like this: ifstream logfile("log.txt"); hex( istream_iterator_limited<char>(logfile,32), istream_iterator_limited<char>(), g_some_global_container.begin() ); - - - - SAMPLE CODE: #include <cstddef> /* size_t */ #include <iterator> /* istream_iterator */ template <typename T> class istream_iterator_limited : public std::istream_iterator<T> { protected: std::size_t const m_limit; std::size_t m_current_count; public: /* Shorter names */ typedef std::istream_iterator<T> Base; typedef istream_iterator_limited<T> This; istream_iterator_limited(typename Base::istream_type &obj_stream, size_t const arg_limit) : Base(obj_stream), m_limit(arg_limit), m_current_count (1) { /* The initialiser list above does all the construction work */ } istream_iterator_limited(void) /* This gives the End-Of-Stream iterator */ : Base() , m_limit(0), m_current_count(1) { /* The initialiser list above does all the construction work */ } This &operator++(void) { if ( m_limit <= m_current_count ) { Base::operator=( Base() ); /* Becomes End-Of- Stream iterator */ } else { ++m_current_count; Base::operator++(); } return *this; } }; #include <algorithm> /* copy */ #include <string> /* string */ #include <sstream> /* istringstream */ #include <iostream> /* cout, endl */ #include <iterator> /* back_inserter */ auto main(void) -> int { std::istringstream iss("123456789"); std::string str; /* Let's use copy to read 5 char's into our string */ std::copy( istream_iterator_limited<char>(iss,5), istream_iterator_limited<char>(), std::back_inserter(str) ); std::cout << str << std::endl; str.clear(); /* Get another 3 */ std::copy( istream_iterator_limited<char>(iss,3), istream_iterator_limited<char>(), std::back_inserter(str) ); std::cout << str << std::endl; }

1 1

[release] Boost 1.72.0 Beta 1
by Michael Caisse 21 Nov '19

21 Nov '19

Boost release 1.72.0 beta 1 is now available at: <https://dl.bintray.com/boostorg/beta/1.72.0.beta.1/source/> The SHA256 checksums are as follows: 5a6b5cbd27b8ca0c7741b715e022a3bf05aecbb1e73dc72dd82eef9622374bd5 boost_1_72_0_b1.7z 6c85a7aed198757f5e4be66a971ae90a25c4ce32703fecfb5bb19019bd80947c boost_1_72_0_b1.tar.bz2 be4a3fdaa84d5a8b25863651043308e02645f3fbf772b7623ee6462fb1dbad09 boost_1_72_0_b1.tar.gz 95181a5f3de0078b8fc031f63a4dc8be4d70b7d3d5cde3b266d2cd98bd4b61b0 boost_1_72_0_b1.zip For details of what's in the release, see <https://www.boost.org/users/history/version_1_72_0.html>. Please download the beta, give it a try, and report any problems you encounter. Thanks, -- The Boost Release Team

1 0

[release] Boost 1.72.0 Beta 1 Release Candidate 2
by Marshall Clow 21 Nov '19

21 Nov '19

Boost release 1.72.0 beta 1 rc2 is now available at: <https://dl.bintray.com/boostorg/beta/1.72.0.beta.1.rc2/source/> The release notes are not yet available. The updated documentation is not yet available. [ They will be available in a day or two. ] The SHA256 checksums are as follows: 5a6b5cbd27b8ca0c7741b715e022a3bf05aecbb1e73dc72dd82eef9622374bd5 ./boost_1_72_0_b1_rc2.7z 6c85a7aed198757f5e4be66a971ae90a25c4ce32703fecfb5bb19019bd80947c ./boost_1_72_0_b1_rc2.tar.bz2 be4a3fdaa84d5a8b25863651043308e02645f3fbf772b7623ee6462fb1dbad09 ./boost_1_72_0_b1_rc2.tar.gz 95181a5f3de0078b8fc031f63a4dc8be4d70b7d3d5cde3b266d2cd98bd4b61b0 ./boost_1_72_0_b1_rc2.zip Changes since RC1: * Fix Boost.IOStreams to allow compilation on Mac OS w/LZMA support. Please download the beta release candidate, give it a try, and report any problems you encounter. Thanks, -- The Boost Release Team

2 2

[release] Boost 1.72.0 Beta 1 Release Candidate 1
by Michael Caisse 18 Nov '19

18 Nov '19

Boost release 1.72.0 beta 1 rc1 is now available at: <https://dl.bintray.com/boostorg/beta/1.72.0.beta.1.rc1/source/> The release notes are not yet available. The updated documentation is not yet available. [ They will be available in a day or two. ] The SHA256 checksums are as follows: 3dd80fc3979c312bf892398c35778d821f6744a7fbf76c8248c85b4f3702e4d4 boost_1_72_0_b1_rc1.7z 676e476a2a1246c7c5e8f40230fa70469f29dfe8aaa5bce0a85f94692e605c68 boost_1_72_0_b1_rc1.tar.bz2 e62e5fdffe0772309c77fc9463a95350ebcabb2ce03f2c6ee177123016756044 boost_1_72_0_b1_rc1.tar.gz e3199f3f5046541570fffacd804d736e1999cfac05df6cc054ec97c8098d000d boost_1_72_0_b1_rc1.zip Please download the beta release candidate, give it a try, and report any problems you encounter. Thanks, -- The Boost Release Team

4 8

回复：Re: [release] Boost 1.72.0 Beta 1 Release Candidate 1
by ckgppl_yan＠sina.cn 18 Nov '19

18 Nov '19

I can compile this release in my macOS catalina, 10.15.1. I don't have lama installed in my OS, so I didn't have the issue below.only some warnings out. Thanks Liang----- 原始邮件 ----- 发件人：Marshall Clow via Boost <boost(a)lists.boost.org> 收件人：turkanis(a)coderage.com, Michael Caisse <mcaisse-lists(a)ciere.com> 抄送人：Marshall Clow <mclow.lists(a)gmail.com>, "boost(a)lists.boost.org List" <boost(a)lists.boost.org> 主题：Re: [boost] [release] Boost 1.72.0 Beta 1 Release Candidate 1 日期：2019年11月19日 04点38分 This appears to be https://github.com/boostorg/iostreams/issues/102, and https://github.com/boostorg/iostreams/pull/103 is a suggested fix. -- Marshall On Mon, Nov 18, 2019 at 11:56 AM Marshall Clow <mclow.lists(a)gmail.com> wrote: > On my Mac, I the version of LZMA that I have installed (via homebrew) does > not have the multi-tasking calls (_lzma_cputhreads and > _lzma_stream_encoder_mt). > It identifies itself: > > $ cat junk.cpp > #include <iostream> > #include "lzma.h" > > int main() { > std::cout << LZMA_VERSION << std::endl; > } > > $ clang++ junk.cpp && ./a.out > 50020042 > $ > > Changing libs/iostreams/src/lzma.cpp thus solves enables things to build: > > #ifndef BOOST_IOSTREAMS_LZMA_NO_MULTITHREADED > - #if LZMA_VERSION < 50020002 > + #if LZMA_VERSION <= 50020042 > #define BOOST_IOSTREAMS_LZMA_NO_MULTITHREADED > #endif > #endif > > -- Marshall > _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

Required C++ version in meta/libraries.json
by Mateusz Loskot 18 Nov '19

18 Nov '19

Hi, How can I specify required version of the standard in the library meta info? Where is documentation of libraries.json schema? I've learned that "std":"C++17", for example, in Boost.Any states which standard adopted the library. That is not what I'm after. -- Mateusz Loskot, mateusz(a)loskot.net (Sent from mobile, may suffer from top-posting)

1 1

Jason is getting MARRIED!
by Vinnie Falco 18 Nov '19

18 Nov '19

My JSON library is going to propose to Boost soon, is there anyone who might be willing and able to function in the role of review manager? Thanks!

3 4

pulling the plug on Boost Library Incubator
by Robert Ramey 17 Nov '19

17 Nov '19

I've been maintaining the Boost Library Incubator (www.blincubator.com) for some years now. Maintaining is sort of mis-nomer since it not required any change for years now. I never, ever touch it. I was painful to get to that point though. My motivation is the continuing evolution of github which I believe has come to embody almost of the goals I've had for the inclubator. I would like a couple of tweaks to git hub - or maybe just some changes in our usage of it. For example I'd like to see us proliferate the tags #Boost and #ProposedForBoost to help us search stuff but basically I believe that it has made boost library incubator obsolete. So I'm inclined to terminate it when the domain comes up for renewal the next time. Currently it has about 200 page views / day. I don't really know how much of that a bots/rss feeds and the like. I do you a service which detects and filters out almost all the obvious bogus hits, but still one never knows. BTW - the tipping point for me is the addition of "sponsership" to github. This looks to be the realization of an idea which I've promoted for many years in one for or another. I would like to successful open source project developers and maintainers get rewarded financially rewarded for their efforts and I see that git hub promoters seem to share this view - and they're in a position to move it toward reality. When I can't sleep at night, I imagine that microsoft looked at the incubator and copied features from it into the git hub. Feels like I'm dreaming so I don't feel like I'm awake anymore. Robert Ramey

1 0

Re: [boost] Jason is getting MARRIED!
by Peter Dimov 17 Nov '19

17 Nov '19

> or even `{ "size": 3, "data": [ 1, 2 ] }`. Er, "size": 2 obviously. :-)

1 0

Fwd: Markdown to Quickbook
by Mateusz Loskot 15 Nov '19

15 Nov '19

As boost-docs may not be as popular among subscribers as the development list, I'm bumping my chances for solution... ---------- Forwarded message --------- From: Mateusz Loskot <mateusz(a)loskot.net> Date: Mon, 11 Nov 2019 at 21:25 Subject: Markdown to Quickbook To: <boost-docs(a)lists.boost.org> Hi, Is there an established known method for converting a Markdown document to Quickbook dokument? Best regards, Mateusz Loskot, mateusz(a)loskot.net (Sent from mobile, may suffer from top-posting) -- Mateusz Loskot, http://mateusz.loskot.net

3 3

Removing old branches
by Edward Diener 15 Nov '19

15 Nov '19

I received an issue about Boost PP having lots of old branches which the issuer would like removed. I notice most other Boost libraries also have lots of old branches. Is there any policy about removing these old branches from a Boost library repository ? Many of these old branches are svn-branches, but most of them do not have any value any more and, of course, do not affect the current 'develop' or 'master' branch.

5 7

[preprocessor] Testing C++ standard macro examples
by Edward Diener 14 Nov '19

14 Nov '19

I have added to the 'develop' branch of Boost PP an 'explicit' test with the alias of 'test_iso' in the 'test' subdirectory. This test, depending on the compiler toolset and C++ standard setting used, will test a compiler's ability to expand correctly the macros listed in a C++ standard document's "Macro Replacement" section for C++ standards 2003, 2001, 2014, 2017, and 2020 ( N4835 ). The test uses the __cplusplus setting and the Boost PP BOOST_PP_VARIADICS setting to determine which C++ standard's set of macros to test. This is because the __cplusplus setting alone is misleading for a number of compilers, most notably vc++ and compilers who mimic vc++, who do not set the correct __cplusplus setting for the C++ standard level being used. There are really only three sets of macros from the C++ standard documents which can potentially be tested, despite five different standards being considered. This is because the set of macros to be tested for C++11, C++14, and C++17 are exactly the same. Some compilers do allow C++20 support but do not implement the full __VA_OPT__ support yet, so these compilers will fail the C++20 macro tests with compiler errors. Among these are gcc and vc++, who both document that they do not yet support the stringizing operator with the __VA_OPT__ parameter. Clang also supports C++20 and will run the test and succeed in that mode. You can of course test any compiler at any C++ level and view the results. These tests, unlike Boost PP, do not have any workarounds for any compilers. So the tests form a really good basis for reporting macro expansion preprocessor bugs to various compiler implementations. In the 'test' subdirectory of Boost PP you should be able to run: b2 toolset=atoolset cxxstd=astandard( optional ) test_iso to get the results for any compiler. Any failed results will show the test output, where the original expression, the expanded expression, and for individual failed tests the expected expanded expression will be shown. The actual macros being used are in the appropriate C++ Standard documents or can be seen in the test program which is called cpp_standard.cpp in the same 'test' subdirectory. After the upcoming release I will push this to the 'master' branch. Please note that the test is an 'explicit' test so it is not normally run when you just run the tests for Boost PP.

1 0

fixed_string: Request for review
by Krystian Stasiowski 13 Nov '19

13 Nov '19

Hi all, My name Is Krystian Stasiowski. I'm currently attending college as a Computer Science major, am active on the C++ Language Slack, and starting to contribute to ISO C++. Vinnie offered for me to take the lead on submitting Boost.FixedString for a formal review, so here I am! Applicable links: Github: https://github.com/18 Repo: https://github.com/18/fixed_string Docs: https://18.github.io/doc/fixed_string

2 1

Late fix for Boost PP
by Edward Diener 12 Nov '19

12 Nov '19

I had added support in the Boost PP library in C20 mode ( __cplusplus > 201703L ) for the __VA_OPT__ construct and enhanced an internal function used fairly extensively in the library to use this functionality in c20 mode when __VA_OPT__ was supported. I had tested this against the compilers which I knew could operate in c20 mode, gcc and clang, and all was well. I just discovered that the vc++ compiler can also work in c20 mode in Boost PP as defined above if you pass the '/std:c++latest' and the '/Zc:__cplusplus' command line switches and that vc++, in its usual non-standard way, blows up badly when doing so using the preprocessor library because it can not handle the rather simple code that checks for __VA_OPT__ support in c20 mode. I have a simple fix for this which is to turn off the __VA_OPT__ support and __VA_OPT__ support checking in c20 mode specifically for vc++ and removes which I have pushed to 'develop'. Can I push this fix to the 'master' branch now ? The fix needs to get in the coming release or else vc++ programmers specifying both the '/std:c++latest' and the '/Zc:__cplusplus' command line switched will not be able to use Boost PP and the many libraries which use Boost PP in the upcoming release. I apologize for the seeming aggressiveness of this change, which incorporated the c20 __VA_OPT__ support internally in some much-used Boost PP functionality when c20 mode is being used, but I did not anticipate that it would blow up on me, although maybe I should have. I can also remove that internal dependency with a very simple one-line change. I realize that Boost PP stability has to be maintained, even in c20 mode for the few compilers which support that mode and apologize again that I have endangered it there.

1 1

Re: [boost] [Boost][Proposal] library for enhanced switch syntax.
by рустам абдумаликов 12 Nov '19

12 Nov '19

Phil Endecott wrote: > Specifically thinking about strings, there are numerous ways > that it could be done. Starting with > (1): the obvious sequence of if-else-if: > ... > (2): binary search using nested switches: > ... > (3) character-by-character comparison using nested switches: > ... > (4) converting to a 64-bit integer, for strings of up to 8 characters: > ... Firstly my implementation was never particularly about string in "switch" it is just one of the applications. Secondly, example 3-4 assume additional implementation( can take quite a time to do it right ), it isn't like you have it out of the box, this is exactly what my statement was about( example 1-2 don't count, they are non-scalable ). Lets rather consider something that is more complex: -- Example_1 "Parse file by extension": switch( hash_it( get_file_extention( file_name ) ) ) { case "cpp"HASH: case "cc"HASH: case "c++"HASH: case "cxx"HASH: case "C"HASH: { ... } break; case "hpp"HASH: case "hh"HASH: case "h++"HASH: case "hxx"HASH: case "H"HASH: { ... } break; } // OR // I think this way it is much readable eswitch( get_file_extention( file_name ) ) >> case_( any_from( "cpp", "cc", "c++", "cxx", "C" ) ) >> [&]{...} >> case_( any_from( "h", "hpp", "hh", "h++", "hxx", "H" ) ) >> [&]{...}; // OR // even this could be possible( but not yet implemented ) eswitch( get_file_extention( file_name ) ) >> case_( "cpp", "cc", "c++", "cxx", "C" ) >> [&]{...} >> case_( "h", "hpp", "hh", "h++", "hxx", "H" ) >> [&]{...}; -- Example_2 "Parse HTTP header with Regex": // O_o too much boilerplate if( std::regex_match( line, "^.+ 200 .+$"_r ) ){...} else if( std::regex_match( line, "^.+ 404 .+$"_r ) ){...} else if( std::regex_match( line, "^.+: .+$"_r ) ){...} else { terminate(); } // OR // I think this way your intention is clearer eswitch( line ) >> case_( "^.+ 200 .+$"_r ) >> []{...} // match for "HTTP/1.1 200 OK" case_( "^.+ 404 .+$"_r ) >> []{...} // match for "HTTP/1.1 404 Not Found" case_( "^.+: .+$"_r ) >> [&]{...} >> // match for "key: value" default_ >> []{ terminate(); }; -- Example_2 "match in range of values": // Error prone approach if( value >= 1 && value <= 10 ){ Print("Value in a range[1,10]"); } if( value >= 11 && value <= 20 ){ Print("Value in a range[11,20]"); } else { Print('?'); }; /// OR eswitch( value ) >> case_( _1.in( 1, 10 ) ) >> []{ Print("Value in a range[1,10]"); } >> case_( _1.in( 11, 20 ) ) >> []{ Print("Value in a range[11,20]"); } >> default_ >> []{ Print('?'); }; // _1 it is lazy index mapping for the params in eswitch I my opinion "eswitch" looks more readable, more intuitive, less error prone and furthermore it is extensible. P.S. Here https://github.com/rabdumalikov/proposals/blob/master/eswitch_boost_proposa… I had described why I think it is important( just in case you've missed it ).

3 4

[release] 1.72.0 closed for Beta
by Michael Caisse 11 Nov '19

11 Nov '19

The master branch is now closed for all changes except by permission for the Beta release. Also, remember to add your libraries' changes to the release notes at: <https://github.com/boostorg/website/blob/master/feed/history/boost_1_72_1.q…> Thanks, -- The Boost Release Team

4 4

[Boost][Proposal] library for enhanced switch syntax. Request for Comments
by рустам абдумаликов 11 Nov '19

11 Nov '19

Hi All, I wrote a library *eswitch* which provides enhanced functionality for* C++ switch*. Please take a look and leave your comments. *=====================* *Motivation:* *=====================* To overcome "*native switch*" limitations: - one parameter per "*native switch*" - the parameter restricted to only *integral *types( int, char, enum ... ). "*eswitch*" supports any number of parameters and almost without restriction on their *type*, as long as the *type *is comparable( i.e. has* operator==* ). *=====================Why it is important?=====================* Here is the most viewed questions on the *stackoverflow*: FEATURE VIEWS Multiple conditions in switch case <https://stackoverflow.com/questions/68578/multiple-cases-in-switch-statement> 850k Switch for string <https://stackoverflow.com/questions/650162/why-the-switch-statement-cannot-…> 693k Case match in range <https://stackoverflow.com/questions/9432226/how-do-i-select-a-range-of-valu…> 133k Over a million views indicate how many people out there are disappointed with limited functionality of "*native switch*". Building parallels with such operators as "*if*"/"*while*"... it is expected by default that "*native switch*" should have the same possibilities: - be able to work with *non-integral* types as well - be able to compose complex conditions like we do in other operators " *if*"/"*while*"... Unfortunately it is not the case up till now. There was a proposal in 2013 *Relax switch statement <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3627.html>*, and committee agreed about importance of this topic. There also was *StringSwitch <http://llvm.org/doxygen/classllvm_1_1StringSwitch.html>* implementation by *LLVM *and *Case ranges <https://gcc.gnu.org/onlinedocs/gcc/Case-Ranges.html>* non-standard extension which is supported by *gcc*, *intel C/C++* and *clang*. Nevertheless, we still don't have common and universal solution. People want to overcome current "*native switch*" limitation either by implementing their own solution, non-standard extension or even trying to standardize it. Making proposed *eswitch <https://github.com/rabdumalikov/eswitch_v4>* functionality part of the *Boost-Library *will provide millions of developers useful, universal and agile functionality in order to finally fulfill their needs. *=====================repository:=====================* https://github.com/rabdumalikov/eswitch_v4 *=====================References:=====================/// "switch for non-integral" on stackoverflow* 1. https://stackoverflow.com/questions/650162/why-the-switch-statement-cannot-… 2. https://stackoverflow.com/questions/16388510/evaluate-a-string-with-a-switc… 3. https://stackoverflow.com/questions/5452188/switch-case-statement-in-c-with… 4. https://stackoverflow.com/questions/19273092/character-in-switch-statement-c 5. https://stackoverflow.com/questions/4165131/c-c-switch-for-non-integers 6. https://stackoverflow.com/questions/27536575/switch-case-on-char */// "Multiple conditions" on stackoverflow* 7. https://stackoverflow.com/questions/8644096/multiple-conditions-in-switch-c… 8. https://stackoverflow.com/questions/68578/multiple-cases-in-switch-statement */// "Ranges in case" on stackoverflow* 9. https://stackoverflow.com/questions/9432226/how-do-i-select-a-range-of-valu… */// "Case ranges" - non-standard extension* 10. https://gcc.gnu.org/onlinedocs/gcc/Case-Ranges.html */// LLVM "StringSwitch"* 11. http://llvm.org/doxygen/classllvm_1_1StringSwitch.html */// "Relax switch statement" proposal* 12. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3627.html */// "N3627 Relaxed switch statement" c++ committee status* 13. https://cplusplus.github.io/EWG/ewg-active.html *Best Regards.*

7 7

[Boost][Proposal] library for enhanced switch syntax. Request for Comments #2
by рустам абдумаликов 09 Nov '19

09 Nov '19

Hi All, First attempt kind of failed due to alignment:( So this is another one) So I wrote a library eswitch which provides enhanced functionality for C++ switch. Please take a look and leave your comments. Motivation: To overcome native switch limitations: 1) one parameter per switch 2) the parameter restricted to only integral types( int, char, enum ... ) Whereas "eswitch" supports any number of parameters and almost without restriction on their type, as long as the type is comparable( i.e. has operator== ). Why it is important? Because people want to overcome current switch limitation either by implementing their own solution, non-standard extension or even trying to standardize it. Making proposed eswitch functionality part of the Boost-Library will provide millions of developers useful, universal and agile functionality in order to finally fulfill their needs. Full proposal here: https://github.com/rabdumalikov/proposals/blob/master/eswitch_boost_proposa… Repository: https://github.com/rabdumalikov/eswitch_v4 Best Regards Rustam Abdumalikov

2 1

Re: [boost] fixed_string: Request for review
by Ggh 09 Nov '19

09 Nov '19

First: 1)wonderful documentation! 2) A few ideas => 2.1)find_count_of =>find number of occurences of 'argument' 2.2)get_sequence_of =>return sequence of 'begin'=>'end' 2.3)set_sequence_of => set sequence of 'begin'=>'end' with 'arg' 2.4)set_slice_of => ~= 2.3) 2.5)get_slice_of => ~= 2.2) 6)char_traits<T> here but =>> also for any type/class? Quoting Krystian Stasiowski via Boost <boost(a)lists.boost.org>: Good work! Please regard this as constructive critism, Ty G > Hi a > ,y > My name Is Krystian Stasiowski. I'm currently attending college as a > Computer Science major, am active on the C++ Language Slack, and starting > to contribute to ISO C++. Vinnie offered for me to take the lead on > submitting Boost.FixedString for a formal review, so here I am! > > Applicable links: > Github: https://github.com/18 > Repo: https://github.com/18/fixed_string > Docs: https://18.github.io/doc/fixed_string > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost Tell me, and I forget. Ask me, and I discover...

1 0

[container] static_string ?
by Vinnie Falco 09 Nov '19

09 Nov '19

Beast has static_string which someone has asked to be move, is there any interest in moving this to Boost.Container? See: <https://github.com/boostorg/beast/issues/1691> <https://github.com/boostorg/beast/blob/b7230f12f16fe7a9f7a1ece5be1f607c8552…> -- Regards, Vinnie Follow me on GitHub: https://github.com/vinniefalco

19 50

[Metrics] - library idea reviews
by cpijcke.wall＠laposte.net 08 Nov '19

08 Nov '19

Hi, Two years ago, I have created a library who handle metrics type (distance, speed, flow rate, ...). I have simply applied the principle of chrono library (std:: one from clang in my case) and have applied it to other types. I have decided some weeks ago to make it public on github. This project also manage inter-type conversion(speed to distance, or volume to flow rate for example). Before going much further in this project, I would like to get your though about it. Maybe some of you already have had a similar idea, maybe even in a more advanced state, or with another principle of conversion between types? Here is the project link: https://github.com/xtofpic/metrics if you are interested. In this case, don't blame me for the state of the code actually, I know it still need a huge works to do on testing and code reducing by better c++ templates. But if you can just let me know what you think of the idea? And if there is an opportunity to eventually integrate this project into boost afterwards? Best regards, Christophe Pijcke.

2 2

How to make boost write_xml not escape angle brackets?
by Ananya Maiti 07 Nov '19

07 Nov '19

Hi all, I am trying to write some data in a xml file using boost write_xml() function. My data has some angle brackets in it e.g. <![CDATA[name]]> . But when I use boost::property_tree::write_xml() to write the data node to xml file it escapes the angle brackets to < and > tags. I even tried using unicode \x3C , \x3E but still it escapes them. Is there any way to tell boost to not escape the characters in a non html safe way ? Regards, Ananyo Maiti

1 0

[1.72][Test][Math][Fiber] Recent breaking change in Boost.Test breaks fiber/math tests
by John Maddock 07 Nov '19

07 Nov '19

This change: https://github.com/boostorg/test/commit/1c4533f7654d4c049cc6a34a43a5c10cde5… To Boost test (which I'm sure has been long signaled, I just wasn't aware of it), breaks one Math lib test (develop and master), and quite a number of Fibre tests (also develop and master), the Math failure should be fixed in develop (https://github.com/boostorg/math/commit/1d04bf714e809d386088ce135e3f9ea04ca…) and will get merged to master once CI is green. Not sure if anything is in the works for Fiber. Just a wee heads-up. Best, John. -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

4 8

Best Boost to use for boost::python with Python 3.7/3.8?
by Kacvinsky, Tom 06 Nov '19

06 Nov '19

Subject is the question. Any recommendations? Looking at the boost documentation for boost::python, it doesn't look like the copyright has changed since 2015, but compiling boost 1.6.9.0, for instance, points out there have been code changes.

1 0

[Test] log_level (was RE: [1.72][Test][Math][Fiber] Recent breaking change in Boost.Test breaks fiber/math tests)
by Peter Bartlett 05 Nov '19

05 Nov '19

>I think it is very counter-intuitive that messages only emerge to the normal output if there is an error or --log_level="message" > >And that > > #define BOOST_TEST_LOG_LEVEL "message" > >does not appear to have the same effect as --log_level="message" > >which is also surprising, and in my book a buglet? > >I suggest that this behaviour should be changed so that BOOST_TEST_MESSAGE >*always* produces output. > >BOOST_AUTO_TEST_CASE(test_message) >{ > BOOST_TEST_MESSAGE("\nTest BOOST_TEST_MESSAGE.\n"); } // BOOST_AUTO_TEST_CASE(test_message) > >Otherwise I am sure I will not be the only person confused. > >At the very least the documentation should highlight that ones expectation may not match what actually happens. Hi, I think it would be a bad idea to change the default value of --log_level (in your suggestion, from "error" to "message"). The default has been "error" for a long time (I don't like to count how long, because it makes me feel old!). And I'm sure that a lot of parsing tools have been built around the world assuming Boost.Test output is of a certain form. I know I've had to 'teach' various CI systems Boost.Test-speak over the years. > #define BOOST_TEST_LOG_LEVEL "message" BOOST_TEST_LOG_LEVEL is supported as an environment variable, not as a macro. Supporting it as a macro would be a bad idea for similar reasons as above - the layout and volume of the output should be for the *user* to control not the author of the tests, or otherwise the user can't rely on what the test output is going to look like from one library to the next. If you, personally, always want the log_level to be 'message', then you should set the environment variable BOOST_TEST_LOG_LEVEL permanently on your system. Hope that helps, Pete

1 0

[histogram] [1.72] merge usability patch?
by Hans Dembinski 05 Nov '19

05 Nov '19

Dear release managers, I have a patch in my develop branch for Boost.Histogram which would like to merge to the master for the 1.72 release. https://github.com/boostorg/histogram/commit/d658aff0b09f73d4f0d3b729b13518… It is a rather intrusive patch, hence my question whether I am allowed to merge this. There is no change to the public interface. The patch provides nice compile-time error messages when users make mistakes in using the histogram instead of spilling out internals details as it does now, that's why I think it would be good to have this already in the upcoming release instead of the next after. The patch passes all the tests in the CI (and new tests developed for this feature). Line coverage remains at 100 % for Boost.Histogram, therefore I am confident that applying the patch is safe. Best regards, Hans

1 0

Re: [boost] [Boost-users] Interest in a Unicode library for Boost?
by Zach Laine 02 Nov '19

02 Nov '19

On Fri, Nov 1, 2019 at 3:41 PM Mathias Gaunard <mathias.gaunard(a)ens-lyon.org> wrote: > This email appears to only be addressed to me and not the list, is > that intentional? > I typed this on my phone so maybe things didn't work exactly as I intended. > It was not intentional. > On Fri, 1 Nov 2019 at 16:09, Zach Laine <whatwasthataddress(a)gmail.com> > wrote: > > > Right. Unicode encodes all natural languages that anyone has taken the > time to put into Unicode. I stand by the implication that natural > languages are crazy. > > Natural languages -- and their transliteration to bytes -- are > arbitrary conventions yes, but they're sufficiently consistent to be > used by millions of people in their personal and professional life > everyday. > There are rules, and however alien they might look to someone who only > needs the fairly straightforward ASCII system, they are not crazy, and > have their own reasons. > > > > So then maybe don't use those parts? They're independent; you don't > have to use them to use the Unicode algorithms. > > Separation of concerns, they do appear coupled in the documentation. > That could just be due to the way the documentation is written. > Could be ... could you point to something in the docs that left you with that impression? I explicitly divided up the documentation along the lines of the separation of concerns found in the code -- the string layer, the Unicode layer, and the text layer. I also tried to be explicit that the first is without dependencies, the second does not depend on the first or the third, and that the third depends on the second. > > Clearly you are more capable than I am. It took me a lot longer to do > than 2 months. Why did you never submit this for a Boost review? You were > thinking about it, ~10 years ago, but you never did.... > > The use case for Unicode is quite niche, and I wasn't particularly > interested in working in that niche further. > Any serious natural language processing engine would probably bypass > Unicode and come up with its own heuristics to parse text, and > applications like GUI toolkits or text editors are specialized enough > that they'd probably never use a library which wasn't specifically > designed for their use case in mind. > That leaves everyday programming, which very rarely needs to do > anything with text beyond treating it as a byte stream, and I believe > wanting to impose the heavyweight Unicode machinery systematically > everywhere is a mistake. > > Anyway, I was just mentioning this because there is prior work > (Boost.Unicode) that you apparently never looked at. > Of course being developed for only a short period of time it doesn't > have the same level of polish as your library. > Ok. FWIW, I did know about your library -- I was there for the BoostCon presentation -- and I was looking forward to using it. Ten years later, I did not look at it again, simply because it had been ten years. > >> and that the database itself is not even accessible, > > > > > > That's also intentional. Another goal of the library is to make Unicode > as simple as possible for naive users who just want to do the basics. If I > find requests for any new feature that has a compelling use case, I'll add > that. > > Being able to replace things like std::isalpha etc. is pretty basic I'd > say. > Having an API that tells you a number of properties about a code point > is one of the most useful parts of Unicode. > I agree I the abstract, but I think that there is a real problem that the properties for a given code point are not necessarily consistent across the various Unicode algorithms. For example, there are multiple notions of "number" that are treated differently in the bidirectional algorithm. Moreover, I don't know of a great use case for a boost::text::is_alpha(). Specifically, it seams that if you are looking for alphabetical characters, you are usually doing something like word-breaking, for which there is already an algorithm, doing a regex match, for which is_alpha() is insufficient, etc. I'm open to hearing about such use cases, of course. > > I don't consider 1.5MB for a database containing all human languages in > widespread use on computers to be a ridiculous size, but YMMV. > > I suppose that's reasonable. > I think the Boost.Unicode one was only 500k but that's an old Unicode > version, and I'm not sure it ever had full collation support. > > > > >> > >> It also doesn't provide the ability to do fast substring search, which > >> you'd typically do by searching for a substring at the character > >> encoding level and then eliminating matches that do not fall on a > >> satisfying boundary, instead suggesting to do the search at the > >> grapheme level which is much slower, and the facility to test for > >> boundary isn't provided anyway. > > > > > > I honestly don't know what you mean here. > > I'm not sure how to clarify this better, but I'll try. > > To search for the utf-8 substring "foo" in the utf-8 string "I really > like foo dogs", there is no need to iterate the string per code point > or per grapheme as you do in your examples. You can just perform the > search at the code unit level, then check that the position before and > after the match does not lie inside a grapheme cluster, i.e. they are > on a valid boundary. > What you need to be able to do that is a function that tells you > whether an arbitrary position in your sequence of utf-8 code units > lies at a grapheme cluster boundary or not (which would probably be a > composition of two separate functions, one that test whether the code > unit is on a code point boundary, and one that tests whether the code > point is on a grapheme cluster boundary). This functionality is not > provided. > > This sort of thing is briefly touched upon in Unicode TR#29 6.4. > I see. This seems like it might be really useful to add. I'll open a ticket for it on Github. Zach

1 1

Interest in a Unicode library for Boost?
by Zach Laine 02 Nov '19

02 Nov '19

About 14 months ago I posted the same thing. There was significant work that needed to be done to Boost.Text (the proposed library), and I was a bit burned out. Now I've managed to make the necessary changes, and I feel the library is ready for review, if there is interest. This library, in part, is something I want to standardize. It started as a better string library for namespace "std2", with minimal Unicode support. Though "std2" will almost certainly never happen now, those string types are still in there, and the library has grown to also include all the Unicode features most users will ever need. Github: https://github.com/tzlaine/text Online docs: https://tzlaine.github.io/text If you care about portable Unicode support, or even addressing the embarrassment of being the only major production language with next to no Unicode support, please have a look and provide feedback. I gave a talk about this at C++Now in May 2018, and now it's a bit out of date, as the library was not then finished. It's three hours, so, y'know, maybe skip it. For completeness' sake: https://www.youtube.com/watch?v=944GjKxwMBo&index=7&list=PL_AKIMJc4roVSbTTf… https://www.youtube.com/watch?v=GJ2xMAqCZL8&list=PL_AKIMJc4roVSbTTfHReQTl1d… Zach

8 10

[filesystem] Management of junction on Windows is broken
by Vincent R. 02 Nov '19

02 Nov '19

Hello, I am bit disappointed to see that symlink and junctions are still not really properly handled on Windows with boost (and even with standard MS libs but that's another story.) First my environment: Windows 10, VS2019 16.3.7, boost 1.71 (static, x64). I would like to write a small c++ utility that does not use os dependent code to handle files so filesystem seems a good candidate. Here is what I am doing on Windows: cd "C:\Users\Vincent\AppData\Roaming\Apple Computer\MobileSync" mklink /j Backup E:\Backup So basically I am creating inside C:\..\MobileSync a junction folder that points to my second harddisk E:\Backup Then I am checking that Windows recognize it by entering dir command: 01/11/2019 23:48 <DIR> . 01/11/2019 23:48 <DIR> .. 01/11/2019 23:29 <JUNCTION> Backup [E:\Backup] 0 fichier(s) 0 octets 3 Rép(s) 59 393 630 208 octets libres As you can see I have a junction targeting E:\Backup, so now let's see what happens with boost: fs::path p(_T("C:\\Users\\Vincent\\AppData\\Roaming\\Apple Computer\\MobileSync\\Backup")); sys::error_code ec; if (fs::is_symlink(p)) { fs::path pathTarget = fs::read_symlink(p, ec); } When I display the content of pathTarget I have: L"\\Backup" ie Backup if I decode it into human string I might not understand anything about junction but is it not supposed to return E:\Backup ?? When I look at source code I can see the following lines: /********************** boost_1_71_0\libs\filesystem\src\operations.cpp **************************************/ symlink_path.assign( static_cast<wchar_t*>(info.rdb.SymbolicLinkReparseBuffer.PathBuffer) + info.rdb.SymbolicLinkReparseBuffer.PrintNameOffset/sizeof(wchar_t), static_cast<wchar_t*>(info.rdb.SymbolicLinkReparseBuffer.PathBuffer) + info.rdb.SymbolicLinkReparseBuffer.PrintNameOffset/sizeof(wchar_t) + info.rdb.SymbolicLinkReparseBuffer.PrintNameLength/sizeof(wchar_t)); This is wrong since we need to distinguish between a symlink and a junction folder so here is my contribution : --- a/src/operations.cpp +++ b/src/operations.cpp @@ -201,6 +201,12 @@ typedef struct _REPARSE_DATA_BUFFER { # ifndef IO_REPARSE_TAG_SYMLINK # define IO_REPARSE_TAG_SYMLINK (0xA000000CL) # endif +# ifndef IO_REPARSE_TAG_MOUNT_POINT +# define IO_REPARSE_TAG_MOUNT_POINT (0xA0000003L) +# endif +# ifndef IO_REPARSE_TAG_DEDUP +# define IO_REPARSE_TAG_DEDUP (0x80000013L) +# endif inline std::wstring wgetenv(const wchar_t* name) { @@ -1661,12 +1667,24 @@ namespace detail if (!error(::DeviceIoControl(h.handle, FSCTL_GET_REPARSE_POINT, 0, 0, info.buf, sizeof(info), &sz, 0) == 0 ? BOOST_ERRNO : 0, p, ec, "boost::filesystem::read_symlink" )) + if (info.rdb.ReparseTag == IO_REPARSE_TAG_SYMLINK) + { symlink_path.assign( static_cast<wchar_t*>(info.rdb.SymbolicLinkReparseBuffer.PathBuffer) + info.rdb.SymbolicLinkReparseBuffer.PrintNameOffset/sizeof(wchar_t), static_cast<wchar_t*>(info.rdb.SymbolicLinkReparseBuffer.PathBuffer) + info.rdb.SymbolicLinkReparseBuffer.PrintNameOffset/sizeof(wchar_t) + info.rdb.SymbolicLinkReparseBuffer.PrintNameLength/sizeof(wchar_t)); + } + else if (info.rdb.ReparseTag == IO_REPARSE_TAG_MOUNT_POINT) + { + symlink_path.assign( + static_cast<wchar_t*>(info.rdb.MountPointReparseBuffer.PathBuffer) + + info.rdb.MountPointReparseBuffer.PrintNameOffset / sizeof(wchar_t), + static_cast<wchar_t*>(info.rdb.MountPointReparseBuffer.PathBuffer) + + info.rdb.MountPointReparseBuffer.PrintNameOffset / sizeof(wchar_t) + + info.rdb.MountPointReparseBuffer.PrintNameLength / sizeof(wchar_t)); + } # endif return symlink_path; } I will add more suggestions in a next message because there is no consistency between boost and MSVC approach. I don't know the last c++ specifications but it shouldn't be difficult to have a simple approach;

1 0

Re: [boost] [Boost-users] Interest in a Unicode library for Boost?
by Zach Laine 01 Nov '19

01 Nov '19

Mathias pointed out that I sent this just to him. So I'm replying again to get this onto the list. Sorry for the noise. On Fri, Nov 1, 2019 at 11:09 AM Zach Laine <whatwasthataddress(a)gmail.com> wrote: > On Fri, Nov 1, 2019 at 6:35 AM Mathias Gaunard < > mathias.gaunard(a)ens-lyon.org> wrote: > >> On Sat, 26 Oct 2019 at 02:11, Zach Laine via Boost-users >> <boost-users(a)lists.boost.org> wrote: >> > >> > About 14 months ago I posted the same thing. There was significant >> work that needed to be done to Boost.Text (the proposed library), and I was >> a bit burned out. >> > >> > Now I've managed to make the necessary changes, and I feel the library >> is ready for review, if there is interest. >> > >> > This library, in part, is something I want to standardize. >> > >> > It started as a better string library for namespace "std2", with >> minimal Unicode support. Though "std2" will almost certainly never happen >> now, those string types are still in there, and the library has grown to >> also include all the Unicode features most users will ever need. >> > >> > Github: https://github.com/tzlaine/text >> > Online docs: https://tzlaine.github.io/text >> >> I would start by removing the superlative statements about Unicode >> being "hard" or "crazy". >> It's not that complicated compared to the actual hard problems that >> software engineers solve everyday. The only thing is that people >> misunderstand what the scope of Unicode is, it's not just an encoding, >> it's a a database and a set of algorithms (relying on said database) >> to facilitate natural text processing of arbitrary scripts, and does >> compromises to integrate with existing industry practices prior to all >> those scripts being brought together under the same umbrella. >> > > Right. Unicode encodes all natural languages that anyone has taken the > time to put into Unicode. I stand by the implication that natural > languages are crazy. > > >> Now the string/container/memory management, this is quite irrelevant. >> That sort of stuff has nothing to do with Unicode and I certainly do >> not want some Unicode library to mess with the way I am organizing how >> my data is stored in memory. >> Your rope etc. containers belong in a completely independent library. >> > > So then maybe don't use those parts? They're independent; you don't have > to use them to use the Unicode algorithms. > > >> What's important is providing an efficient Unicode character database, >> and implementing the algorithms in a way that is generic, working for >> arbitrary ranges and being able to be lazily evaluated (i.e. range >> adaptors). >> I already did all that work more than 10 years ago as a two-month GSoC >> project, though there are some limitations since at that time ranges >> and ranges adaptors were still fairly new ideas for C++. It does >> however provide a generic framework to define arbitrary algorithms >> that can be evaluated either lazily or eagerly. >> > > Clearly you are more capable than I am. It took me a lot longer to do > than 2 months. Why did you never submit this for a Boost review? You were > thinking about it, ~10 years ago, but you never did.... > > >> To be honest I can't say I find your library to be much of an >> improvement, at least in terms of usability, since the programming >> interface seems more constrained (why don't things work with arbitrary >> ranges rather than this "text" containers) > > > They do, of course. I'm not sure why it is you think otherwise. > > >> and verbose (just look at >> the code to do transcoding with iterators), > > > Are you referring to the verbosity of: > > char const * some_utf8 = /* ... */ ; > out = std::ranges::copy(boost::text::as_utf32(some_utf8), out); > > , or: > > out = boost::text::transcode_utf_8_to_32(utf8_first, utf8_last, out); > > , or something else? > > >> the set of features is >> quite small, > > > That is quite intentional. I want to standardize *basic* Unicode > support. I feel that what I have in Boost.Text is the basic set that users > will need, just to support languages or formatting conventions that are not > common in their favorite environment. For instance, today there is no > standard way of taking UTF-8 and turning it into UTF-16, or vice versa; > this library is intended to work at that level. That is, it is intended to > fill in needless gaps in Unicode support that exist in C++ -- gaps that no > other major language besides C has. It is specifically not intended to > replace all ICU functionality. Do you have specific things in mind that > you think ~90% of Unicode-aware C++ users will need? Note that I did not > say 100%. > > >> and that the database itself is not even accessible, > > > That's also intentional. Another goal of the library is to make Unicode > as simple as possible for naive users who just want to do the basics. If I > find requests for any new feature that has a compelling use case, I'll add > that. > > >> and >> last I remember your implementation was ridiculously bloated in size. >> > > I don't consider 1.5MB for a database containing all human languages in > widespread use on computers to be a ridiculous size, but YMMV. > > >> It also doesn't provide the ability to do fast substring search, which >> you'd typically do by searching for a substring at the character >> encoding level and then eliminating matches that do not fall on a >> satisfying boundary, instead suggesting to do the search at the >> grapheme level which is much slower, and the facility to test for >> boundary isn't provided anyway. >> > > I honestly don't know what you mean here. If you use the text::text or > text::string types, those are just contiguous sequences of bits, like a > std::vector or std::string. text::text exposes iterators to those bits > which can be used to get grapheme, code point, and/or UTF-8 byte views of > the underlying data. If you are using something else besides text::text or > text::string two types, you presumably have access to your own bits in your > own representation. What prevents you from doing whatever substring search > you like, via std::search(), std::ranges::includes(), or something else? > Boost.Text is not intended as a string algorithms library. > > I'm pretty sure I made similar comments in the past, but I don't feel >> like any of them has been addressed. >> > > I think you're referring to this email you sent in the Boost.Text > interest thread from 14 months ago: > > """ > The Unicode library I did as a SoC project in 2009 was significantly > smaller than that and if I recall correctly it has more data than the one > in your library. > Clearly some work can be done here to better optimize the database size. > """ > > I did make it a bit smaller. The other comments are new. > > Zach > >

1 0

Change TCP_USER_TIMEOUT
by JH 01 Nov '19

01 Nov '19

Hi, I am using boost asio TCP socket in my device application for network connection in Linux platform. I am troubled currently by long TCP tmeout issues in a device to switch application between WiFi and 4G LTE. If my application TCP was connected via 4G LTE initially, when WiFi is available, the network is switched to WiFi, but the application TCP connection would have 30 minutes timeout before it terminated the 4G LTE and reconnects to WiFi. That 30 minutes is too long. I checked TCP document for TCP_USER_TIMEOUT: TCP_USER_TIMEOUT Decreasing user timeouts allows applications to "fail fast", if so desired. Otherwise, failure may take up to 20 minutes with the current system defaults in a normal WAN environment. My question is, in boost asio socket, is there an API to change TCP_USER_TIMEOUT? Appreciate if showing an example or point me to a document how to do it. Thank you. Kind regards, - jh

2 3

Re: [boost] [Boost-users] Interest in a Unicode library for Boost?
by Zach Laine 30 Oct '19

30 Oct '19

On Wed, Oct 30, 2019 at 4:51 AM Leon Mlakar <leon(a)digiverse.si> wrote: > On 29.10.2019 17:11, Zach Laine wrote: > > > > >> - for the sake of completeness the normalization type used at the text >> level ought to be a policy parameter; although I do understand your >> arguments against it I think it should be there even at the cost of >> different text types being inoperable without conversions >> > > I disagree. Policy parameters are bad for reasoning. If I see a > text::text, as things currently stand, I know that it is stored as a > contiguous array of UTF-8, and that it is normalized FCC. If I add a > template parameter to control the normalization, I change the invariants of > the type. Types with different invariants should have different names. To > do otherwise is a violation of the single responsibility principle. > > Okay, the policy or not the policy was not my point ... it was to allow > for different underlying normalizations. Granted, it may only be important > to (a few) corner cases where input and/or output normalizations are given, > and your assessment that it may not be worth the effort is reasonable ... > unless you are aiming towards adding to the standard. Then the completeness > imho becomes more important. > > Frankly, I'm not proficient enough in the meta-programming to make a > strong case either for policy parameter or for explicit types/templates. I > just happen to prefer the policy based approach. > Understood. FWIW, the algorithms provided by Boost.Text make it possible to use any normalization representation, though at times conversions may be necessary. Some of those conversions are mandated by the Unicode standard itself -- you cannot feed NFC, NFKC, or NFKC to the collation algorithm, for instance (though implementations are possible for NFD and FCC). > > > - at the text level I'm not sure I'm willing to cope with different >> fundamental text types; I just want to use boost::text::text, pretty >> much the same as I use std::string as an alias to much more complex >> class template; heck, even at the string layer I'd probably prefer >> rope/contiguous concept to be a policy parameter to the same type >> template. >> > > That would be like adding a template parameter to std::vector that makes > it act like a std::deque for certain values of that parameter. Changing > the space and time complexity of a type by changing a template parameter is > the wrong answer. > > No, that is not making the std::vector to act as std::deque - the text > would still remain the text and act as a text, with the same interface. > It's more like FIFO implementation using either std::vector or std::dequeu > for its store - since in both cases the FIFO has the same interface and > functionally behaves the same, I really don't want two distinct types. The > type template with the parameter that makes the choice between the > underlying storage seems much more natural to me. > You example highlights my point. For N inputs to your FIFO queue, a deque underlying implementation is worst-case O(N). A vector implementation is worst-case O(N*N). The invariants of the type matter, and they matter a lot. Saying a foo may be like a bar or like a baz only work when bar and baz are so similar that you cannot observe a difference in the behavior of foo. Zach

1 0

[SPAM] istream_iterator_limited
by Frederick Gotham 28 Oct '19

28 Oct '19

- - - - WHY I NEEDED THIS: I wanted to open a file using "ifstream", and then I wanted to read 32 bytes from the file and feed them directly into boost::algorithm::hex. Unfortunately I couldn't do this because 'hex' takes two iterators [begin,end), and there's no alternative function "hex_n". So I had to read the file into a string first, and then pass the string to 'hex'. - - - - THE IDEA I CAME UP WITH: Open the file using "ifstream", and then use a special iterator that will stop reading from the file after 32 bytes, with syntax like this: ifstream logfile("log.txt"); hex( istream_iterator_limited<char>(logfile,32), istream_iterator_limited<char>(), g_some_global_container.begin() ); - - - - SAMPLE CODE: #include <cstddef> /* size_t */ #include <iterator> /* istream_iterator */ template <typename T> class istream_iterator_limited : public std::istream_iterator<T> { protected: std::size_t const m_limit; std::size_t m_current_count; public: /* Shorter names */ typedef std::istream_iterator<T> Base; typedef istream_iterator_limited<T> This; istream_iterator_limited(typename Base::istream_type &obj_stream, size_t const arg_limit) : Base(obj_stream), m_limit(arg_limit), m_current_count (1) { /* The initialiser list above does all the construction work */ } istream_iterator_limited(void) /* This gives the End-Of-Stream iterator */ : Base() , m_limit(0), m_current_count(1) { /* The initialiser list above does all the construction work */ } This &operator++(void) { if ( m_limit <= m_current_count ) { Base::operator=( Base() ); /* Becomes End-Of- Stream iterator */ } else { ++m_current_count; Base::operator++(); } return *this; } }; #include <algorithm> /* copy */ #include <string> /* string */ #include <sstream> /* istringstream */ #include <iostream> /* cout, endl */ #include <iterator> /* back_inserter */ auto main(void) -> int { std::istringstream iss("123456789"); std::string str; /* Let's use copy to read 5 char's into our string */ std::copy( istream_iterator_limited<char>(iss,5), istream_iterator_limited<char>(), std::back_inserter(str) ); std::cout << str << std::endl; str.clear(); /* Get another 3 */ std::copy( istream_iterator_limited<char>(iss,3), istream_iterator_limited<char>(), std::back_inserter(str) ); std::cout << str << std::endl; }

1 0

Re: [boost] disjoint_sets?
by Glen Fernandes 27 Oct '19

27 Oct '19

Peter wrote: > At some point we removed the disjoint_sets module from the develop branch, > but it's still on master. When are we going to remove it from master as > well? The relevant changes need to be merged from Graph develop to master, before we can retire the disjoint_sets repository entirely. John, any concerns about doing this now, before the 1.72 release progresses? Glen

1 0

disjoint_sets?
by Peter Dimov 25 Oct '19

25 Oct '19

At some point we removed the disjoint_sets module from the develop branch, but it's still on master. When are we going to remove it from master as well?

1 0

question re BOOST_NO_EXCEPTION
by Robert Ramey 25 Oct '19

25 Oct '19

I want to detect whether or not the -no_exception compile time flag has been used on gcc/clang. Will BOOST_NO_EXCEPTIONS do this? If not is there something I can use? Robert Ramey

5 10

Multi-Dimensional Dynamic Array Boost Library Proposal
by Richard Hogaboom 24 Oct '19

24 Oct '19

I've written a library at GitHub/rahogaboom/daa that does dynamic array allocation in ptr to ptr ... style that is very simple to use(only two routines), header file only, can allocate an unlimited number of dimensions with subscripts for each dimension starting at an arbitrary number e.g. 0, 1, -5 etc, can allocate anything you can take sizeof() and allocates all in one contiguous block(stack, heap) for easy freeing. I'm aware of the Boost.MultiArray library, however, I think daa has some advantages. Specifically, a. each dimension has it's own starting subscript b. it's relative simplicity(2 routines) c. it's longevity - 30 years and two articles d. also can be used in a C only environment. Following is the points noted in the GitHub README.md: |Library: daa.hpp Dynamic Array Allocator - C++ header file only library - ptr to ptr to ... style arbitrary N dimensional array allocator of anything you can take sizeof() - arbitrary starting subscript(0, 1, -10, ...) for each separate dimension - Note: for each array dimension the starting subscript and dimension size determine the valid subscripts for that dimension - any index outside that range is invalid and will give unpredictable results - allocates anything of any type(double, int, long, struct, ...) - one contiguous block allocation of memory for all ptr's and data(locality of reference and easy free()) - array or slices of array can be passed to subroutines to any depth, modified there, and be seen at all levels - simple library, two routines(das()(calculate space needed) and daa()(allocate ptr to ptr ... array)) - no library dependencies(except standard header files) - initialization pointer argument set to instance of initialized type or NULL for no initialization - implemented by a recursive routine(ptr_init()) which calls two other different recursive routines(off() and doff()) - see article in Embedded Systems Programming, Dec. 2000, "Flexible Dynamic Array Allocation"(included) - see article in The C Users Journal, Nov. 1990. "A Flexible Dynamic Array Allocator"(included) - 18 verification tests that show code usage examples, see daa_test.cpp - see cut/paste Examples section and API(das(), daa()) section below - a daa-compile.tar file is provided with a non-header compiled(clang, clang++, gcc, g++) version - for an excellent reference on this type of array(ptr to ptr to ...) access see Numerical Recipes in C, Press, Flannery, Teukolsky, and Vettering, Cambridge University Press, 1992, pg. 20-23. Ch. 1 Preliminaries -> 1.2 Some C Conventions for Scientific Computing -> Matrices and Two-Dimensional Arrays. From the above reference read: 'Here is our bottom line: We avoid the fixed-size two-dimensional arrays of C as being unsuitable data structures for representing matrices in scientific computing. We adopt instead the convention “pointer to array of pointers,” with the array elements pointing to the first element in the rows of each matrix.' - this file is the entire documentation needed to use the library - Author: Richard Hogaboom, richard.hogaboom(a)gmail.com| | Usage: - das() - find size necessary malloc()(or whatever memory allocation routine) - allocate memory daa() - populate allocated memory - allocate auto stack or static area storage e.g. unsigned char mem[SIZE] das() - determine if array will fit in mem[] daa() - populate allocated memory | |Example:| | int err_code = 0; int asize = 0; char *mem_ptr; unsigned int d[4] = {3, 5, 4, 2}; /* dimensions */ int st[4] = {-1, -5, 10, 0}; /* starting subscripts */ double ****array = NULL; /* array pointer */ asize = das(sizeof(double), 4, d, &err_code); mem_ptr = (char *)malloc(asize); array = (double ****) daa(sizeof(double), 4, d, st, &err_code, mem_ptr, NULL);| | double d = array[-1][-5][10][0];| -- Richard A Hogaboom 16 Alprilla Farm Road Hopkinton, MA 01748-1922 richard.hogaboom(a)gmail.com www.linkedin.com/in/richardhogaboom/ www.github.com/rahogaboom M508-330-3775

2 1

Boost logo font?
by Hans Dembinski 23 Oct '19

23 Oct '19

Dear all, does someone remember which font was used for the Boost logo on boost.org? Is it possible to get this font to make another logo? I want to make a logo for Boost.Histogram. Best regards, Hans

4 11

New JSON library from the maker of Beast!
by Vinnie Falco 23 Oct '19

23 Oct '19

I've been working on a massively-multiplayer online blackjack casino server, called Beast Lounge [1]. The server and client communicate using JSON-RPC over WebSocket. I have developed a brand-new JSON library for this project, in accordance with the following design goals: * Robust support for custom allocators throughout. * Array and object interfaces closely track their corresponding C++20 container equivalents. * Use `std::basic_string` for strings. * Minimize use of templates for reduced compilation times. * Parsers and serializers work incrementally (['online algorithms]). * Elements in objects may also be iterated in insertion order. You can see the JSON library in development here: https://github.com/vinniefalco/json Is there any interest in proposing this for Boost? I'm happy to hear feedback or answer questions about this library. Feel free to open an issue on the repository, or reply here. Thanks [1] <https://github.com/vinniefalco/BeastLounge>

21 68

[lockfree][Interprocess] - SPSC queue in shared memory cause SEG fault
by Saravanan A 23 Oct '19

23 Oct '19

Hi Team, We Currently trying to develop a prototype with boost libraries, where we are facing an issue in it with boost library. It would be great if someone help out here . we are having two process where one process create “*managed xsi shared memory”* and other get attached to it. Here we trying to have a spsc queue in a shared memory structure which will be accessed by both process . Where SPSC queue data is a user defined class object. when we have a integer in ” *Mydata”* (Class name) mentioned below and try to do a Push /pop operation in the spsc queue on respective process it was working fine without any issues. But the same framework when we have an array of greater size(more than 28 byte around. Example: a[7] ) .We are facing a crash in consumer side . (It seems spsc queue write somewhere in process heap memory after first pop leading to memory corrupt ) please let us know if there any open issue in this ? or if we have used boost library incorrectly ? Thanks for reading. I would be thankful for any information you may have to offer. *Backtrace:* /data/users/kapparao/example_boost/anony-SHM-managed> $./processB Consumer-TX - Read data from Q - [1,b] notify_one@93 - I am here! notify_one@159 - I am here! Segmentation fault (core dumped) /data/users/kapparao/example_boost/anony-SHM-managed> $gdb ./processB GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-115.el7 Copyright (C) 2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html > This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /data/users/kapparao/example_boost/anony-SHM-managed/processB...done. (gdb) r Starting program: /data/users/kapparao/example_boost/anony-SHM-managed/./processB [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Consumer-TX - Read data from Q - [1,b] Program received signal SIGSEGV, Segmentation fault. 0x00007ffff7bcb09b in pthread_cond_signal@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 Missing separate debuginfos, use: debuginfo-install glibc-2.17-292.0.1.el7.x86_64 libgcc-4.8.5-39.0.1.el7.x86_64 libstdc++-4.8.5-39.0.1.el7.x86_64 (gdb) bt #0 0x00007ffff7bcb09b in pthread_cond_signal@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x00000000004063de in boost::interprocess::ipcdetail::posix_condition::notify_one (this=0x28) at ../../boost/include/boost/interprocess/sync/posix/condition.hpp:160 #2 0x00000000004066e1 in boost::interprocess::interprocess_condition::notify_one (this=0x28) at ../../boost/include/boost/interprocess/sync/interprocess_condition.hpp:94 #3 0x0000000000402941 in main () at processB.cpp:42 Attached the complete code in tar for your reference. *Compilation and Execution* : *Process A : * Compilation syntax : c++ my_data.cc processA.cpp -I < boost_header_file_path> <boost_lib_path> -lpthread -g -o processA -std=c++11 Execution syntax : ./processA *Process B :* Compilation syntax : c++ my_data.cc processB.cpp -I < boost_header_file_path> <boost_lib_path> -lpthread -g -o processB -std=c++11 Execution syntax : ./processB *Thanks in advance !!!!!* Regards, saravanan =====================================================

2 1

Re: [boost] New JSON library from the maker of Beast!
by Daniel Frey 22 Oct '19

22 Oct '19

> On 23. Oct 2019, at 00:33, Vinnie Falco <vinnie.falco(a)gmail.com> wrote: > > On Tue, Oct 22, 2019 at 3:13 PM Daniel Frey via Boost > <boost(a)lists.boost.org> wrote: >> That sounds like you should stop using the STL altogether. What if std::string is suddenly 2x slower? So... no, I don't buy that argument. >> >> I just switched our JSON library <https://github.com/taocpp/json> from >> our own classic enum+union implementation (back from the C++11 days) >> over to std::variant (as we are now C++17 anyways). > > Any idea why taocpp compiled with optimizations is 5 to 10 times > slower than the other libraries at parsing the same inputs? Yeah... I'd actually *try* to blame MSVC here :) We haven't benchmarked our libraries on Window as we are not Windows users ourselves. The numbers on Linux/MacOS should look different. Have you tested there as well? So Emil's argument has some truth to it, but still I'd rather like to see the STL to improve rather than rolling back. But I haven't even verified it, so take that with a grain of salt. > It seems like there's this thing called PEGTL which has some large > number of functions showing up as taking up time in the profile? What > is PEGTL? The PEGTL is the Parsing Expression Grammar Template Library <https://github.com/taocpp/PEGTL>, our general-purpose parser library. the JSON library actually started out as a benchmark for the PEGTL. Obviously, the parser spends most time in some methods from the PEGTL. And older version that are in the nativejson-benchmark were doing quite well for a general-purpose parser framework <https://github.com/miloyip/nativejson-benchmark#parsing-time>. Not as fast as RapidJSON, but that also largely depends on the design choices for the value type to hold the result.

2 1

Re: [boost] New JSON library from the maker of Beast!
by Vinnie Falco 22 Oct '19

22 Oct '19

On Tue, Sep 24, 2019 at 7:32 AM Dominique Devienne <ddevienne(a)gmail.com> wrote: > ...why conflate the array and object APIs in the value > type, rather than just having as_object() and > as_array() as you already? I agree, and these additional APIs have been pruned. I have also pruned other unnecessary APIs (thanks to advice from Peter Dimov) such as the local iterator and bucket interfaces in `json::object` (which needlessly constrain the implementation). > So I'm curious why it should be different here. Does the doc goes into that already? `json::value` is not `variant<...>` for the same reason that `string_view` is not `std::pair<char const*, std::size_t>`. > On the "compact" side, how compact is your json::value? > What are the different sizeof on 32 and 64-bit arch? I've done some work on this. I gave up on using std::string to represent strings for a few reasons related to performance and API. I have reimplemented string to have a small buffer optimization and to work natively with the `json::storage_ptr` type which gives some space efficiencies (and eliminates some unnecessary atomic operations caused by std::string's Allocator interface). The new sizes look like this: 32-bit sizeof(value) == 40 sizeof(object) == 8 sizeof(array) == 8 sizeof(string) == 32 sizeof(number) == 24 64-bit sizeof(value) == 48 sizeof(object) == 16 sizeof(array) == 16 sizeof(string) == 40 sizeof(number) == 24 The string type has a 20-byte small buffer which is pretty generous Thanks

4 5

[release] Is everyone ready for the 1.72.0 release (cycle)?
by Marshall Clow 21 Oct '19

21 Oct '19

We're getting ready to start the release cycle. People should be familiar with the milestones. They're on the calendar at https://www.boost.org/development/ The first two milestones are: 23-Oct: Boost 1.72.0 closed for new libraries and breaking changes 30-Oct: Boost 1.72.0 closed for major changes -- Marshall

1 0

[Exception] PR #24 passes CI tests
by dariomt＠gmail.com 21 Oct '19

21 Oct '19

Hi, PR #24 [1] at last passes all CI tests. It should solve Issue #10 [2]. I'd like to ask for it to be reviewed and merged. I'm hopeful we can get it into the 1.72 release. Regards, Dario PS: thanks to pdimov for suggesting how to fix the Travis configuration [1] https://github.com/boostorg/exception/pull/24 [2] https://github.com/boostorg/exception/issues/10

1 0

Re: [boost] Adding my sorting algorithm, ska_sort to boost
by Malte Skarupke 20 Oct '19

20 Oct '19

Thanks for the replies. I finished a first pass of the documentation, tests, and other work of including my algorithm in boost and uploaded it here: https://github.com/skarupke/sort/tree/master I also re-ran all the single threaded benchmarks and updated the documentation. For the big O complexity: I am actually still not quite sure what it is. I used similar notation to what spreadsort uses. I think O(n*key_length) is correct for the worst case, but for long keys (like when sorting long strings) the algorithm may fall back to comparison based sorting, so I used the same thing as spreadsort: min(O(n log n), O(n key_length)). For speed: ska_sort should be the fastest sorting algorithm even for small numbers of items. I included three graphs of benchmarks, for sorting ints, floats and strings: https://github.com/skarupke/sort/blob/master/doc/images/sorting_ints.png https://github.com/skarupke/sort/blob/master/doc/images/sorting_strings.png https://github.com/skarupke/sort/blob/master/doc/images/sorting_floats.png For ints and strings ska_sort is always fastest, for floats pdqsort is briefly faster, but starting at N >= 128 ska_sort is faster. Part of the work of this new version of ska_sort was to make radix sort really fast even for small N. Before I would use std::sort for any small array of less than 128 items. Now that cutoff is at 32 items, so I skip straight to insertion sort and never do std::sort. The biggest effect of this change is that it removes the "waves" from the benchmark graph, like we still see for spreadsort in the above picture. I used to also have those when I gave a talk about this algorithm. Now the graph is much more smooth. (this also confuses my answer to the question "what is the big O complexity of this algorithm?" Because the O(n*b) answer that I gave in my talk was justified by the presence of the waves) The biggest questions I have at this point are around the interface. I reworked that completely so that even relatively advanced use cases are now pretty straightforward. I don't think that anyone else will ever need to use those advanced features, so I kept the documentation of them small, choosing instead to focus on the common use cases. And I made sure to give lots of examples of converting existing comparison-based sorting examples to my interface. Oh and for the big point of a parallel version of this algorithm: At this point I have no idea how to do that. I haven't even begun to look into parallel algorithms. The current version was a lot of work already. I think that'll have to be a project for another time. (it's definitely appealing though since currently the sorted algorithms are only 2.4 times as fast as ska_sort on a machine with 8 cores/16 hyper threads in benchmark_numbers.cpp, so even a little bit of parallelism would beat the existing algorithms...) Francisco, since you'll be busy in the near term it sounds like I can't expect too much response for another month, but I would really appreciate it if you could look at it a little just to see if anything obvious stands out to you that I can work on while I wait. (otherwise no biggie, I understand how hard it can be to find time for maintaining projects, since that is exactly one of the reasons why I want to get this into boost...) Thanks, Malte -- Malte Skarupke malteskarupke(a)fastmail.fm > Date: Sun, 20 Oct 2019 13:24:06 +0200 > From: Francisco Jos? Tapia <fjtapia(a)gmail.com> > To: boost(a)lists.boost.org > Subject: Re: [boost] Adding my sorting algorithm, ska_sort to boost > Message-ID: > <CADBNGqQJpHux3AdRJON-nh76BaouRn1FRO4_LrMR76TywmCH+g(a)mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > Hi Malte, > I am Francisco Tapia, one of the co-authors of the Sort library. > We will examine your algorithm. But we must examine the internal parts of > the algorithm, and evaluate the correctness of the algorithm, how is > implemented the worst case and a couple of details. After, we check the > speed with the benchmarks used in the library, with several sets of data. > Since the near sorted to the fully unsorted, and from the single numbers to > structs with heavy comparison functions. > > Now, I am overburdened by work, and I can't revise until December. But we > will do and provide to you a reasoned response, and according to it, decide > the inclusion or not in the library. > As commented by Phil Endecott, the most interesting now is the parallel > algorithms. Today, we don't have any parallel algorithm based on radix sort > or any other hybrid algorithm. > Because with small sets of data the differences are insignificant. But when > you have big sets of data, use parallel algorithms, and then, the new > single thread algorithms are in the middle, in the no man's land. > > If you have any doubt or question, contact me, and I will try to answer you. > > El mar., 15 oct. 2019 a las 23:06, Kostas Savvidis via Boost (< > boost(a)lists.boost.org>) escribi?: > > > > > > On Oct 13, 2019, at 03:06, Malte Skarupke via Boost < > > boost(a)lists.boost.org> wrote: > > > > > > Hi, > > > a couple of years ago I wrote a generalized version of radix sort, > > called ska_sort. I gave a talk about it at CppNow, available here: > > > https://www.youtube.com/watch?v=zqs87a_7zxw > > > > > > I have a new version of that algorithm that is both faster and more > > general. I can now sort almost anything. For example when I gave the talk I > > couldn't sort a std::vector<std::list<int>> because std::list doesn't have > > a random access interface, but now that works. (and it's faster than > > sorting the same thing with std::sort) > > > > > > > This seems like a product of a large investment of effort. > > The big advantage over any previously available radix_sort > > is the ability to sort almost any datatype if a key maps to an integer > > somehow. > > Plus, an advantage in measured practical speed, and apparently no claims > > about Big O improvement. > > > > The average performance is O(n*b) where b is unknown and/or dependent on n > > ? > > > > Is the theoretical worst-case O(n^2) ? Why? Is it because of working > > in-place? > > (yes, I understand you fall back to std::sort if you hit this case) > > > > Is this software/algorithm fully documented? - I mean by another way than > > reading the source code. > > > > Maybe too many questions at once, but it was not clear after watching your > > talk at cppcon and the blog posts. > > > > Cheers, > > Kostas > > > > <https://www.youtube.com/watch?v=Nz1KZXbghj8> > > > > _______________________________________________ > > Unsubscribe & other changes: > > http://lists.boost.org/mailman/listinfo.cgi/boost > > > > > ------------------------------ > > Subject: Digest Footer >

1 0

constexpr for boost::endian
by Gero Peterhoff 20 Oct '19

20 Oct '19

Hello developer, can you implement constexpr support for boost::endian? And i'm missing support for (compiler-dependent) int128 (boost::u/int128_type). thx Gero

2 2

Adding my sorting algorithm, ska_sort to boost
by Malte Skarupke 20 Oct '19

20 Oct '19

Hi, a couple of years ago I wrote a generalized version of radix sort, called ska_sort. I gave a talk about it at CppNow, available here: https://www.youtube.com/watch?v=zqs87a_7zxw I have a new version of that algorithm that is both faster and more general. I can now sort almost anything. For example when I gave the talk I couldn't sort a std::vector<std::list<int>> because std::list doesn't have a random access interface, but now that works. (and it's faster than sorting the same thing with std::sort) I've also made it much easier to extend the algorithm with your own types. It was always easy if your type isn't too complicated, but now even weird types like std::variant are pretty easy to add. In my old version I had to go deep into the guts to add support for std::variant, now it's easy enough to do that that I'll add it to the documentation. I'm thinking of releasing the new version in boost, mainly so that it will be used more widely and so that it can be kept working in the long term. Since this is a long weekend in the US, I will try to as much of the work as possible this weekend. I'm currently trying to figure out how the boost documentation works (I saw that there are quickbook files in Boost.Sort, but how do I run the build for it?) and I've already made good progress on cleaning up my code and making it use the boost::sort namespace. Before I go any further I wanted to ask though: Does boost want my sorting algorithm? This would essentially deprecate spreadsort since this one is faster and more general and easier to use. To convince you that this is worth adding, I ran the benchmark that is included in the Boost.Sort source code. On random numbers here is how long all the algorithms took: std::sort: 9.04 pdqsort: 4.65 std::stable_sort: 11.57 spinsort: 5.42 flat_stable_sort: 7.26 spreadsort: 4.41 ska_sort: 2.00 There are a lot more bencmarks in the Boost.Sort code, and in general the results are this: If the data is already sorted or mostly sorted, other algorithms are faster, but if there are no easy patterns, ska_sort is always fastest. (I was going to include the entire table in this email, but the formatting breaks. I can attach all the results separately if anyone is interested) The Boost.Sort code also has benchmarks for sorting "objects" and "strings" and the results are similar there: On random data ska_sort is always fastest. I think this new version would be great in boost. It's not every day that a new sorting algorithm comes along that's literally twice as fast as what we had before. If we want this in boost, what would the next steps be? From the "submission process" document it sounds like there will be several stages of "Refinement" for the code. (or should this go through the Boost Library Incubator?) After I figure out how the documentation works I can upload a first version of this to github. (I want to get the documentation working so that we can talk about the interface) Let me know what you think, Malte -- Malte Skarupke malteskarupke(a)fastmail.fm

5 4

[SPAM] [preprocessor][vmd] Updates to the preprocessor and vmd libraries
by Edward Diener 19 Oct '19

19 Oct '19

The C++20 preprocessor construct __VA_OPT__ has the additional affect of providing the ability to write a general purpose macro for testing emptiness, ie. no preprocessor tokens, in C++ macro programming that is 100% reliable for any preprocessor data passed to it. Previously such a macro testing for emptiness always had some corner cases where the test might fail with a preprocessor error, but in C++20 mode at least the test can now be completely reliable in all cases. So I have added two macros along with documentation, as well as a topic discussing emptiness, to the Boost PP library. The first macro is called BOOST_PP_VARIADIC_OPT, invoked with no parameters as BOOST_PP_VARIADIC_OPT(), which expands to 1 if the compiler is in C++20 mode, supports variadic macros, and supports the C++ 20 __VA_OPT__ construct, and otherwise expands to 0. The second macro, which only exists if BOOST_PP_VARIADIC_OPT() expands to 1, is called BOOST_PP_CHECK_EMPTY. This second macro is a variadic macro which takes a single parameter of variadic data, and expands to 1 if the data is empty or expands to being empty, while otherwise expanding to 0 if the data is not empty. Furthermore in the Boost VMD library I have updated the BOOST_VMD_IS_EMPTY macro to essentially invoke the BOOST_PP_CHECK_EMPTY macro when BOOST_PP_VARIADIC_OPT() expands to 1, while retaining the current processing when that is not the case. As well I have updated the VMD discussion of emptiness in the documentation of Boost VMD to include information about the ability to provide a 100% reliable test for emptiness in C++20. Neither change in Boost PP or Boost VMD should affect any end-user or Boost library in any way. There are tests for all these changes and all tests have passed. I will update the release notes for Boost PP and Boost VMD for the next release of Boost with this information. As always any comments, questions, or criticism of these changes are always welcome.

1 1

Warning from Boost.Exception
by pbristow＠hetp.u-net.com 17 Oct '19

17 Oct '19

Using Clang 9 on Windows b2 toolset-clang-linux cxxstd=2a . I am seeing lots of these warnings In file included from ..\..\..\boost/test/included/unit_test.hpp:23: In file included from ..\..\..\boost/test/impl/execution_monitor.ipp:37: In file included from ..\..\..\boost/exception/diagnostic_information.hpp:11: ..\..\..\boost/exception/info.hpp:134:21: warning: delete called on non-final 'boost::exception_detail::error_info_container_impl' that has virtual functions but non-virtual destructor [-Wdelete-non-abstract-non-virtual-dtor] delete this; ^ It seems that trying to supress is ineffective with -Wno-delete-non-abstract-non-virtual-dtor Perhaps by design? https://releases.llvm.org/9.0.0/tools/clang/docs/DiagnosticsReference.html#… te-non-abstract-non-virtual-dtor -Wdelete-non-abstract-non-virtual-dtor <https://releases.llvm.org/9.0.0/tools/clang/docs/DiagnosticsReference.html> Diagnostic text: warning: delete destructor called on non-final B that has virtual functions but non-virtual destructor -Wdelete-non-virtual-dtor <https://releases.llvm.org/9.0.0/tools/clang/docs/DiagnosticsReference.html> Some of the diagnostics controlled by this flag are enabled by default. Controls -Wdelete-abstract-non-virtual-dtor <https://releases.llvm.org/9.0.0/tools/clang/docs/DiagnosticsReference.html> , -Wdelete-non-abstract-non-virtual-dtor <https://releases.llvm.org/9.0.0/tools/clang/docs/DiagnosticsReference.html> . Should I be concerned about this? Paul Paul A. Bristow Prizet Farmhouse Kendal, Cumbria LA8 8AB UK

4 13

[Math] float16 on ARM
by Phil Endecott 16 Oct '19

16 Oct '19

Hi, There seems to be support for 16-bit floats on iOS, when using Apple's XCode clang. This seems to be a storage-only format with the only instruction set support being conversions to and from 32- and 64-bit floats. Quick test: #if __ARM_FP & 2 #warning "Have 16-bit FP" #endif void test() { __fp16 a = 1.234; static_assert(sizeof(a)==2); __fp16 b = 2.345; auto sum = a+b; static_assert(sizeof(sum)==4); } There doesn't seem to be a std::numeric_limits specialisation. I suspect that other platforms have something similar. It would be good to have a boost::float16_t typedef and a portable feature-test macro (and maybe a software fallback). As far as I can see, boost/math/cstdfloat/cstdfloat_types.hpp checks the sizes of float, double and long double, and checks for 128-bit floats provided by the compiler. Can this be extended to check for __fp16 ? (P.S. it seems that gcc also has support, see https://gcc.gnu.org/onlinedocs/gcc/Half-Precision.html ) Cheers, Phil.

5 10

Does boost asio ssl support sslv3?
by JH 15 Oct '19

15 Oct '19

Hi, I've been running boost asio socket and sslv2 for many months, it works very well: server.cpp ontext_(boost::asio::ssl::context::sslv23) context_.set_options(boost::asio::ssl::context::default_workarounds | boost::asio::ssl::context::no_sslv2 | boost::asio::ssl::context::single_dh_use); context_.set_password_callback(boost::bind(&Server::get_password, this)); context_.use_certificate_chain_file("ssl/server.pem"); context_.use_private_key_file("ssl/server.pem", boost::asio::ssl::context::pem); context_.use_tmp_dh_file("ssl/dh2048.pem"); on client.cpp boost::asio::ssl::context context(boost::asio::ssl::context::sslv23); Recently we changed a nodejs server nodejs which using sslv3, the client failed to connect to server sslv3: Failed handshake: sslv3 alert handshake failure Any tips how to fix sslv3 handshake failure? Thank you. Kind regards, - jh

4 6

Cryptic Boost.Build error (help required!)
by John Maddock 14 Oct '19

14 Oct '19

Can anyone see what's wrong here: https://github.com/boostorg/regex/issues/89 ? The reduced test case is: |./b2 -sICU_PATH="/opt/some/path" -sICU_LINK="-L/opt/some/path/lib/x86_64-linux-gnu -licuuc -licudata -licui18n" toolset=gcc-8 -n --with-filesystem --with-log Many thanks, John. | -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

2 1

[gil][docs] Image Processing docs structure based on "Principles of Digital Image Processing" book
by Mateusz Loskot 13 Oct '19

13 Oct '19

Hi, (Copying to boost and boost-users lists) If you are passionate about C++ and image processing and interested in writing documentation about it, here is a good first issue for you if you'd like to start contributing to Boost.GIL. During the course of GSoC 2019 we have received first batch of IP features, there is not great deal of content yet, so shouldn't be overwhelming to get started. It's rather a clean slate under your control. Don't be shy! :-) Regards, Mateusz Loskot ---------- Forwarded message --------- From: Mateusz Loskot <mateusz(a)loskot.net> Date: Sun, 13 Oct 2019 at 20:08 Subject: [GH #396] Image Processing docs structure based on "Principles of Digital Image Processing" book To: <boost-gil(a)lists.boost.org> Hi, Following our successful GSoC 2019, I have started discussion on proposal of improved and future-proof structure of the "Image Processing" chapters of GIL documentation. Here are details: https://github.com/boostorg/gil/issues/396 Please, have a look and share your feedback. If there is anyone experienced in writing docs, a technical write, who is looking for ways to contribute to Boost and Boost.GIL, this is a very good first issue to pick :-) Best regards, -- Mateusz Loskot, http://mateusz.loskot.net -- Mateusz Loskot, http://mateusz.loskot.net

1 0

[outcome] Major changes for Boost 1.72 release
by Niall Douglas 11 Oct '19

11 Oct '19

Just as a heads up to those who care, and any pretesting of these changes in advance of the Boost release is welcome. There are two breaking changes: 1. The git submodule mechanism used by standalone Outcome of specifying dependent libraries has been replaced with a cmake superbuild of dependencies mechanism instead. Upon cmake configure, an internal copy of quickcpplib will be git cloned, built and installed into the build directory from where an internal `find_package()` uses it. This breaks the use of the unconfigured Outcome repo as an implementation of Outcome, one must now do one of: 1. Add Outcome as subdirectory to cmake build 2. Use cmake superbuild (i.e. `ExternalProject_Add()`) to build and install Outcome into a local installation. 3. Use one of the single header editions. 2. For standalone Outcome, the current compiler is now checked for whether it will compile code containing C++ Concepts, and if it does, all cmake consumers of Outcome will enable C++ Concepts. Set the cmake variable `CXX_CONCEPTS_FLAGS` to an empty string to prevent auto detection and enabling of C++ Concepts support occurring. There are two new features: - Standalone outcome is now `make install`-able, and cmake `find_package()` can find it. Note that you must separately install and `find_package()` Outcome's dependency, quickcpplib, else `find_package()` of Outcome will fail. - Support for C++ Coroutines has been added. This comes in two parts, firstly there is now an `OUTCOME_CO_TRY()` operation suitable for performing the `TRY` operation from within a C++ Coroutine. Secondly, in the header `outcome/coroutine_support.hpp` there are implementations of `eager<OutcomeType>` and `lazy<OutcomeType>` which let you more naturally and efficiently use `basic_result` or `basic_outcome` from within C++ Coroutines -- specifically, if the result or outcome will construct from an exception pointer, exceptions thrown in the coroutine return an errored or excepted result with the thrown exception instead of throwing the exception through the coroutine machinery (which in current compilers, has a high likelihood of blowing up the program). Both `eager<T>` and `lazy<T>` can accept any `T` as well. Both have been tested and found working on VS2019 and clang 9. More detail can be found at: https://boostorg.github.io/outcome/changelog.html Niall

3 4

Seeing spam designation in message title
by Edward Diener 10 Oct '19

10 Oct '19

The previous message I sent to this mailing list shows the word [SPAM] in the title to the message. Does anybody know why this happened ? I am obviously not a spammer being the author of two libraries and maintainer of another.

3 3

Regression tests on 'develop'
by Edward Diener 10 Oct '19

10 Oct '19

It looks like on the 'develop' side most regression tests are either not being run very often or there is some problem in the posting of the latest results. I suspect the former but I thought it should at least be brought up. On the 'master' side many more recent recent regression tests are showing.

1 0

A solution to return dynamic strings without heap allocation. Any interest?
by Roberto Hinz 09 Oct '19

09 Oct '19

Hi all, I haven't been succesful at attracting interest in a formatting library [1] I've been working lately. But recently I realized that part of it could be isolated as a small standalone library that could solve an old common troublesome situation in C++: Suppose you need to create a function that returns/provides a string whose content and size is unknown at compilation time. The first approach is to make it return a `std::string`. But if it need to be usable in environments like bare-metal real-time system, then one usually makes it take a raw string as an output argument, more or less like this: struct result{ char* it; bool truncated; }; result get_message(char* dest, std::size_t dest_len); But this is clearly not a perfect solution since there's nothing really effective the caller can do when get_mesage fails because of the destination string being is too small. So I present the `outbut` abstract class. It somehow resembles `std::streambuf`, but with a simpler and lower level design, which is the result of many attempts looking for the best performance [2] and usability in my formatting library. Afaics, it does not require a hosted C++ implementation, though I would like someone else to confirm that. Now the caller of `get_message` has to choose or create a suitable class type deriving from outbuf, that dictates where the message is written to. For example, if the user wants to get a `std::string`, then `string_maker` will do the job: #include <boost/outbuf/string.hpp> // ... boost::outbuf::string_maker<false> msg; get_message(msg) std::string str = msg.finish(); Or, if one wants it to write into a raw string, then use `cstr_writer` char buff[buff_size]; boost::outbuf::cstr_writer csw(buff, buff_size); get_message(csw); auto result = csw.finish(); if (result.truncated) { // ... Those `finish` functions above do not belong to `outbuf`. They are defined in the concrete derived types only. It's solely by convention that they share the same name. Yes, using `string_maker` still leads to heap allocation and `cstr_writer` to string truncation. The problem isn't solved by these. However, a string object is never the final destination. So the user could rather use another class that writes the message directly into the final destination ( output console, a log file, an LCD display or whatever ). It is not difficult to implement concrete subtypes of `outbuf`. `outbuf` is actually a type alias: template <bool NoExcept, typename CharT> class basic_outbuf; using outbuf = basic_outbuf<false, char>; using outbuf_noexcept = basic_outbuf<true, char>; That `NoExcept` template parameter is perhaps the controversial part. It is not present originally in my formatting library. Besides the destructor, `basic_outbuf` has only one virtual function: `recycle()`, and it is declared as `noexcept(NoExcept)`. This is the only effect the `NoExcept` template parameter has. All other functions are guaranteed not to throw. Hence, by taking a `outbuf_noexcept&` parameter, a function states that the destination must not throw. That might be particularly good if such object comes from another module and we must avoid exceptions crossing modules boundaries. On the other hand, if a function takes an `outbuf&`, then it also accepts `outbuf_noexcept&`, because `basic_outbuf<true, CharT>&` derives from `basic_outbuf<false, CharT>`. When using `string_maker` you can choose between the two kinds. `string_maker<true>` derives from `basic_outbuf<true, char>&`. So if any exception raises from its internal `std::string`, then it is caught by a try/catch(...) block, stored as an `exception_ptr` and rethrown by `finish()`. This has the undesirable effect of delaying its proper handling ( after all, we rather stop what's being doing as soon as possible when an error appears ). So I think the recommendation would be to use `string_maker<false>&` if possible, and `string_maker<true>&` only if necessary. The reason why I think it's controversial is that it makes `recycle()` violates the Lakos Rule. And although the Lakos Rule is not a requirement in boost (afaik), I was wondering whether this library could interest LEWG in future as well. Anyway, this whole noexcept idea is not a central part of this library and can it be removed. Now, the other topic is how to implement that `get_message` function, i.e., how to write into an `outbuf` object. One can use `puts` and `putc` functions to insert string and chars. One can also use `fmtlib` through an output iterator adapter. Or one can write directly in the buffer. But I will ask you to read the doc [3] for that. It's a quick read, quicker than this email. The repository is: https://github.com/robhz786/outbuf I would prefer it to be part of Boost.Core instead of being a standalone library, and also to remove the `outbuf` namespace. But that is up to you. Best regards, Roberto [1] The Stringify library: https://github.com/robhz786/stringify [2] The great performance of Stringify is mainly thanks to the design of outbuf ( named there as `output_buffer` ): https://robhz786.github.io/stringify/doc/html/benchmarks/benchmarks.html#be… [3] "Writing into and outbuf object" https://robhz786.github.io/outbuf/doc/html/index.html#boost_outbuf.overview…

5 13

[Boost.MSM] Please, update master with changes from develop
by Deniz Bahadir 08 Oct '19

08 Oct '19

Hello world, I just stumbled across a compilation-error with the latest Boost release (1.71) of Boost.MSM for which I already provided a merge-request [1] a year ago, and which was merged to "develop" branch at that time, too. Still, the "master" branch lags this merge-request (and a lot more [2] from former years which are in "develop") but has some other unrelated merge-requests [3] merged in which are not in "develop". I would love seeing "develop" being merged into "master" (and maybe vise-versa) so that bugs for which fixes already exist will no longer be present in the next Boost release. Thanks for taking care of. Deniz [1] https://github.com/boostorg/msm/pull/15 [2] https://github.com/boostorg/msm/compare/master...develop [3] https://github.com/boostorg/msm/compare/develop...master

3 2

[contract] new maintenance release for Boost 1.72
by Lorenzo Caminiti 07 Oct '19

07 Oct '19

Hello Release Managers & all, I made a maintenance release of Boost.Contract. All tests pass, docs are updated, etc. The code is up-to-date in boost/contract/master. Can you please pull changes from boost/contract/master into the upcoming Boost 1.72 release? These are the changes: * Using std::uncaught_exceptions on C++17 compilers onward (instead of the now obsolete std::uncaught_exception). * Fixed a few warnings. * Removed linking to Boost.System (Boost.System is now a header-only library). * Added this library to Boost's Continuous Integration (CI). * Fixed documentation typos. Thank you in advance. --Lorenzo

2 2

git pull on Boost 'develop' branch problem
by Edward Diener 03 Oct '19

03 Oct '19

When I do a 'git pull' on Boost checked out to 'develop' it ends with: error: Server does not allow request for unadvertised object 3eb4826d1d2a3e46207a7e4a0467d9bab96d37f5 Anybody know why this is happening with the latest Boost in the 'develop' branch and if I need to do something to correct this ? It does not seem to b3e affecting anything, and it appears the 'git pull' is successful at the top level in pulling the latest 'develop' changes.

4 3

Re: [boost] New JSON library from the maker of Beast!
by Bjorn Reese 30 Sep '19

30 Sep '19

On 9/30/19 12:14 PM, julien.blanc(a)tgcm.eu wrote: > Do you have an example of an efficient implementation of a pull parser on top of async io ? I find push parsers really more straightforward in that case. Vinicius has an HTTP pull parser here: https://github.com/BoostGSoC14/boost.http > Pull parsers can also be built on top of push parsers, although it is less easy. Indeed, that is how we implemented XmlTextReader in libxml2, and it was a rather painful experience. Coroutines can help, as Phil pointed out, but pull parser are also a natural fit for parser combinators (e.g. HTTP contains a partial URL syntax, so it could be created combining HTTP and URL pull parsers.) I am not sure how well coroutines would handle this case.

1 0

Who is maintaining Boost.Random?
by Christoph Conrads 29 Sep '19

29 Sep '19

Last Tuesday I submitted a feature request for Boost.Random and received absolutely no feedback which seems to be unusual judging by last week's discussions (e.g. secure-by-default networking with Boost.Asio). Is anybody maintaining Boost.Random currently and if not, how can I proceed with my feature request? Christoph Conrads

2 3

How to handle contributions from anonymous?
by Hans Dembinski 27 Sep '19

27 Sep '19

Hi all, I got a PR from a contributor who prefers to remain anonymous. The person created new files and instead of putting a real name, the person added just initials. I am talking to the person to see whether they can be convinced to give a real name. Any advice on how to handle this? My feeling is that a copyright notice without a real name is illegal. I could publish the code in my name, but then a documented transfer of copyright from the contributor to me is missing, which then puts me in a vulnerable position. Any thoughts? Best regards, Hans

5 6

MS STL now open source (and using Boost)
by John Maddock 26 Sep '19

26 Sep '19

Microsoft's standard library is now in the process of going open source (the code is there, but not the tests yet), see : https://devblogs.microsoft.com/cppblog/open-sourcing-msvcs-stl/ Interestingly they're using the Math library's special functions en-mass for enhanced <cmath> support, and a quick grep of the code turns up other references to Boost, though I haven't identified the libraries they've borrowed from yet. Hopefully this means that in the long turn we'll see patches and enhancements flowing in both directions for the benefit of all. John. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

11 14

more (hyper)complex types
by Gero Peterhoff 26 Sep '19

26 Sep '19

Hallo Developers, Hello John, I'm missing the (hyper)complex types in boost::math: - dual, i²=0 https://en.wikipedia.org/wiki/Dual_number - acomplex (anormal complex), i²=1 https://en.wikipedia.org/wiki/Split-complex_number - sedenion, https://en.wikipedia.org/wiki/Sedenion and the arithmetic functions for this types. Can you provide it? That would be great! thx Gero

3 2

Memory leak in add_options
by Vinitha Anish(UST,IN) 24 Sep '19

24 Sep '19

Hi , Our static analyzer report an memory leak with add_options . We use namespace po = boost::program_options; po::options_description desc("Options"); desc.add_options() ("name", po::value<std::string>(), ...) // add option ; The issue reported in boost library file value_semantic.hpp:199 template<class T> typed_value<T>* value(T* v) { typed_value<T>* r = new typed_value<T>(v); return r; } memory is dynamically allocated here and return at line 201. Can anyone suggest how do we handle this memory leak.

1 0

How to bind boost::asio::ip::tcp::socket to a local endpoint with a sperific local IP address?
by JH 24 Sep '19

24 Sep '19

Hi, I have searched the documents, but still could not clarify how to bind the socket to a local IP address, which API could I add my local IP address to it? socket.bind(boost::asio::ip::tcp::endpoint(boost::asio::ip::tcp::v4(), 12345)); ....... boost::asio::ip::tcp::resolver::query query(remoteServerIPAddress, portNumber); Thank you. Kind regards, - jh

3 3

Source code of boost-commitbot git user
by LE GARREC Vincent 24 Sep '19

24 Sep '19

Hi, I work on a company where the architecture of the software is closed to boost : one super project and lots of submodules. We are spending lots of time with the superproject by doing "fetch/merge/checkout" every time because someone else updated a submodule just 15 minutes ago. In boost, it looks like the superproject is updated by Travis (or maybe a git post hook ?). Does this script is available somewhere? It will really help us and improved your time. I took a look but I didn't find anywhere the source code. Thanks for your help, Best regard, Vincent

1 0

clang-9 on travis?
by John Maddock 23 Sep '19

23 Sep '19

Has anyone figured out how to install clang-9 on travis? I'm seeing: Adding APT Sources Disallowing sources: llvm-toolchain-xenial-9 See https://travis-ci.org/boostorg/multiprecision/jobs/588146074 With .travis.yml containing: - os: linux env: TOOLSET=clang COMPILER=clang++-9 CXXSTD=c++17 TEST_SUITE=misc addons: apt: packages: - clang-9 - libgmp-dev - libmpfr-dev - libmpc-dev - libmpfi-dev sources: - ubuntu-toolchain-r-test - llvm-toolchain-xenial-9 Which works fine for clang-8. Any ideas anyone? Thanks! John. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

2 2

Call for Papers - ICITST-2019 - London, UK
by Galina Akmayeva, ICITST 20 Sep '19

20 Sep '19

CALL FOR PAPERS! ************************************************************ The 14th International Conference for Internet Technology and Secured Transactions (ICITST-2019) Venue: CCT Venues-Docklands London, UK December 9-11, 2019 www.icitst.org ************************************************************ The ICITST is an international refereed conference dedicated to the advancement of the theory and practical implementation of secured Internet transactions and to fostering discussions on information technology evolution. The ICITST aims to provide a highly professional and comparative academic research forum that promotes collaborative excellence between academia and industry. The ICITST-2019 invites research papers that encompass conceptual analysis, design implementation and performance evaluation. The topics in ICITST-2019 include but are not confined to the following areas: Internet Applications and Technology: * Internet Architecture * Internet of things * Broadband Access Technologies * Application Agents * Boundary Issues of Internet Security * Database Management * Data Models for Production Systems and Services * Artificial Intelligence and Expert Systems * IPSec Quality of Service * Knowledge Management * Embedded Systems * Defence Systems Ubi/Cloud Computing: * Authentication and Access Control for Data Protection in Ubi/Cloud Computing * Context-Awareness and its Data Mining for UbiCom * Data Grids * Distributed Information Systems * Human-Computer Interface and Interaction for UbiCom * Ubiquitous Systems * USN/RFID Service * Smart Homes and its Business Model for UbiCom Service * Security and its Data Management for UbiCom * Peer to Peer Data Management * New Novel Mechanism and Application for Ubi/Cloud Computing Information Security: * Trust, Privacy and Data Security * Network Security Issues and Protocols * Security Challenges and Content Authoring * Cryptography * Secure Communications * Authentication Techniques * Chaos-based Data Security * MANET Security * Wireless Sensor Network Security * Organization Considerations in Security Policy Formulation and Implementations * Digital Forensics and Crimes * Biometrics * Cyber Security Multimedia and Web Services: * Intelligent Multimedia and its Data Management * Multimedia Information Systems * Multimedia Security * Web Databases * Web Metrics and its Applications * Web Mining including Web Intelligence and Web 3.0. * Web Services * XML and other extensible languages * Semantic Web and Ontology Bitcoin *Challenges and its Roadmap *Crypto-Assets *Current State of Privacy in Bitcoin *Decentralised Technology *Data Licensing *Digital Currencies *Fintechs *Future Payment Implications *Standardisation-Related Issues *Technical, Business and Regulatory Aspects *Technology-based Risks Infonomics and e-Technology: * Infonomics * Information Visualization * Information Management * Information Quality * Technology-Enabled Information * e-Learning * e-Commerce * e-Business * e-Government * e-Society * System Design and Security for e-Services * Synchronizing e-Security Submissions: *You can submit your abstract via email at abstract(a)icitst.org *You can submit your extended abstract or paper online at http://icitst.org/paper-submission/ or email it to extendedabstract(a)icitst.org or papers(a)icitst.org *You can submit your poster via email at posters(a)icitst.org *You can submit your workshop or tutorial proposal via email at workshop-tutorial(a)icitst.org *You can submit your speaker's proposal online at https://icitst.org/call-for-speakers/ or via email at speakers(a)icitst.org Submission Dates: *Abstract and Extended Abstract Submission Date: September 20, 2019 *Notification of Abstract and Extended Abstract Acceptance/Rejection: September 25, 2019 *Proposal for Industrial Presentation: September 20, 2019 *Notification of Industrial Presentation Acceptance: September 25, 2019 *Full Paper Submission Date: September 27, 2019 *Notification of Paper Acceptance/Rejection: October 10, 2019 *Workshops and Tutorials Submission Date: September 20, 2019 *Notification of Workshop and Tutorial Acceptance: September 25, 2019 *Special Track Submission Date: September 20, 2019 *Notification of Special Track Acceptance: September 25, 2019 *Poster/Demo Submission Date: September 20, 2019 *Notification of Poster/Demo Acceptance: September 25, 2019 *Camera Ready Paper Due: November 15, 2019 *Early Registration Deadline: October 25, 2019 *Late Registration Deadline: November 25, 2019 *Conference Dates: December 9-11, 2019 For more details, please contact [1]info(a)icitst.org References 1. mailto:info@icitst.org

1 0

[multiprecision] how to catch both underflow and overflow
by blacksmith＠peerfreedom.org 20 Sep '19

20 Sep '19

Hello, when using boost multiprecision [1] to execute even simple math operations like addition x = x+1 or x-1 it seems on mathematical error it might throw either std::range_error or std::overflow_error or std::underflow_error . Sadly it seems that it's not the case that overflow and underflow are child classes of range_error. So, in more complex math expression to detect any math error you must write catch(....) for all 3 of them (because just catching common std::runtime_error would be too broad and might hide some unrelated error). Is there some better way for this? Perhaps boost should introduce a common type for math error and throw own under/over/range errors that inherit from std's one (for compatibility) and also inherit from boost::math_range_error to allow catch (boost::math_range_error) // either over/under flow or other math [1] for example using type like: boost::multiprecision::number< boost::multiprecision::cpp_int_backend< 64-1, 64-1, boost::multiprecision::signed_magnitude, boost::multiprecision::checked, void> > -- GPG: 31A8 55AA 07BE 5145 65EB 2292 65A6 1F7A 9781 DF89

3 2

Requesting endorsements of Boost.STLInterfaces for review
by Zach Laine 20 Sep '19

20 Sep '19

As mentioned a couple of weeks ago, I started a small library that was an updated iterator_facade. It is now a still-smallish library called stl_interfaces that includes a pre-C++20 implementation of view_interface, and analogous templates iterator_interface (a cross between Boost.Iterator's iterator_facade and iterator_adaptor), and container_interface. Each of these makes it easier to write a view, iterator, or container, respectively. Using container_interface, I was able to write a version of static_vector in which I implemented only 21 member functions, and the template provided the other 40(!) functions. The library is C++14 and later. There is an inline v1 namespace for the C++14 implementations, and an experimental non-inline v2 namespace with implementations using C++20 standard concepts. The part using C++20 concepts requires GCC 8 or 9, and cmcstl2 (more info on that on the Github page). Github page: https://github.com/tzlaine/stl_interfaces Online docs: https://tzlaine.github.io/stl_inteTherfaces/doc/html/index.html <https://tzlaine.github.io/stl_interfaces/doc/html/index.html> Oh, and if you're willing to act as review manager, please let me know. Zach

9 17

[GitHub] Checks not listed for Travis CI
by Mateusz Loskot 18 Sep '19

18 Sep '19

Hi, GitHub offers the Checks tab [1] which displays CI checks based on Travis CI, Azure Pipelines, etc. I can't find out why the Travis CI ones are not displayed for any of repositories under github.com/boostorg/ I checked Histogram, Beast, and a few others and ffor GIL only Azure Pipelines is displayed (I integrated AzP there from the marketplace fairly recently). I suspect, that is due to the fact Travis CI integration was installed long time ago, using an old way, so it does not 'recognise' new features. For example, using the old webhooks/services method now deprecated which then was automatically ported to new marketplace-based integrations. Does anyone know how to add the Checks feature to boostorg/ repos? One of interesting feature of it is that it can display "a specific line in a commit causes a check to fail" [1] [1] https://help.github.com/en/articles/about-status-checks#checks Here is example of the Checks in full: https://github.com/OSGeo/gdal/pull/1776/checks I can confirm enabling the Checks has nothing to do with the branch protection feature and enabling required statuses of PRs. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

2 2

Details of environment building release docs and website
by Mateusz Loskot 18 Sep '19

18 Sep '19

Hi, Where can I find details about the environment used to build the website and the documentation for the releases? For example, - What is the OS? (i.e. system packages can be identified then) - What is toolset and compiler version used? GCC 4.8? - What is the version of Python, Doxygen, AsciiDoc, Sphinx? I looked at these places, but it's still unclear to me https://www.boost.org/development/website_updating.html https://github.com/boostorg/website/blob/master/.travis.yml Or was I supposed to derive the answer from the Travis CI's image php:'5.3'? Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

1 0

[Quickbook] VSCode Extension for syntax colouring & simple preview
by Jan Bouwer 18 Sep '19

18 Sep '19

I've built a Visual Studio Code <https://code.visualstudio.com/> extension to provide simple syntax colouring & preview generation for Boost.Quickbook source files. It is available from within the VSCode extension marketplace or at https://marketplace.visualstudio.com/items?itemName=JBouwer.boost-quickbook… - from where the GitHub repos/issue tracker can be accessed too. Perhaps somebody else may find this useful too - like I have. Regards Jan Bouwer

2 1

[program_options] Proposal: self-contained, header-only port of Boost Program Options library
by Vicram Rajagopalan 17 Sep '19

17 Sep '19

I am interested in creating a header-only implementation of the Boost Program Options library that only depends on the C++ standard library. Program Options uses several other Boost libraries, so I would have to re-implement some of it using standard library constructs. I have 2 questions for the community: 1. Would you use something like this if it were available? 2. Do you know of any implementation details of Program Options which might make some part of this difficult or impossible? To be clear, I do not intend for this to be merged into Boost in any form. Rationale: There is no portable command-line argument-parsing capability in the C++ standard library. There's getopt, but that's in unistd.h which is only available on Unix-based systems. The only widely-used C++ command-line parsing library I am aware of is Program Options, but that requires adding a dependency on Boost to your project, which seems like overkill to me. I would like to be able to simply add a project as a submodule in my Git repo and #include it without even having to add anything to my build files. The goal is to ensure that the library is as portable and easy to include as possible, because it shouldn't be difficult to parse command-line options. I appreciate any thoughts, comments, or criticisms! -Vicram Rajagopalan

9 14

[Boost.numeric.ublas] Compiler warnings when building with O2 optimizations and NDEBUG defined
by Albert Perlman 17 Sep '19

17 Sep '19

I am using boost v1.69, compiling with g++-7 for an x86 target. If I build with -O2 optimization flags when NDEBUG is defined, I get the following compiler warning: ./../boost/numeric/ublas/matrix_expression.hpp:59:20: error: ‘*((void*)&<anonymous> +8)’ is used uninitialized in this function [-Werror=uninitialized] return e_.size2 (); If I add -fno-partial-inling to the compiler flags, this makes the warning go away. This warning does not appear if NDEBUG is not defined, regardless of optimization flags. This behavior is the same with boost v1.71. I would like to build with the -fpartial-inling optimization when NDEBUG is defined. Is there a workaround to fix this warning? -- Albert -- IMPORTANT: The information contained in this transmission may be privileged, proprietary and confidential and protected from disclosure. It is intended only for the intended recipient. If you are not the intended recipient or a person responsible for delivering this transmission to the intended recipient, you may not disclose, copy or distribute this transmission or take any action in reliance on it. If you received this transmission in error, please notify us immediately by replying to this message and please dispose of and delete this transmission. Thank you. Yaskawa America, Inc.

1 0

Write data to NAND flash file system
by JH 13 Sep '19

13 Sep '19

Hi, I am using boost::filesystem to write / remove files to NAND flash file system where it writes by pages, the system can cache and pack data upon write back to avoid segmentation if fsync(), fdatasync(), O_SYNC or a sync mounted filesystem are not used to force write. Will the boost::filesystem::ofstream and operator<< involve any of sync call? Which IO library is not using sync call? Thank you. Kind regards, - jupiter

1 0

math
by Gero Peterhoff 12 Sep '19

12 Sep '19

Hello Developers, Hello John, thanks for making the float128_t features I missed available in boost 1.71. But: - I miss in boost::math::constants log2_e (M_LOG2E); You have written in the documentation that all constants are now available; are there any other constants missing? - in boost/multiprecision/float128.hpp, the value in numeric_limits<float128_t>::is_bounded must be true Thanks and Greetings Gero

2 1

Secure-by-default networking
by Alex Christensen 11 Sep '19

11 Sep '19

At https://github.com/boostorg/asio/pull/283 <https://github.com/boostorg/asio/pull/283> I’ve attached a proof-of-concept which explores making ASIO secure by default. The C++ committee is discussing what secure-by-default networking would look like in the soon to be published papers P1860 and P1861. Since the C++ Networking TS is based on ASIO, this seems like a good place to try things out. The implementation uses BoringSSL for its crypto and Security.framework to evaluate certificates against the root certificates trusted by the system. I've implemented enough to see what the API shape would need to be, and it works with basic client and server programs. I’d love to get your feedback on this initial work, including any implementation concerns you have and suggestions on portability. I don’t think the patch is ready to commit as-is.

3 2

Re: [boost] Secure-by-default networking
by Bjorn Reese 11 Sep '19

11 Sep '19

On 9/11/19 1:35 AM, Alex Christensen via Boost wrote: > At https://github.com/boostorg/asio/pull/283 <https://github.com/boostorg/asio/pull/283> I’ve attached a proof-of-concept which explores making ASIO secure by default. The C++ committee is discussing what secure-by-default networking would look like in the soon to be published papers P1860 and P1861. Since the C++ Networking TS is based on ASIO, this seems like a good place to try things out. Please don't. There are plenty of networking applications that do not use SSL. Use ssl::stream if you want secure-by-default.

1 0

Re: [boost] Requesting opinions on CECS (C/C++ Error Control) library for possible boost implementation.
by Bjorn Reese 11 Sep '19

11 Sep '19

On 9/8/19 3:17 PM, Terablade via Boost wrote: > I have also released the library on github:https://github.com/terablade2001/CECS This library is described as handling "textual informative error control" using severity levels, so the first question that comes to mind is how this differs from Boost.Log? PS: The standard as reserved all symbol names starting with an underscore followed by a capital letter.

2 1

[Random] Proposal: Faster RANLUX engines
by Christoph Conrads 10 Sep '19

10 Sep '19

Boost.Random and the C++11 standard library ship with a 24- and a 48-bit RANLUX pseudo-random number generator (PRNG). I propose to add 32- and 64-bit RANLUX PRNGs because they are at least 40% faster. Additionally, the 32-bit RANLUX PRNG can be implemented as follows: #include <boost/cstdint.hpp> #include <boost/random.hpp> namespace br = boost::random; typedef br::subtract_with_carry_engine<boost::uint32_t,32,3,17> ranlux32_base; typedef br::discard_block_engine<ranlux32_base, 389, 16> ranlux32; There is C++98 benchmark code at the end of this e-mail requiring only Boost and a C++ compiler. Below I will briefly discuss the theory behind RANLUX PRNGs, where the new generators are coming from, and why the 64-bit RANLUX PRNG requires (a few lines of) new code. Drawing from RANLUX PRNGs is a two-step process. In the first step a value is drawn from a "subtract-with-borrow" (SWB) generator implementing b-bit modular arithmetic [1]. Then, values are generously discarded yielding uniformly distributed values (uniform in a dynamical systems model) [2]. The RANLUX PRNGs using 24- and 48-bit arithmetic always gave me an itch so I looked into the motivation behind this. It turns out [3] that this restriction arose likely from a) computational limitations in the 1990s and b) Lüscher's interest in the generation of floating-point numbers (single-precision floating-point numbers have 24-bit significand). SWB PRNGs come in two flavors (Type I, Type II) and they make use of three parameters called base b, short lag s, and long lag r. Using modern prime factorization methods, one can quickly come up with the 32-bit PRNG above, a Type I SWB generator with b=2^32, r=17, and s=3. This one can be implemented as shown above. To generate 64-bit values, one should use a Type II SWB with b=2^64, r=62, and s=5 (all other 64-bit generators with b=2^64 and r < 100 will be awfully slow). What distinguishes the different types of SWBs is the recurrence for the computation of variates. For Type I it is x_n := (x_{n-s} - x_{n-r} + c_n) mod b, where c_n is a carry bit. For Type II it is x_n := (x_{n-r} - x_{n-s} + c_n) mod b. (Observe the order of long lang and short lag in these formulas.) Type II SWBs are not difficult to implement but it requires either a modification of `subtract_with_carry_engine` or a new class. Let me know what you think about this proposal. Christoph Conrads [1] G. Marsaglia, A. Zaman: "A New Class of Random Number Generators". 1991. URL: https://www.jstor.org/stable/2959748 [2] Martin Lüscher: "A Portable High-Quality Random Number Generator for Lattice Field Theory Simulations". 1994. URL: https://arxiv.org/abs/hep-lat/9309020 [3] Christoph Conrads: "Faster RANLUX Pseudo-Random Number Generators". 2019. URL: https://christoph-conrads.name/faster-ranlux-pseudo-random-number-generators // Build with: // c++ -Wextra -Wall -std=c++98 -pedantic benchmark.cpp -O3 \ // -march=native -DNDEBUG -lboost_chrono -lboost_system #include <boost/chrono.hpp> #include <boost/cstdint.hpp> #include <boost/random.hpp> #include <cassert> #include <cstdio> #include <limits> #include <string> namespace chrono = boost::chrono; typedef chrono::milliseconds milliseconds; typedef chrono::process_cpu_clock my_clock; namespace br = boost::random; typedef br::subtract_with_carry_engine<boost::uint32_t,32,3,17> ranlux32_base; typedef br::discard_block_engine<ranlux32_base, 389, 16> ranlux32; struct dummy_engine { typedef boost::uint32_t result_type; static result_type max() { return std::numeric_limits<result_type>::max(); } static result_type min() { return std::numeric_limits<result_type>::min(); } result_type operator() (); result_type state_; }; dummy_engine::result_type dummy_engine::operator() () { return state_++; } std::string get_name(const dummy_engine&) { return "dummy-prng"; } std::string get_name(const br::ranlux24&) { return "ranlux24"; } std::string get_name(const br::ranlux48&) { return "ranlux48"; } std::string get_name(const ranlux32&) { return "ranlux32";} template<typename Generator> typename Generator::result_type draw(Generator& gen) __attribute__((noinline)); template<typename Generator> typename Generator::result_type draw(Generator& gen) { return gen(); } template<typename Generator> void run(boost::uintmax_t num_draws) { assert(Generator::min() == 0); unsigned w = Generator::max() == std::numeric_limits<boost::uint64_t>::max()?8u: Generator::max() == (UINTMAX_C(1)<<48) - 1u ?6u: Generator::max() == std::numeric_limits<boost::uint32_t>::max()?4u: Generator::max() == (UINTMAX_C(1)<<24) - 1u ?3u: Generator::max() == std::numeric_limits<boost::uint16_t>::max()?2u: Generator::max() == std::numeric_limits<boost::uint8_t>::max() ?1u: 0u ; Generator gen; my_clock::time_point t_0 = my_clock::now(); for(uintmax_t i = 0; i < num_draws; ++i) draw(gen); my_clock::time_point t_1 = my_clock::now(); milliseconds t_ms = chrono::duration_cast<milliseconds>(t_1 - t_0); double bytes_per_sec = w * num_draws * 1000u/double(t_ms.count()); std::string name = get_name(gen); boost::uint16_t dummy = boost::uint16_t(gen()); std::printf( "%-26s | %10lu | %20.2e | %hu\n", name.c_str(), t_ms.count(), bytes_per_sec, dummy ); } int main() { boost::uintmax_t num_draws = UINTMAX_C(100000000); run<dummy_engine>(num_draws); run<br::ranlux24>(num_draws); run<ranlux32>(num_draws); run<br::ranlux48>(num_draws); }

1 0

Interest in circular span?
by Bjorn Reese 10 Sep '19

10 Sep '19

I am working on a circular queue library that contains a non-owning circular span, a fixed-sized circular array, and a dynamically resizable circular vector. Would you be interested in adding such a library to Boost? The design is inspired by Boost.CircularBuffer, std::span, and P0059R4 std::experimental::ring_span. The code can be found at: https://github.com/breese/trial.circular The documentation can be found at: https://github.com/breese/trial.circular/tree/develop/doc circular::span can be used to implement the P0059R4 ring_span, as shown in one of the example: https://github.com/breese/trial.circular/blob/develop/example/p0059/ring_sp… circular::span can also be used to implement most parts of boost::circular_buffer; all except insertions and erasure at arbitrary positions.

7 10

[Intrusive] Movable intrusive container elements?
by Phil Endecott 09 Sep '19

09 Sep '19

Dear Experts, Is it possible to make intrusive container elements movable? Here's the scenario. Say I have struct Thing { int id, string name }; and I want a container of those indexed by both the id and the name. Using Boost.Intrusive I can add two hooks to the struct and have two intrusive::sets, one using id as the key and the other using name. All good. But say my ids are a contiguous range of integers starting at zero. It would be much better to store the Things in a vector (or similar), indexed by the id, and use Intrusive only for the name index. Or if my ids are not contiguous, I might still prefer to keep the things in a vector sorted by id and do id lookup by binary search (i.e. a flat_set). In both cases, the issue is that when the vector expands or is sorted the elements are moved, and this will invalidate the pointers used for the name index. Is is possible to fix this using move constructors and move assignment for the hooks? I.e. those operations could adjust the pointers pointing to the element's old location to point to its new location. (This has some similarities to how auto-unlink hooks already fix pointers to remove the being-deleted item.) Maybe there is some complication that makes this impossible. Or maybe this is already possible?? Any thoughts anyone? Regards, Phil.

2 2

Requesting opinions on CECS (C/C++ Error Control) library for possible boost implementation.
by Terablade 08 Sep '19

08 Sep '19

Hi all. Recently I focused on completing and releasing a public a C/C++ library for C/C++ Error Control System. I've exposed the library to public via two articles in Linked In, and especially in the "C++ Developers Groups" were I got some positive feedback (a few comments and likes). A "Senior Architect at Apple" left the following comment: "Man that’s error traceability for a lot of readability". This made me wonder if this library deserves to be exposed more to C/C++ developers, and led me to think of boost library. Personally I'm testing the library by integrating it in different projects, and I'm quite happy from the outcome. With very few code (increased readability) and a specific design approach for capturing and handling possible errors, it does provide a lot of customized error traceability - a feature which for me is quite important on complex projects and especially when multiple libraries mix up and need integrated error tracking through all of them. Reading the boost guidelines I joined this mailing list to request review and opinions.As my free time is a a bit limited to convert and test the library to be supported by boost, I'd like some comments and review first.Do you believe that CECS could be a useful util for Boost? Should I go for it? The two articles in that group (requires membership) is at:https://www.linkedin.com/feed/update/urn:li:activity:6568218380594098176… articles are also in my profile:https://www.linkedin.com/pulse/cecs-cc-error-control-system-vasilei… I have also released the library on github:https://github.com/terablade2001/CECS I'd like to note that the library has been favored till now by 7 accounts in github (8 including me) which, for me, is also a positive feedback. Thanks for your time,V. Pothos

1 0

[GSOC19] Congrats to all students and mentors
by Damian Vicino 06 Sep '19

06 Sep '19

Hi, GSOC finished for 2019. We had 11 students this year and all of them survived the summer and contributed a lot of good stuff. Hopefully, most of it will be merged in the next few weeks. Thanks to all students and mentors, and to Boost community for supporting the program. Special thanks to David Bellot that worked as org admin and dealed with the logistics in addition to mentor. Cheers, Damian

2 1

[bimap] Maintaining library
by Edward Diener 04 Sep '19

04 Sep '19

Could someone please take a look at bimap in order to maintain the library. I have had a simple PR since last December, simply to remove executable permissions from some files, which has been ignored and no one appears to be maintaining the library.

1 0

boost::asio::deadline_timer and boost::asio::io_service
by JH 02 Sep '19

02 Sep '19

Hi, I use a single thread to run 3 classes using boost::asio::deadline_timer, the timers are managed by boost::asio::io_service. I deliberately use a single thread to avoid mutex, I believe those 3 timers are called exclusively by boost::asio::io_service in a single thread, there won't be race condition to share the objects among them, is it correct? Thank you. Kind regards, - jupiter

2 7

Re: [boost] A solution to return dynamic strings without heap allocation. Any interest?
by Bjorn Reese 01 Sep '19

01 Sep '19

On 8/29/19 3:24 PM, Roberto Hinz via Boost wrote: > auto result = csw.finish(); > if (result.truncated) { > // ... I suggest that you change the return type of finish() to contain the number of element written instead of the truncated boolean. This would make outbuf extensible to binary data as well where you cannot rely on a terminating zero to tell you how much data has been written. The return type could also have begin()/end() member functions, which makes it directly usable with STL algorithms. In that case it would also make sense to have data()/size().

2 3

Re: [boost] [Boost-users] License Issue with boost_intrusive
by Michael Caisse 27 Aug '19

27 Aug '19

Copying to dev ML. On 8/22/19 12:05, Gerald Wiltse via Boost-users wrote: > During an annual third-party audit of our source code, boost intrusive > was flagged as containing unlicensed code. Specifically, there are > several pieces of code in this file which are explicitly attributed to > external parties on external websites, which still exist and show no > license. > > https://github.com/boostorg/intrusive/blob/develop/include/boost/intrusive/… > > https://github.com/boostorg/intrusive/blob/develop/include/boost/intrusive/… > > > Original sources: > http://stackoverflow.com/questions/11376288/fast-computing-of-log2-for-64-b… > http://www.flipcode.com/archives/Fast_log_Function.shtml > > I don't claim to be a license expert. I've read a lot over the years, > but this is the first time that I've actually been between an attorney > and a codebase having to figure out practical implications of a scenario > like this. > > I first want to make sure that Boost committee is aware of this situation. > > Second, I would like to know what the official conclusion would be from > the Boost Committee about the license implications in cases like these. > Maybe it has come up before and is well established. On the surface, the > implications seems ambiguous to me when: DEVELOPER_A takes unlicensed > code off the internet, prefixes it with a comment that says "Thanks to > DEVELOPER_B ", then prefixes the whole file with a file-level copyright > notice that says "COPYRIGHT DEVELOPER_A", and then says it's > distributed under BSL-1.0 license, and then the boost team > re-distributes the source code. > > Internally at my company, there was little discussion about it. There > is no room for ambiguity, so the directive from management was to delete > the file from our SCM system completely and ensure it never is included > in our products. VERY fortunately, deleting it doesn't seem to have > broken our builds. In future cases like this, that's really not what we > want to be doing with your OSS libraries for obvious reasons. So, I'd > like to know if there's any chance this situation changes in a future > version of Boost (I.E., the code be removed/re-written with clean-room > approach, etc). > > Regards, > Jerry > > Gerald R. Wiltse > jerrywiltse(a)gmail.com <mailto:jerrywiltse@gmail.com> > > > _______________________________________________ > Boost-users mailing list > Boost-users(a)lists.boost.org > https://lists.boost.org/mailman/listinfo.cgi/boost-users >

8 8

Set deadline_timer expired_at realtime clock 0 minute and repeat
by JH 27 Aug '19

27 Aug '19

Hi, How can I set deadline_timer expired at real clock absolute time at 0 minute, then repeat every minute? So it should expired at: 13:40:00, 13:41:00, 13:42:00 and so on? Thank you. Kind regards, - jupiter

2 7

Becoming the new maintainer of Boost.Functional/Factory (value_factory and factory)
by Glen Fernandes 26 Aug '19

26 Aug '19

Tobias (see forwarded e-mail below) has kindly agreed to allow me to become the maintainer of boost::factory and boost::value_factory (in Boost.Functional). I'll be revising the implementation of both for the next Boost (1.72) release, to: * Support r-value arguments * Use variadic templates to support arbitrary arguments * Support allocators that are final * Support allocators that use non-raw (fancy) pointers * Support BOOST_NO_EXCEPTIONS environments * Improve compilation times (drop Boost.Preprocessor usage) I'll add myself to the appropriate repository teams and update the library information accordingly. Glen ---------- Forwarded message --------- From: T.Schwinger <tschwinger(a)isonews2.com> Date: Mon, Aug 26, 2019 at 5:38 AM Subject: Re: Maintaining Boost.Functional value_factory and factory To: Glen Fernandes <glen.fernandes(a)gmail.com> Hi Glen, On 25.08.19 19:46, Glen Fernandes wrote: > I'd like to assume maintenance of factory/value_factory in > Boost.Functional. Among other things, update them to support r-value > references (when the compiler supports it), as well as simplify the > implementation for when the compiler supports variadic templates. > Along with other work going forward. [...] > If you have no objections let me know. No objections - to the contrary: I'm grateful. Thank you for taking care of it! Best, Toby

1 0

Compliance with Boost copyright and license guidelines
by pbristow＠hetp.u-net.com 23 Aug '19

23 Aug '19

Prompted by some recent discussion of Boost license and copyright info by the Debian package team, I have recently been checking on the Boost.Multiprecision library and run the Boost inspect program https://www.boost.org/doc/libs/1_70_0/tools/inspect/ (originally written by Beman Dawes in 2003 and revised several times since). I’ve made some minor cosmetic changes to the program and the rather sparse documentation to make it easier to use by library authors and give a bit more info. It checks on compliance with https://www.boost.org/development/requirements.html. It’s use has been a little neglected recently but I conclude that we are not doing well enough in providing the proof of copyright and license that we promise. The results of my run of inspect on the boost/lib folder using develop branch are not pretty Problem counts: 1790 files missing Boost license info or having wrong reference text 1682 files missing copyright notice (but not I suspect quite as bad as they look – some items probably do not need copyright and license). Now that the 1.71 release is out bar a little shouting, I wonder if we should focus on improving compliance for the next release? I’d like to propose 1 A boost/tools/inspect/develop branch to refine the inspect program a little and improve the documentation (I have done something on this already for my education and use). 2 Discussion of the bad results (zip attached) to try to find why there are so many reports and to decide what to do. 3 Encourage all authors to run inspect on their library locally and try to remedy the items missing. 4 I suspect that many libraries will have items missing but the authors are also missing. So someone from the community maintenance team will need to take over and make some decisions on what to do. Often just providing a copyright claim from the obvious author and Boost license will suffice? 5 Try to improve the compliance with other guidelines. For example. there are many libraries that are failing to prevent with min and max macros for what of a couple of brackets. Usually (std::numeric_limits<>::max)(). All these will trip up Windows users in a puzzling way. Please can we just fix these? Views? Paul PS My halo is shining brightly 😉 Boost.Multiprecision has a problem count of zero 😊 (and I’m working on Boost.Math) Boost Inspection Report Inspect version no 3.1.15 Run Date: 08:44:19 UTC, Saturday 17 August 2019 Distributed under the Boost Software License, Version 1.0. (See accompanying file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt) Copyright Boost 2019 boost-no-inspect Inspection from path "libs" including subfolders. Totals: 52355 files scanned 4351 directories scanned (including root) 3472 problems reported Problem counts: 1790 files missing Boost license info or having wrong reference text 1682 files missing copyright notice Worst Offenders: outcome 940 metaparse 556 polygon 228 python 194 beast 192 Summary: algorithm (4) array (2) asio (12) … Paul A. Bristow Prizet Farmhouse Kendal, Cumbria LA8 8AB UK

14 34

Re: [boost] crc.hpp:569 msvc warning C4800
by Kenneth Porter 22 Aug '19

22 Aug '19

This appears not to have made it into 1.71.0. I had to edit crc.hpp:569 to silence the warning. --On Saturday, April 13, 2019 1:35 PM -0700 Kenneth Porter via Boost <boost(a)lists.boost.org> wrote: > <https://github.com/boostorg/crc/pull/2> > > Visual Studio 2010-2019 issue this warning for crc.hpp line 569: > > warning C4800: "'int' : forcing value to bool 'true' or 'false' > (performance warning) > > bool const quotient = remainder & high_bit_mask; > > Replace with: > > bool const quotient = (remainder & high_bit_mask) != 0;

1 0

boost high precision timer and boost io_service
by JH 22 Aug '19

22 Aug '19

Hi, I am currently running boost::asio::deadline_timer to transmit data every minute, the requirement needs the interval accurate, if the first data sending at 10:00:05, the next needs be 10:01:05 and so on, but my data sending time shifting every 2 seconds I need to fix it. I am not sure if the boost high precision timer can fix it, it seems to me like a realtime requirement. My whole application is based on boost::asio::io_service in a single thread on Linux embedded system, can the boost high precision timer fix the problem or will the the boost multithreading fix the problem or there might be no chance to match the requirement simply because Linux is not a realtime OS? Appreciate your insight advice. Thank you. Kind regards, - jupiter

4 5

[release] Boost 1.71.0
by Michael Caisse 21 Aug '19

21 Aug '19

Release 1.71.0 of the Boost C++ Libraries is now available. These open-source libraries work well with the C++ Standard Library, and are usable across a broad spectrum of applications. The Boost license encourages both commercial and non-commercial use. This release contains 1 new library (Variant2) and numerous enhancements and bug fixes for existing libraries. For details, including download links, see <http://www.boost.org/users/news/version_1.71.0> You can also download directly from: <https://dl.bintray.com/boostorg/release/1.71.0/> To install this release on your system, see <http://www.boost.org/doc/libs/release/more/getting_started/index.html> Thanks to everyone who participated in this release. Thanks, -- The Boost Release Team Marshall Clow, Michael Caisse

3 2

[release] Boost 1.71.0 Release Candidate 2 available
by Michael Caisse 20 Aug '19

20 Aug '19

The release candidates for the 1.71.0 release are now available at: <https://dl.bintray.com/boostorg/release/1.71.0/source/> The SHA256 checksums are as follows: 1b3949ffddf56129141032542523920034f2e69775fb9332a52ba37c548dbf35 boost_1_71_0_rc2.7z d73a8da01e8bf8c7eda40b4c84915071a8c8a0df4a6734537ddde4a8580524ee boost_1_71_0_rc2.tar.bz2 96b34f7468f26a141f6020efb813f1a2f3dfb9797ecf76a7d7cbd843cc95f5bd boost_1_71_0_rc2.tar.gz 85a94ac71c28e59cf97a96714e4c58a18550c227ac8b0388c260d6c717e47a69 boost_1_71_0_rc2.zip As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. -- The Boost Release Managers

5 6

Potential project: Resolving boost::chrono conflicts with std::chrono
by Howard Hinnant 20 Aug '19

20 Aug '19

Possible project for someone looking for a boost project to contribute to: boost::chrono was created soon after std::chrono was proposed and served people well for experimenting with this library prior to migrating to C++11. Fast forward 8 years: Now we have two competing chrono libraries: boost::chrono and std::chrono. And it is not rare for people to use non-chrono boost libraries, which in turn use boost::chrono, and for those same people to use std::chrono. Invariably what happens is they get horribly complicated compile-time errors which boil down to: boost::chrono does not interoperate with std::chrono. And these errors often come from deep within libraries which people are simply trying to use. The pitch: boost::chrono, and other boost::libs needs to defer to std::chrono for C++11 and later. This would make boost significantly easier to use. This is likely a multi-project effort, and I don’t even have a concrete strategy in mind. This is a problem in search of a solution, not vice-versa. And I often hear of enthusiastic people who want to jump in and lend a helping hand. I think this would be a terrific area to point such talent towards. Howard

13 27

Re: [boost] [multiprecision] Proposal for enhancing cpp_int multiplication
by kotika98 19 Aug '19

19 Aug '19

-------- Original message --------From: Ankur Dua via Boost <boost(a)lists.boost.org> Date: 17/08/2019 18:17 (GMT+08:00) To: boost(a)lists.boost.org Cc: Ankur Dua <ankurdua15(a)gmail.com> Subject: [boost] [multiprecision] Proposal for enhancing cpp_int multiplication We have benchmarked cpp_int vs mpz_int (GNU GMP backend) and we found thataround 10^6 bits, cpp_int is tremendously slow (almost 1200x times). Wehave also prepared a document containing the benchmarks [1] alongwith thedetails about the idea and the project.References,[1] Introductory document -https://docs.google.com/document/d/1cclKlbBWDVmY9zKSdn0ga2yTcCkyD9ZiUUdCZZkVyaI/edit?usp=sharing__________________________________________________________________________________ Nice idea for a project! In GMP, things are organized around thresholds for switching to the next algorithm. It is impossible to predict theoretically what that threshold will be or how it will evolve in the future with changes to computer architecture.1. However, for very large input, FFT dominates over Karatsuba and Toom. The threshold is around 4000 limbs which is roughly 250,000 bits. BTW, it is below your test limits.2. For most sizes in between 0 and 4000 limbs, Toom-8 dominates, not Karatsuba.3. Karatsuba and Toom are anyway both special cases of FFT.https://gmplib.org/manual/Multiplication-Algorithms.html#Multiplication…

1 0

I'm getting some neat results by changing graph testing over to using pre-compiled headers
by jrmarsha 18 Aug '19

18 Aug '19

Shout out to Rene Rivera for helping me get this stuff together. I'm getting some useful results out of changing to using pre-compiled headers. There isn't the speed-up I expected, but it has actually turned out useful for finding out incorrect header inclusion patterns and will certainly be making the code more reliable. This is something that we ought to consider trying more broadly in the project.

1 0

[multiprecision] Proposal for enhancing cpp_int multiplication
by Ankur Dua 18 Aug '19

18 Aug '19

Hi Boost community, We are team of two students (Senior Undergraduate) from IIT(ISM) Dhanbad — Madhur Chauhan & Ankur Dua. We want to bring your attention towards the the potential project that we wish to complete — Enhancing multplication of cpp_int by using Karatsuba as the multiplication algorithm. We have benchmarked cpp_int vs mpz_int (GNU GMP backend) and we found that around 10^6 bits, cpp_int is tremendously slow (almost 1200x times). We have also prepared a document containing the benchmarks [1] alongwith the details about the idea and the project. We are awaiting response from the community after which we will prepare a formal proposal containing the details of approach and possible implementations with documentation and test code changes. Thanks & Regards Madhur Chauhan & Ankur Dua madhur4127(a)gmail.com ankurdua15(a)gmail.com References, [1] Introductory document - https://docs.google.com/document/d/1cclKlbBWDVmY9zKSdn0ga2yTcCkyD9ZiUUdCZZk…

2 1

Interest in updated, standalone iterator_facade library?
by Zach Laine 18 Aug '19

18 Aug '19

I write a lot of iterators, and I'm getting sick of doing it by hand. I can't use Boost.Iterator's iterator_facade in library code, since it knows nothing about constexpr and noexcept. The design of Boost.Iterator's iterator_facade does not lend itself very well to being modified in a direction that is standardization-friendly (reasons why are outlined in the online docs). So, here is one take on this problem: GitHub: https://github.com/tzlaine/iterator_facade Online Docs: https://tzlaine.github.io/iterator_facade For those unfamiliar with the problem, iterators are very simple, at the highest level of abstraction. An iterator's implementation does not reflect this -- it is highly repetitive and easy to get subtly wrong. This library fixes that. The library is forward-looking, since I intend to write WG21 papers to standardize iterator_facade; there is good support for upcoming C++20 library features. In particular, the iterators created with iterator_facade model the C++20 iterator concepts, and therefore do not necessarily match the requirements of the C++17-and-earlier requirement tables. I have not found this to affect the usability of iterator-facade-based iterators with pre-C++20 code. Something to note: there was a recent-ish attempt to stanrdize iterator_facade, which is now abandoned, P0186 (http://wg21.link/P0186) This was very different from what I'm proposing for Boost. I talked to Eric Niebler about this, and he favors a return to the CRTP-based approach of my lib and the original Boost.Iterator iterator_facade library. Zach

9 20

Interest in STL interface templates for iterators, views, and containers? (Was: Interest in updated, standalone iterator_facade library?)
by Zach Laine 17 Aug '19

17 Aug '19

On Wed, Aug 14, 2019 at 10:44 AM Zach Laine <whatwasthataddress(a)gmail.com> wrote: > On Wed, Aug 14, 2019 at 4:44 AM Hans Dembinski <hans.dembinski(a)gmail.com> > wrote: > > [snip] > > >> > Since iterator_interface is a lot more like Boost.Iterator's >> iterator_adaptor than my previous iterator_facade was (and I'll look into >> that), it may be possible to make one template that does everything, but I >> will not include two separate templates. >> >> If you could merge the two that would be even better, but I am not sure >> you can. >> > > I can, and I did last night. You can see an example here (not that this > is not the master branch): > > > https://github.com/tzlaine/iterator_facade/blob/interface_alternative/examp… > > When I get MSVC fixed, I'll merge all this to master. > This is now done. The focus of the library is now a bit different. All the iterator bits are still there, but now iterator_facade is called iterator_interface, and has facilities for acting more like an iterator_facade and more like an iterator_adaptor. One of the new things is an implementation of C++20's view_interface. Give it a range or view, even one with only begin() and end(), and it gives you all the view-type API that can be supported from begin() and end(), based on the iterator types and categories. The other new thing is container_interface. It is analogous to view_interface, but instead of supporting definition of new view types, it supports the definition of new containers. It has support for all the operations in the sequence container and reversible container requirements in the standard. In the example in the docs, I was able to write a static_vector, for which container_interface provided 38(!) of the member functions. Finally, the library's name has changed to reflect all this. You can now get the code here: https://github.com/tzlaine/stl_interfaces and see the online docs here: https://tzlaine.github.io/stl_interfaces/doc/html/index.html Zach

1 0

Beast/Context build failures
by Vinnie Falco 15 Aug '19

15 Aug '19

I'm seeing new build failures related to Boost.Context, could this be the recent changes there? <https://travis-ci.org/boostorg/beast/jobs/571029999> Thanks

3 2

Boost.Predef still broken in 1.71 RC 1
by Niall Douglas 13 Aug '19

13 Aug '19

As reported earlier, Boost.Build's predefined macro testing support is still misdetecting in RC 1: Using Boost 1.71 RC 1 with VS2019: b2 libs/outcome/test Performing configuration checks - default address-model : 32-bit - default architecture : x86 - !BOOST_COMP_GNUC : no - BOOST_COMP_GNUC >= 6.0 : no - !BOOST_COMP_CLANG : no - BOOST_COMP_CLANG >= 4.0 : no - Boost.Config Feature Check: cxx14_variable_templates : yes - Boost.Config Feature Check: cxx14_constexpr : yes - !BOOST_COMP_GNUC : no - BOOST_COMP_GNUC >= 6.0 : no - !BOOST_COMP_CLANG : no - BOOST_COMP_CLANG >= 4.0 : no - Boost.Config Feature Check: cxx14_variable_templates : yes - Boost.Config Feature Check: cxx14_constexpr : yes ...found 1 target... Using Boost 1.71 RC 1 with GCC 7.3 on Linux: g++ --version g++ (Ubuntu 7.3.0-27ubuntu1~18.04) 7.3.0 Copyright (C) 2017 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. ./b2 libs/outcome/test Performing configuration checks - !BOOST_COMP_GNUC : no - BOOST_COMP_GNUC >= 6.0 : no - !BOOST_COMP_CLANG : no - BOOST_COMP_CLANG >= 4.0 : no - default address-model : 64-bit - default architecture : x86 - Boost.Config Feature Check: cxx14_variable_templates : yes - Boost.Config Feature Check: cxx14_constexpr : yes - !BOOST_COMP_GNUC : no - BOOST_COMP_GNUC >= 6.0 : no - !BOOST_COMP_CLANG : no - BOOST_COMP_CLANG >= 4.0 : no - Boost.Config Feature Check: cxx14_variable_templates : yes - Boost.Config Feature Check: cxx14_constexpr : yes ...found 1 target...

2 2

Re: [boost] Potential project: Resolving boost::chrono conflicts with std::chrono
by Glen Fernandes 12 Aug '19

12 Aug '19

Howard wrote: > There is truth to this rationale, but I also wanted to point out that it is not absolute. > [snip] > Not providing a boost implementation does not preclude enhancing a std::lib. > But it can certainly help in changing existing signatures, Indeed. Of course, someone who wants to prototype some breaking change to a library like chrono or smart_ptr can do it without Boost. For example, we could have reimplemented ALL of shared_ptr in github/JohnDoe/smart_ptr to prototype the extensions added in C++17 and C++20. But here were some advantages of not doing so, and using Boost instead: - NOT reimplementing ALL of shared_ptr - Access to a bigger user base than github/JohnDoe/smart_ptr would have e.g. * Boost being white-listed as approved open source in many organizations * New versions of Boost included in many Linux distribution software repositories * etc. So it was an easy choice to go through Boost because boost::shared_ptr wasn't just an alias for std::shared_ptr, and had a quality, well tested, implementation. Still, even with Smart_Ptr, you have the option to convince the maintainer of Smart_Ptr to make boost::shared_ptr just an alias for [C++17] std::shared_ptr, and make boost::allocate_shared just defer to [C++20] std::allocate_shared. It would make users unhappy. There are already users of boost::local_shared_ptr which depends on the implementation of boost::shared_ptr, that would continue using Boost even after C++20 features are implemented everywhere. Glen

1 0

Re: [boost] Potential project: Resolving boost::chrono conflicts with std::chrono
by Glen Fernandes 12 Aug '19

12 Aug '19

There is value in Boost.Chrono providing a chrono implementation (i.e. not just aliasing std::chrono), to provide a library where future enhancements to chrono could eventually make it into C++23, or beyond. i.e. Similar to how we enhanced std::shared_ptr, std::make_shared, std::allocate_shared past the C++11 versions, and these enhancements made it into C++17 and C++20. Other Boost libraries can switch today to use std::chrono instead of boost::chrono (conditionally or unconditionally) if they want. As always: - It is, up to the maintainer of Boost.Chrono whether he wants to use std::chrono internally, and make boost::chrono compatible with std::chrono. - It is up to the maintainers of other Boost libraries whether they want to use std::chrono instead of boost::chrono Both of these can be achieved independently, purely by convincing the respective Boost maintainers. Maybe they can drop C++11 support and only support std::chrono. Maybe they might want to use boost::chrono in C++03 mode and std::chrono in C++11 mode. The discussion on the Boost mailing list (each time it gets repeated, for Boost.X library for which there is a C++ standard library equivalent) while still interesting, probably still won't achieve anything. i.e. No amount of discussion here is going to result in any action to command any maintainer to do something. Glen

2 1

[release] Boost 1.71.0 Release Candidate 1
by Michael Caisse 11 Aug '19

11 Aug '19

The first release candidates for the 1.71.0 release are now available at: <https://dl.bintray.com/boostorg/release/1.71.0.rc1/source/> The SHA256 checksums are as follows: 7fadf835372325d7a287b1c45310c4f96811eb1e4809933a5a400d529df38d0e boost_1_71_0_rc1.7z c857a86fb1223c7a256414151e2d1dcd4691b56197aa1329e087e92502191434 boost_1_71_0_rc1.tar.bz2 07c07cad079fed3f0175cbd7097740a333c2cdc6c899ac433dea87d1224d726d boost_1_71_0_rc1.tar.gz bc1674ba3e11635fc2effbddc2ed69aecaced3901f81a6a2aae7b77f34e4cf76 boost_1_71_0_rc1.zip As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy.

5 7

[asio][coroutine] Intentional synchronization of a single coroutine
by Jared McIntyre 10 Aug '19

10 Aug '19

Within a large asynchronous project, I have a coroutine that needs to synchronize with other calls to that coroutine. This is a very simplified (and somewhat silly) example: #include <iostream> #include <cstdlib> #include <chrono> #include <boost/asio.hpp> #include <boost/asio/spawn.hpp> using namespace std; using namespace std::chrono; using namespace std::placeholders; using namespace boost::asio; using namespace std::chrono_literals; io_service ioservice; void bottleneck(seconds duration, yield_context yield) { steady_timer delay_timer(ioservice); delay_timer.expires_after(duration); delay_timer.async_wait(yield); std::cout << duration.count() << " "; } int main() { spawn(ioservice, std::bind(&bottleneck, 3s, _1)); spawn(ioservice, std::bind(&bottleneck, 2s, _1)); spawn(ioservice, std::bind(&bottleneck, 1s, _1)); spawn(ioservice, std::bind(&bottleneck, 0s, _1)); ioservice.run(); } The output is, of course, 0 1 2 3 because the timer effectively acts to re-order the calls. What I need is a way for each call to bottleneck() to fully complete before the next one starts, and each call occurs in the order they were called. This would make the output 3 2 1 0. I also want to allow other asynchronous routines on the io_service to run when the coroutine is yielding (so no cheating and turning the delay timer into a sleep). I've tried to think through something like the following. But I have no idea how to make it work. yield_context_queue bottleneck_queue; void bottleneck(seconds duration, yield_context yield) { bool yield_time = !bottleneck_queue.empty() bottleneck_queue.push_back(yield); if( yield_time ) { yield_back; } steady_timer delay_timer(ioservice); delay_timer.expires_after(duration); delay_timer.async_wait(yield); std::cout << duration.count() << " "; bottleneck_queue.pop(); if( false == bottleneck_queue.empty() ) { ioservice.post(bottleneck_queue.peak()); } }

3 2

Re: [boost] [asio][coroutine] Intentional synchronization of a single coroutine
by Bjorn Reese 10 Aug '19

10 Aug '19

On 8/9/19 9:12 PM, Jared McIntyre via Boost wrote: > The output is, of course, 0 1 2 3 because the timer effectively acts to > re-order the calls. What I need is a way for each call to bottleneck() to > fully complete before the next one starts, and each call occurs in the > order they were called. This would make the output 3 2 1 0. I also want to > allow other asynchronous routines on the io_service to run when the > coroutine is yielding (so no cheating and turning the delay timer into a > sleep). This sounds like a job for Boost.Fiber and its Boost.Asio integration: https://www.boost.org/libs/fiber/doc/html/fiber/callbacks/then_there_s____b…

2 1

[release] master branch closes soon - check build status
by Michael Caisse 09 Aug '19

09 Aug '19

The master branch will be closing soon (in about 30-hours). Please check the build status of your library. <https://www.boost.org/development/tests/master/developer/summary.html> - Your Friendly Boost Release Team

4 6

[release] 1.71.0 closed for Beta
by Michael Caisse 09 Aug '19

09 Aug '19

The master branch is now closed for all changes except by permission for the Beta release. Also, remember to add your libraries' changes to the release notes at: <https://github.com/boostorg/website/blob/master/feed/history/boost_1_71_0.q…> Thanks, -- The Boost Release Team

1 0

Re: [boost] Potential project: Resolving boost::chrono conflicts with std::chrono
by Bjorn Reese 09 Aug '19

09 Aug '19

On 8/9/19 3:01 AM, Howard Hinnant via Boost wrote: > The pitch: boost::chrono, and other boost::libs needs to defer to std::chrono for C++11 and later. This would make This should be done with great care. Boost.Asio does exactly this for its timer classes -- use boost::chrono if compiled pre-C++11 and otherwise use std::chrono. As implemented, this is a pain from the users perspective, because the user has to pass a type-strong expiration parameter which can be either, say, std::chrono::seconds or boost::chrono::seconds. This means, that your code that works perfectly suddenly yields compilation errors when your users change the compiler flags. boost::asio::steady_timer timer; timer.expires_from_now(boost::chrono::seconds(5)); // Fails post C++03 The Boost.Asio way is to import all chrono symbols into its own namespace: boost::asio::steady_timer timer; timer.expires_from_now(boost::asio::chrono::seconds(5)); // Okay Another solution is to use the timer template classes, e.g. basic_waitable_timer instead of steady_timer, so the user can work around the problem by selecting whether to use std::chrono or boost::chrono: boost::asio::basic_waitable_timer<boost::chrono::steady_clock> timer; timer.expires_from_now(boost::chrono::seconds(5)); // Okay PS: I am not arguing for or against the project, nor am I recommending any particular solution. I am just sharing some experience.

2 1

Result of out_ptr review.
by Zach Laine 07 Aug '19

07 Aug '19

I've compiled the results of the reviews of out_ptr during its recent review. Unfortunately, out_ptr is NOT ACCEPTED, though many of the reviewers indicated interest in seeing it come back in some future form. I counted these formal reviews: Andrey Semashev: reject Louis Dionne: accept David Sankel: reject Phil Endecott: reject Glen Fernandes: reject Gavin Lambert: reject Thanks to all of the above reviewers, and to all those who contributed to the ongoing discussions surrounding out_ptr, even if they did not have time for a full review. Points against out_ptr raised during the review: - Many reviewers indicated their puzzlement that this library was proposed at all, since they had never seen enough calls to C APIs in their own code to motivate the need for out_ptr. - Some reviewers who did find the motivating cases of the library compelling, still said that they would prefer to write wrappers instead of using something like out_ptr. - Multiple reviewers want the library to provide error-reporting help (it currently does not). In particular, for c_func(out_ptr(p)), there was a concern about whether p is assigned a value, when c_func() returns a failure-status. - There was concern from several reviewers about the fact that out_ptr's types' dtors may throw, though this is only limited to the use of out_ptr with shared_ptr and similar smart pointers. In particular, non-unique_ptr uses will never throw in out_ptr's types' dtors, unless the user provides a throwing deleter. - Multiple reviewers disagreed with the use of template specialization as a customization mechanism. - There was widespread concern about the use of potentially UB-invoking tricks to get max performance out of the implementation. - Many reviewers wanted a more typical Boost tutorial introduction in the documentation. Now please permit me a digression. The library attempts to take a call that looks like this (simplest call possible): // CASE 0 foo * new_foo; TODO if (!create_foo(&new_foo)) { // etc. ... } And turn it into something as close as possible to this: // CASE 1 std::unique_ptr<foo> new_foo; if (!create_foo(new_foo)) { // etc. ... } out_ptr does a great job of this lexically: // CASE 2 std::unique_ptr<foo> new_foo; if (!create_foo(out_ptr(new_foo))) { // etc. ... } If you have not written thousands of lines of code that look like case 0, stop for a second and consider what it would be like to drop those thousands of raw pointers into your code, and how much you would like to replace them all with unique_ptrs. Now consider what it would take you to write all the wrapping functions necessary to make those thousands of calls look like case 1. You may make tooling to generate the wrappers, and that's time consuming. Writing it by hand is even more so. out_ptr also has the nice property that using it as I have above with unique_ptr does not change the meaning of the code, except to ensure that new_foo is guaranteed to be treated in a RAII manner. Thus we get increased exception safety, memory leak mitigation, etc. -- y'know, all that RAII stuff. If out_ptr is implemented well, case 2 should produce nearly identical object code to case 0, except that case 2 handles calling new_foo's dtor at the right time. Note that because of this, you have the same relationship to the C API in all three cases. That is, you need to check for the success value returned from create_foo(), and you need to know what create_foo()'s contract is in the face of errors -- did it write to new_foo or not? out_ptr is how you get from raw pointers to RAII ones, not how you solve all programming problems related to calling functions. Hopefully that motivates the use case for out_ptr, even if you don't need it in your own code. Hopefully that also allays concerns that out_ptr is not doing enough -- doing more is outside the library's scope. Now, on to exceptions in out_ptr's types' dtors. I heard a lot of discussion about this during the review. To me, concerns about what happens when an out_ptr or an inout_ptr throws in its dtor misses the point entirely, because it is concerned with fixing corner cases we should not even care to support. Instead of worrying about the semantics of exceptions in those kinds of situations, we should instead be asking why we want to support user code like this: ... } catch { create_foo(in_out_ptr(my_shared_ptr_to_a_foo)); ... } In other words, we don't really care about the dtor exceptions, unless: - there is an active exception already, and - we are also calling a C API to create a new object (a possible, but certainly atypical thing to do when handling an exception), and - we're catching this new object in a shared_ptr-like smart pointer that might throw on construction. Who writes code like that? Few people, perhaps none. It's not impossible to see code like that, but until there are well-motivated cases for this, maybe leave it for a later version of the library. In other words, the question should have been "Why support anything other than nothrow-constructible RAII types like unque_ptr?" Note that I find this argument compelling for the WG21-facing version of this work too. To summarize: I think the first four bullet points listed at the beginning of this post are, or could easily be made to be, irrelevant. So, that leaves some issues still outstanding: - figure out how to provide customization points (I'm actually fine with the current approach...), - eliminate the UB-dangerous code, or make it opt-in, - rework the tutorial portion of the docs, and - many assorted doc cleanups. That does not seem like an unreasonable amount of stuff to resolve in post-review acceptance readiness. I bring all this up because I do in fact hope that JeanHeyd brings this back for a future review, and I hope that my arguments here will convince some of you that this library is a useful thing to have around. I waited until now to say any of these things in an attempt to remain impartial during the review; I've been bothered by seeing previous review managers clearly represent a pro-acceptance position from the start. Thanks to JeanHeyd for his submission. A no-vote from this group is a tough thing, and I hope that the feedback he has received takes some of the sting out. Zach

6 5

[asio][coroutine] forbid_suspend blocks
by Vinícius dos Santos Oliveira 07 Aug '19

07 Aug '19

I've implemented a dumb linter using Python + clang API that allows you to mark certain blocks as “atomic in respect to coroutines” using C++11 attributes. Usage example follows: void f() { int yield; g(yield); [[bt::forbid_suspend]] { // Comment this call to make linter accept the code g(yield); t(); } } You can change bt::forbid_suspend to another identifier by tuning settings on the beginning of the script. The prefix forbid was inspired by Rust's linters[1] as you cannot disallow the linter from inside the forbid_suspend block. Some limitations follow: - A suspend point is identified by looking references to any id equals to yield in the last argument passed to function calls. It means that yield[ignored_ec] and alike will be correctly identified, but it needs to be named yield and it needs to be the last argument to the function call. - I haven't found a way to extract attributes related to COMPOUND_STMT nodes with clang API, so I manually look for token gaps and do a simple regex. It means you cannot use macros to [[bt::forbid_suspend]] as the macro won't be expanded. - You better call the script with '-x c++' and also ' -I/usr/lib/clang/5.0.1/include'. Like I've said in the beginning of the email, it's a *dumb* linter, which means it doesn't try to handle all cases. Therefore, I don't hope to do many changes to it or maintain it to work against newer releases of clang and I'm only uploading it to gist (not fullblow Github): < https://gist.github.com/vinipsmaker2/d930fbe5b7597432b021effe618da171>. It should also be easy to hack as it is very small. I'm releasing the linter under public domain. Enjoy. I have been using fibers in a daily basis on the last months of my job to solve networking problems on a gateway project. Some of the technologies I use are: - Boost.Asio and its spawn function. - A few custom synchronization primitives for the fibers (e.g. mutex, semaphore). - Eventually I'll have to write a custom spawn function that returns a joinable handle so I can kill the usage of a fiber::barrier in a few places. I've been using the linter for about a week already and looks fine. My use case are: - To prevent iterator invalidation in regions accessing shared variables. - To guarantee events order in algorithms that handle races (cannot yield while task YYY hasn't finished). The project I use it in is not an open source project, so I cannot talk much more about it. Also, I don't claim my solution is original. I wouldn't be surprised if the very same solution exists in the wild (please let me know if you know of a similar approach). This is not a new problem. It is know for some time. For instance, in P0171, Gor Nishanov noted this same problem: “In coroutines the suspend point is clearly marked with await, which tells the reader that something unusual happens in this function and allows the reader, for example, to confirm whether the lifetimes of the objects of interest align with the lifetime of the coroutine or not, whether some locks need to be acquired to protect some concurrently accessed data, and whether some locks need to be released before the execution reaches the suspend point.” — <http://open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0171r0.html>, 2015 However, the solution he presented was to manually examine whole blocks of code without help from the compiler. I argue that the solution he presented is as error-prone as manually looking for exit paths that don't free acquired resources in languages lacking RAII. And I've been spoiled too much by RAII. Furthermore, I take this comment of his with highly suspicious look: “Since we are on the subject of maintenance nightmares, we would like to offer a conjecture that the absence of the await in P0114 is a likely source of many maintenance nightmares. Without a syntactic marker to signal to the person reading the code that something funny is going on, it is impossible to tell whether the following code is correct or not” — http://open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0171r0.html If I had to give a vote to the proposal he was defending or Chris' proposal, I'd probably have chosen Chris'. [1] https://doc.rust-lang.org/reference/attributes.html# lint-check-attributes -- Vinícius dos Santos Oliveira https://vinipsmaker.github.io/

2 3

Making copyright holders easier to parse
by Giovanni Mascellani 07 Aug '19

07 Aug '19

Dear Boost developers, I am one of the Debian developers maintaining the Boost package in Debian. As part of packaging policy, we want the copyright status of each file in Debian packages to be documented, which includes at least the name of the copyright holders and the license of that particular file. As you can believe, this is rather complicated for Boost, since there are a lot of files with many copyright holders. I started to use the tool bcp, which among other things is able to collect such copyright information. My clone is available here[1]. However, bcp often is confused by the inconsistent style of how copyright holders are listed in different files, so it required a lot a manual fixing. For example, sometimes copyright years are written before the name, sometimes after, sometimes they're absent; names are sometimes separated by commas, sometimes by newlines, maybe even sometimes by nothing. Sometimes there are spelling mistakes or casing inconsistencies between names, or inconsistent institutions' names. Bcp has some complicated regular expression to overcame all these differences, but the result is brittle at its best. [1] https://salsa.debian.org/gio/boost-copyright Since I am doing this manual work anyway, I might as well update the Boost files so that their copyright headers are more consistent and easy to parse, and then I could submit you patches for having them fixed in the Boost official repositories. My question is: are you interested in this kind of patches? Of course I would still go through the ordinary patch submission procedure. I am just asking if this kind of patches would be well received or not. To better illustrate what I mean, let me consider a few examples (the chosen files are completely random); file libs/log/include/boost/log/exceptions.hpp currently has: > /* > * Copyright Andrey Semashev 2007 - 2015. > * Distributed under the Boost Software License, Version 1.0. > * (See accompanying file LICENSE_1_0.txt or copy at > * http://www.boost.org/LICENSE_1_0.txt) > */ I might change this to: > /* > * Copyright: 2007-2015 Andrey Semashev > * License: Boost Software License, Version 1.0 > * (See accompanying file LICENSE_1_0.txt or copy at > * http://www.boost.org/LICENSE_1_0.txt) > */ File libs/atomic/include/boost/atomic/fences.hpp has: > /* > * Distributed under the Boost Software License, Version 1.0. > * (See accompanying file LICENSE_1_0.txt or copy at > * http://www.boost.org/LICENSE_1_0.txt) > * > * Copyright (c) 2011 Helge Bahmann > * Copyright (c) 2013 Tim Blechmann > * Copyright (c) 2014 Andrey Semashev > */ I might change this to: > /* > * Copyright: 2011 Helge Bahmann > * Copyright: 2013 Tim Blechmann > * Copyright: 2014 Andrey Semashev > * License: Boost Software License, Version 1.0 > * (See accompanying file LICENSE_1_0.txt or copy at > * http://www.boost.org/LICENSE_1_0.txt) > */ I hope these examples illustrate my intention. I think that having more easily parsable copyright holders could be useful for Debian, for Boost and for Boost adopters which should properly care about the licensing of the libraries they use. Thank you, Giovanni. -- Giovanni Mascellani <g.mascellani(a)gmail.com> Postdoc researcher - Université Libre de Bruxelles

14 23

Expansion of Boost.Algorithm
by ATHARVA VEER 06 Aug '19

06 Aug '19

Greetings to all! I am planning to expand Boost.Algorithm by including more of general purpose algorithms to it. But since I don't know the future roadmap of the module, I cannot suggest changes right now. Also I have couple of algorithms in my mind that I think would be great if they are part of Boost but I don't know if Boost.Algorithm is the right place to include them. So I was wondering if anyone is willing to mentor me (as in review my work and suggest changes before merging) and we could discuss what we could include in Boost.Algorithm or appropriate module to include them. Brief about myself:- I am junior year college student and I have some experience working in open-source. I haven't contributed to Boost before but have used Boost libraries in day to day life. Thank you!!

1 0

Boost 1.71.0 Beta 1 and Quantlib 1.15
by Cg K 06 Aug '19

06 Aug '19

Gentlemen, Please read this message from Quantlib Dev board <https://sourceforge.net/p/quantlib/mailman/message/36730686/> In short, I was not able to compile Quantlib 1.15 with Boost 1_71_0_b1_rc1 I was able to compile it with 1.70 with some creativity. See here. <https://sourceforge.net/p/quantlib/mailman/message/36732240/> I have a complete list of the errors and messages. It is some 36 pages long and thought it best not to attach. If anyone wants it I will gladly send it to them privately. kaucher(a)gmail.com

4 5

[quickbook] build errors on master
by Raffi Enficiaud 05 Aug '19

05 Aug '19

Hi, I just merged develop to master and I have quickbook errors on my CI (see errors below). The exact same code compiled at 27. July 2019 at 13:47:19 CEST. Does anyone know something about this? Thanks, Raffi 05-Aug-2019 21:44:37 /Users/bambooagent/bamboo-agent-home/xml-data/build-dir/RS-BCB-DOX/library/tools/quickbook/src/include_paths.cpp:160:18: error: no member named 'directory_iterator' in namespace 'boost::filesystem'; did you mean 'directory_entry'? 05-Aug-2019 21:44:37 for (fs::directory_iterator dir_i(base_dir), dir_e; dir_i != dir_e; 05-Aug-2019 21:44:37 ~~~~^ 05-Aug-2019 21:44:37 ../../../boost/filesystem/path_traits.hpp:48:9: note: 'directory_entry' declared here 05-Aug-2019 21:44:37 class directory_entry; 05-Aug-2019 21:44:37 ^ 05-Aug-2019 21:44:37 /Users/bambooagent/bamboo-agent-home/xml-data/build-dir/RS-BCB-DOX/library/tools/quickbook/src/include_paths.cpp:160:61: error: use of undeclared identifier 'dir_i' 05-Aug-2019 21:44:37 for (fs::directory_iterator dir_i(base_dir), dir_e; dir_i != dir_e; 05-Aug-2019 21:44:37 ^ 05-Aug-2019 21:44:37 /Users/bambooagent/bamboo-agent-home/xml-data/build-dir/RS-BCB-DOX/library/tools/quickbook/src/include_paths.cpp:160:70: error: use of undeclared identifier 'dir_e' 05-Aug-2019 21:44:37 for (fs::directory_iterator dir_i(base_dir), dir_e; dir_i != dir_e; 05-Aug-2019 21:44:37 ^ 05-Aug-2019 21:44:37 /Users/bambooagent/bamboo-agent-home/xml-data/build-dir/RS-BCB-DOX/library/tools/quickbook/src/include_paths.cpp:161:16: error: use of undeclared identifier 'dir_i' 05-Aug-2019 21:44:37 ++dir_i) { 05-Aug-2019 21:44:37 ^ 05-Aug-2019 21:44:37 /Users/bambooagent/bamboo-agent-home/xml-data/build-dir/RS-BCB-DOX/library/tools/quickbook/src/include_paths.cpp:162:26: error: use of undeclared identifier 'dir_i' 05-Aug-2019 21:44:37 fs::path f = dir_i->path().filename(); 05-Aug-2019 21:44:37 ^ 05-Aug-2019 21:44:37 /Users/bambooagent/bamboo-agent-home/xml-data/build-dir/RS-BCB-DOX/library/tools/quickbook/src/include_paths.cpp:170:41: error: use of undeclared identifier 'dir_i' 05-Aug-2019 21:44:37 if (fs::is_regular_file(dir_i->status())) { 05-Aug-2019 21:44:37 ^ 05-Aug-2019 21:44:37 /Users/bambooagent/bamboo-agent-home/xml-data/build-dir/RS-BCB-DOX/library/tools/quickbook/src/include_paths.cpp:178:42: error: use of undeclared identifier 'dir_i' 05-Aug-2019 21:44:37 if (!fs::is_regular_file(dir_i->status())) { 05-Aug-2019 21:44:37 ^ 05-Aug-2019 21:44:37 7 errors generated.

2 1

[release] 1.71.0 post-beta merges
by Michael Caisse 05 Aug '19

05 Aug '19

The master branch is is now open for post-beta merges, but only as described in the Post-Beta Merge Policy. See <https://github.com/boostorg/boost/wiki/Releases%3A-Beta-Merge-Policy> Thanks, -- The Boost Release Team

7 17

Expansion of Boost.Algorithm
by ATHARVA VEER 04 Aug '19

04 Aug '19

Greetings to all! I am planning to expand Boost.Algorithm by including more of general purpose algorithms to it. But since I don't know the future roadmap of the module, I cannot suggest changes right now. Also I have couple of algorithms in my mind that I think would be great if they are part of Boost but I don't know if Boost.Algorithm is the right place to include them. So *I was wondering if anyone is willing to mentor me (as in review my work and suggest changes before merging) and we could discuss what we could include in Boost.Algorithm.* Brief about myself:- I am junior year college student and I have some experience working in open-source. I haven't contributed to Boost before but have used Boost libraries in day to day life.

1 0

Boost.Accumulators regression in Boost 1.71 beta 1 on VC++17/19
by Luigi Ballabio 04 Aug '19

04 Aug '19

Hello, the attached minimal file fails to compile on VC++17/19 when using Boost 1.71.0b1. It compiles successfully with Boost 1.70.0. I also attach the compiler errors. Cheers, Luigi

1 1

ASIO socket wired observation
by JH 03 Aug '19

03 Aug '19

Hi, I have been using asio tcp socket on desktop Ubuntu for years, but I have never seriously run interface connections in a LTE embedded system, here is what I have observed wired thing: - Client initialized TCP socket connection to remote server, the connection was established. - Client sent data to server via Internet every one minute, all good. - Somehow, the LTE connection dropped, there was no any network connection available, but the client keep sent messages, there was no error about the network connection, the message obvious could not go Internet, it accumulated in the RAM, the original each message size was 79 bytes, the size was accumulated became 52790 bytes, it kept going for ever until I terminate the client program. ....... Send message size: 52790 Send message size: 52869 Send message size: 52948 ..... Is it normal behavior of ASIO socket or what I did wrong here? Appreciate your insight tips to fix this problem to trig client socket error not keeping sending message going no way. Thank you. Kind regards, - jupiter

2 1

How safer to use boos::shared_from_this() from derived class inherited from based class?
by JH 02 Aug '19

02 Aug '19

Hi, I have a derived base class: class Base : boost::enable_shared_from_this<Base> { public: Base(); virtual ~Base(); virtual boost::shared_ptr<Base> SharedFromThis(void) {return shared_from_this();} private: } class Derived : public Base { public: Derived(); ~Derived(); // boost::shared_ptr<Derived> SharedFromThis(void) {return boost::static_pointer_cast<Derived>(shared_from_this());} private: }; Applications are sharing the derived class, it can either use shared_ptr<Derived> or shared_ptr<Base> by calling the SharedFromThis(), three options: (1) Don't define derived class own SharedFromThis(), always call Base SharedFromThis() to pass shared_ptr<Base> as Derived shared_ptr, the reference count will be shared_ptr<Base>. (2) Define derived class its own SharedFromThis() and pass shared_ptr<Derived> to applications: boost::shared_ptr<Derived> SharedFromThis(void) {return boost::static_pointer_cast<Derived>(shared_from_this());} That one cannot be virtual as conflicted to Base SharedFromThis(), the reference count will always be boost::shared_ptr<Derived> (3) Mixed both boost::shared_ptr<Derived> and boost::shared_ptr<Base> in applications, that could be a bad option to cause segmentation as one shared_ptr could be ended before another shared_ptr. Which option will be safer? Thank you. Kind regards, - jupiter

2 2

Norton blocking Appveyor?
by John Maddock 01 Aug '19

01 Aug '19

Hi all, I see that my browser is just started blocking ci.appveyor.com which is a bit of a problem for CI to say the least. Is anyone else seeing this? Any ideas whether it's justified or spurious? Thanks, John. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

3 2

Final Call for Submissions: International Conference on Information Society (i-Society 2019)
by International Conference on Information Society 29 Jul '19

29 Jul '19

If you are not able to see this mail, click http://r.confinfosoc.org/mk/mr/dNqT-1si6HE5qHDv5cV6nrZEGnVvH63myFIAZaMHhWb9… Final Call for Submissions: International Conference on Information Society (i-Society 2019) The i-Society is a global knowledge-enriched collaborative effort that has its roots from both academia and industry. The conference covers a wide spectrum of topics that relate to information society, which includes technical and non-technical research areas. Submission Instructions: * You can submit your extended abstract or paper online at [ http://www.i-society.eu/paper-submission/ ]( http://r.confinfosoc.org/mk/cl/f/cKABES_5mIGAo8Mgp-cuui5DCd9DYYIrOsBvLgtLLN… )or email it to papers(a)i-society.eu * You can submit your poster via email at posters(a)i-society.eu * You can submit your workshop or tutorial proposal at workshop(a)i-society.eu or tutorial(a)i-society.eu * You can submit your speaker's proposal at speakers-2019(a)i-society.eu [ Submit ]( http://r.confinfosoc.org/mk/cl/f/FhV5CG1-0Pk8UtOQVyS5RSUsGqCAVXq-AH1LIwQW9t… ) This email was sent to boost(a)lists.boost.org You received this email because you are registered with Infonomics Society [ Unsubscribe here ]( http://r.confinfosoc.org/mk/un/07f-n0ocPpExwtzrl_PeKAeTG4ctupFicTSTp-RuT97r… ) [ ]( http://r.confinfosoc.org/mk/cl/f/j-a-1n1z1XvvyX_L5iaFp6R3gGFhBceWdCdqP1QnZF… ) © 2019 Infonomics Society

2 1

MSVC 2019
by Cg K 27 Jul '19

27 Jul '19

I recently installed Visual Studio 2019 and then Boost and Quantlib. I tried to compile Quantlb with the precompiled 1.70 boost. I go the error message: LINK : fatal error LNK1104: cannot open file 'libboost_unit_test_framework-vc142-mt-gd-x64-1_70.lib' It appears that compatibility with Visual Studio/MSVC 2019 has not been worked out in 1.70 given its release date was so close to the release date of Visual Studio 2019. I also noted the the beta for 1.71 was closed. Wondering if the beta fixes this or is there a workaround or is this a user error?

7 9

RSS1/RSS2/ATOM + P2P
by Ggh 27 Jul '19

27 Jul '19

Dear All, I invite you all to a debate/brainstorming on implementing an RSS library for boost, as well as an RSS+p2p protocol on the application layer on the TCP/IP stack. I do not claim that RSS should have an implementation in boost, however I think it might be a good idea. Lots of activity on http/application layer of the web and perhaps we/boost developers should consider an RSS extention to boost of RSS/Atom, with P2P capabilities. As always, comments and critisism is velcome. Thank you, Cheers Greg Tell me, and I forget. Ask me, and I discover...

1 0

proposals
by VALERIU SMERICA 27 Jul '19

27 Jul '19

Hello. Is it possible to propose some data structures to be part of Boost that use code under the Apache 2.0 license? Are there any legal issues with this? I heard Apache 2.0 license was pretty permissive. Thanks.

2 1

[release] Boost 1.71.0 Beta 1
by Michael Caisse 26 Jul '19

26 Jul '19

Boost release 1.71.0 beta 1 is now available at: <https://dl.bintray.com/boostorg/beta/1.71.0.beta1.rc1/source/> The SHA256 checksums are as follows: 451adc4f199c73e995e541f38c4dbd51faf4ce0db15537136ffd5213a1be5e55 boost_1_71_0_b1_rc1.7z a93d7066fc1514995aec0e726532a219447dd39b0ffa7cb97ca5736f16b0488b boost_1_71_0_b1_rc1.tar.bz2 34743b80466463e0c1b7fc71b677f326bdc242fe0b87a9c1599b6f7ea6e5c0cb boost_1_71_0_b1_rc1.tar.gz 5cd448bddc8394469391306e0ccada0a8f88c5c6cf8ec775ddf8e56adef8bbc2 boost_1_71_0_b1_rc1.zip For details of what's in the release, see <http://www.boost.org/users/history/version_1_71_0.html>. Note: Having some trouble getting the web page updated... check back with it soon. Please download the beta, give it a try, and report any problems you encounter. Thanks, -- The Boost Release Team

9 15

Boost proposals
by VALERIU SMERICA 26 Jul '19

26 Jul '19

Hello. Is it possible to propose some data structures to be part of Boost that use code under the Apache 2.0 license? Are there any legal issues with this? I heard Apache 2.0 license was pretty permissive. Thanks.

1 0

boost::serialization optional does not use boost::serialization::access
by Janek Kozicki 25 Jul '19

25 Jul '19

Hi, this simple program will not compile. The only way to make it work is to make a public default constructor. This defeats the purpose of boost::serialization::access. I tried to fix <boost/serialization/optional.hpp> but I couldn't get it to correctly call the access::construct(); Please help. // g++ -o serialize_optional /tmp/serialize_optional.cpp -lboost_serialization #include <fstream> #include <iostream> #include <boost/serialization/nvp.hpp> #include <boost/serialization/serialization.hpp> #include <boost/archive/xml_iarchive.hpp> #include <boost/archive/xml_oarchive.hpp> #include <boost/serialization/access.hpp> #include <boost/archive/text_oarchive.hpp> #include <boost/archive/text_iarchive.hpp> #include <boost/serialization/optional.hpp> #include <boost/optional.hpp> class Foo { public: Foo(int k) : i(k) {} friend std::ostream& operator<<(std::ostream& os, Foo const& foo) { return os << "Foo { " << foo.i << " }"; } private: Foo() : i(-1) {}; friend class boost::serialization::access; template<class Archive> void serialize(Archive & ar, const unsigned int){ #define N(a) BOOST_SERIALIZATION_NVP(a) ar & N(i); #undef N }; int i; }; int main() { using Data = boost::optional<Foo>; std::cout << "Boost version: " << BOOST_VERSION << "\n"; { auto f = Data(133); std::ofstream os("test.xml"); boost::archive::xml_oarchive oa(os); oa << boost::serialization::make_nvp("f", f); } { Data g; std::ifstream is("test.xml"); boost::archive::xml_iarchive ia(is); ia >> boost::serialization::make_nvp("f", g); std::cout << g.get() << "\n"; } } best regards Janek Kozicki

2 4

[gil] Missing doc/html/ files from Boost 1.70
by Mateusz Loskot 24 Jul '19

24 Jul '19

Hi, I'm following up this old report of mine [1] about missing GIL docs. Apparently, GIL documentation was not generated during the release process, so no files were copied wherever they should be. The documentation is missing from: - boost_1_70_0 source archives - https://www.boost.org/doc/libs/1_70_0/libs/gil/ Is it possible to fix the website at least, redirect it to valid URL? Can I fix it myself? How? [1] https://lists.boost.org/Archives/boost/2019/04/245985.php Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

1 1

[locale] Loss of precision (C4244) warnings in MSVC 64-bit build
by Kenneth Porter 24 Jul '19

24 Jul '19

Building with MSVC compilers for 64-bit results in several C4244 warnings in api.hpp, due to passing the difference of two pointers (ptrdiff_t) to Win APIs expecting an int. Patch here: <https://github.com/boostorg/locale/issues/42> Using this command with the recent 1.71.0 beta: call .\bootstrap.bat --without-python .\b2 --without-python toolset=msvc-14.2,msvc-14.0,msvc-12.0,msvc-10.0 runtime-link=shared,static address-model=32,64

2 1

[release] Boost 1.71.0 Beta 1 - déjà vu
by Michael Caisse 23 Jul '19

23 Jul '19

Note: The previous email announcement still had the rc1 tag in the filenames. This version of beta1 is identical in content to beta1 rc1. Boost release 1.71.0 beta 1 is now available at: <https://dl.bintray.com/boostorg/beta/1.71.0.beta1/source/> The SHA256 checksums are as follows: 451adc4f199c73e995e541f38c4dbd51faf4ce0db15537136ffd5213a1be5e55 boost_1_71_0_b1.7z a93d7066fc1514995aec0e726532a219447dd39b0ffa7cb97ca5736f16b0488b boost_1_71_0_b1.tar.bz2 34743b80466463e0c1b7fc71b677f326bdc242fe0b87a9c1599b6f7ea6e5c0cb boost_1_71_0_b1.tar.gz 5cd448bddc8394469391306e0ccada0a8f88c5c6cf8ec775ddf8e56adef8bbc2 boost_1_71_0_b1.zip For details of what's in the release, see <http://www.boost.org/users/history/version_1_71_0.html>. Note: Having some trouble getting the web page updated... check back with it soon. Please download the beta, give it a try, and report any problems you encounter. Thanks, -- The Boost Release Team

2 1

[BOOST] Boost fusion testcase fails with llvm and gcc when optimization enabled
by Jaydeep Chauhan 22 Jul '19

22 Jul '19

Hi Devs, consider below boost testcase, boost_1_70_0/libs/fusion/test/functional/invoke.cpp when compiles with optimization enabled, $g++ -O2 -I./boost_1_70_0 boost_1_70_0/libs/fusion/test/functional/invoke.cpp $./a.out ./boost_1_70_0/libs/fusion/test/functional/invoke.cpp(391): test 'that.data == fusion::invoke(& members::data, fusion::join(sv_obj_c_ctx,seq))' failed in function 'void test_sequence_n(Sequence&, mpl_::int_<0>) [with Sequence = boost::fusion::vector<>]' ./boost_1_70_0/libs/fusion/test/functional/invoke.cpp(401): test 'that.data == fusion::invoke(& members::data, fusion::join(sv_obj_c_d_ctx,seq))' failed in function 'void test_sequence_n(Sequence&, mpl_::int_<0>) [with Sequence = boost::fusion::vector<>]' ./boost_1_70_0/libs/fusion/test/functional/invoke.cpp(391): test 'that.data == fusion::invoke(& members::data, fusion::join(sv_obj_c_ctx,seq))' failed in function 'void test_sequence_n(Sequence&, mpl_::int_<0>) [with Sequence = boost::fusion::list<>]' ./boost_1_70_0/libs/fusion/test/functional/invoke.cpp(401): test 'that.data == fusion::invoke(& members::data, fusion::join(sv_obj_c_d_ctx,seq))' failed in function 'void test_sequence_n(Sequence&, mpl_::int_<0>) [with Sequence = boost::fusion::list<>]' 4 errors detected. And When compiled without any optimization $g++ -O0 -I./boost_1_70_0 boost_1_70_0/libs/fusion/test/functional/invoke.cpp $./a.out No errors detected. $g++ --version Target: x86_64-pc-linux-gnu Configured with: ../gcc-9.1.0/configure -- --enable-languages=c,c++ --disable-libquadmath --disable-libquadmath-support --disable-werror --disable-bootstrap --enable-gold Thread model: posix gcc version 9.1.0 (GCC) Here we demonstrated the test case with g++ but same can be seen with clang++. When analyzed further we have seen that this is [ boost_1_70_0/boost/fusion/functional/invocation/invoke.hpp:139 ] trying to return local address, which is undefined behavior. And that lead to above test-case failure. So either we have to modify test-case to pass as reference or disable it.But before going ahead like to know your thought/suggestions? Thanks, Jaydeep

1 0

Innocent but annoying warning in Boost QVM library
by Luigi Castelli 19 Jul '19

19 Jul '19

Hi Emil and all, when compiling Boost QVM, compilation succeeds but I get this warning: filename: quat_operations.hppwarning: Declaration shadows a typedef in function 'boost::qvm::axis_angle' A declaration in line 1438 shadows one in line 1414 Could this be solved for the next update?Thanks - Luigi

2 1

Boost log to limit log file maximum file size
by JH 19 Jul '19

19 Jul '19

H Andrey and all, Can the log file be configured to set up the file size cap, when the log file reaches to the maximum file size, it deletes it and starts a new log file not rotates it? Thank you. - jupiter

2 1

Lambda testcase fails when optimization enabled in gcc and llvm
by navya deepika garakapati 19 Jul '19

19 Jul '19

Hi Devs, consider below reduced testcase from boost lamda. $cat result_of_tests.cpp #include <boost/lambda/lambda.hpp> #include <stdio.h> template<class A, class F> typename boost::result_of<F(A)>::type apply1(F f, A b) { return f(b); } using namespace boost::lambda; int main(int, char *[]) { int one = 1; int d= (apply1<int>(_1 ,one) == 1); printf("\n%d\n",d); return 0; } when compiled with optimization O2 $g++ result_of_tests.cpp -I ./boost_1_70_0 -O2 $./a.out 0 And,when we compile same testcase with O0 $g++ result_of_tests.cpp -I ./boost_1_70_0 -O0 $./a.out 1 The above testcases is demonstrated with g++ compiler but behavior is same on clang as well. so we thought that this may be boost testcase issue. When we replace , int d= (apply1<int>(_1 ,one) == 1); with int d= (apply1<int&>(_1 ,one) == 1); testcase gives correct result with or without optimization. Wanted to confirm here,is it valid testcase or we have to modify testcase as per above? Thanks, Navya

3 5

Review request for LEAF, review manager needed
by Emil Dotchevski 19 Jul '19

19 Jul '19

I'm requesting a formal review for LEAF, a C++11 error-handling library: https://zajo.github.io/leaf. Features: * Header-only, no dependencies. * No dynamic memory allocations. * Compatible with std::error_code, errno and any other error code type. * Can be used with or without exception handling. LEAF comes complete with its own result<T> type, but it is compatible with any other type with value-or-error variant semantics (like outcome::result<T>) as long as .error() returns a std::error_code. https://travis-ci.org/zajo/leaf https://ci.appveyor.com/project/zajo/leaf

3 2

Re: [boost] [release] 1.71.0 closed for Beta
by Kenneth Porter 19 Jul '19

19 Jul '19

I'm seeing the following block of warnings repeated with several MSVC compiler versions. I'd suggest changing int to ptrdiff_t or size_t for the target type. f:\devel\Boost\boost_1_71_0\libs\locale\src\win32\api.hpp(149): warning C4244: 'argument': conversion from '__int64' to 'int', possible loss of data f:\devel\Boost\boost_1_71_0\libs\locale\src\win32\api.hpp(153): warning C4267: 'argument': conversion from 'size_t' to 'int', possible loss of data f:\devel\Boost\boost_1_71_0\libs\locale\src\win32\api.hpp(153): warning C4244: 'argument': conversion from '__int64' to 'int', possible loss of data f:\devel\Boost\boost_1_71_0\libs\locale\src\win32\api.hpp(170): warning C4244: 'argument': conversion from '__int64' to 'int', possible loss of data f:\devel\Boost\boost_1_71_0\libs\locale\src\win32\api.hpp(245): warning C4244: 'argument': conversion from '__int64' to 'int', possible loss of data f:\devel\Boost\boost_1_71_0\libs\locale\src\win32\api.hpp(249): warning C4244: 'argument': conversion from '__int64' to 'int', possible loss of data My build command: call .\bootstrap.bat --without-python .\b2 --without-python toolset=msvc-14.2,msvc-14.0,msvc-12.0,msvc-10.0 runtime-link=shared,static address-model=32,64

1 0

[release] 1.71.0 closed for Beta
by Michael Caisse 19 Jul '19

19 Jul '19

The master branch is now closed for all changes except by permission for the Beta release. Also, remember to add your libraries' changes to the release notes at: <https://github.com/boostorg/website/blob/master/feed/history/boost_1_71_0.q…> Thanks, -- The Boost Release Team

5 8

Any sample code to configure boost log for syslog?
by JH 18 Jul '19

18 Jul '19

Hi, I am using boost log to write log file in the disk of the desktop, but for an embedded system application where the NAND flash is used, to prolong the flash service life time, I try not to write log files in flash, but use journalctl to view the log in RAM. Are there any simple example to configure boost log for syslog? Thank you. - jh

2 2

Something off my chest about Boost
by Maarten Verhage 18 Jul '19

18 Jul '19

Dear Boost people, Sorry but I need to get something off my chest regarding the Boost culture. To start of with something nice: I’m convinced Boost provides really useful facilities for C++ and some of them even make it into the standard C++ library. I do believe I can also contribute in a reasonable way. But the terse documentation keeps me from advancing. How it is currently stated on https://www.boost.org/users/faq.html “What about documentation? A very simple library might be accepted with only a well commented header file. For more substantial libraries, some form of documentation is certainly going to be expected. HTML is the preferred form.” To make Boost more accessible to people I believe Boost should ask more on this from current and new library authors. Speaking for myself. I think the first bits to get started with a library are on a sufficient level. You know the tutorial and the example code. But I get lost when I want to use the library for my own application domain. Then I do need library facilities not covered in the example code and sometimes the documentation mentions only the syntax. As I would imagine the library author working on his/her library judging whether to add a facility or not. Finally decided to add something: *the thought/motivation that goes along with that*, that would be so valuable for me to read that in the documentation!! Yes, I’m annoyed that I cannot read that in the documentation. Another issue is when example code introduces three or more facilities at once. Then it is very hard for me to see how these bits relate to each other to make it useful for myself. Ok, a few examples for what I would like to ask the Boost community to demand from the library authors: 1) In general, for the classes/functions where the user should directly deal with documentation like cppreference.com. So, with function prototypes showing the argument- and return types and a complete list of members along with what they do. 2) Specifically for Spirit X3, a part on Parser Directives: https://www.boost.org/doc/libs/develop/libs/spirit/doc/x3/html/spirit_x3/qu… I would very much like that the reason why each directive is added along with a minimal example that shows how to use just that directive. Anyway, I hope people are also interested to discus documentation policies on this mailing list. I do believe it is important. Best regards, Maarten Verhage

10 17

ASIO socket termination crashed at boost::asio::async_read
by JH 17 Jul '19

17 Jul '19

Hi, I use boost TCP socket for months, it works well until I call a termination of smart pointer which is running at boost::asio::async_read. Could anyone explain what could be the cause for the following errors? void Comms::HandleReadBody(const boost::system::error_code &error, const uint32_t length) { ................ boost::asio::async_read(this->mHandler->Socket(), boost::asio::buffer(this->mHeader, sizeof(this->mHeader)), [=](const boost::system::error_code &status, const uint32_t length) {this->HandleReadHeader(status, length);}); ............... } (gdb) run 2019-07-15 11:47:32.396184: Sanity check socket connection and terminate it when it is inactive ............. pure virtual method called terminate called without an active exception Program received signal SIGABRT, Aborted. (gdb) backtrace #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51 #1 0x00007ffff7a24801 in __GI_abort () at abort.c:79 #2 0x00007ffff5565957 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 #3 0x00007ffff556bab6 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 #4 0x00007ffff556baf1 in std::terminate() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 #5 0x00007ffff556c8bf in __cxa_pure_virtual () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 #6 HandleReadHeader(boost::system::error_code const&, unsigned int) () #7 0x00007ffff679a116 in boost::asio::detail::read_op<boost::asio::ssl::stream<boost::asio::basic_stream_socket<boost::asio::ip::tcp, boost::asio::stream_socket_service<boost::asio::ip::tcp> > >, boost::asio::mutable_buffers_1, boost::asio::detail::transfer_all_t, HandleReadBody(boost::system::error_code const&, unsigned int)::{lambda(boost::system::error_code const&, unsigned int)#1}>::operator()(boost::system::error_code const&, unsigned long, int) () #8 0x00007ffff6799c20 in boost::asio::ssl::detail::io_op<boost::asio::basic_stream_socket<boost::asio::ip::tcp, boost::asio::stream_socket_service<boost::asio::ip::tcp> >, boost::asio::ssl::detail::read_op<boost::asio::mutable_buffers_1>, boost::asio::detail::read_op<boost::asio::ssl::stream<boost::asio::basic_stream_socket<boost::asio::ip::tcp, boost::asio::stream_socket_service<boost::asio::ip::tcp> > >, boost::asio::mutable_buffers_1, boost::asio::detail::transfer_all_t, HandleReadBody(boost::system::error_code const&, unsigned int)::{lambda(boost::system::error_code c---Type <return> to continue, or q <return> to quit--- onst&, unsigned int)#1}> >::operator()(boost::system::error_code, unsigned long, int) () #9 0x00007ffff679b547 in boost::asio::detail::reactive_socket_recv_op<boost::asio::mutable_buffers_1, boost::asio::ssl::detail::io_op<boost::asio::basic_stream_socket<boost::asio::ip::tcp, boost::asio::stream_socket_service<boost::asio::ip::tcp> >, boost::asio::ssl::detail::read_op<boost::asio::mutable_buffers_1>, boost::asio::detail::read_op<boost::asio::ssl::stream<boost::asio::basic_stream_socket<boost::asio::ip::tcp, boost::asio::stream_socket_service<boost::asio::ip::tcp> > >, boost::asio::mutable_buffers_1, boost::asio::detail::transfer_all_t, HandleReadBody(boost::system::error_code const&, unsigned int)::{lambda(boost::system::error_code const&, unsigned int)#1}> > >::do_complete(boost::asio::detail::task_io_service*, boost::asio::detail::task_io_service_operation*, boost::system::error_code const&, unsigned long) () #10 0x000055555559f5c0 in boost::asio::detail::task_io_service::do_run_one(boost::asio::detail::scoped_lock<boost::asio::detail::posix_mutex>&, boost::asio::detail::task_io_service_thread_info&, boost::system::error_code const&) () #11 0x000055555559f747 in boost::asio::detail::task_io_service::run(boost::system::error_code&) ()

4 5

Useful Release Notes
by James E. King III 13 Jul '19

13 Jul '19

I'd suggest we make sure our release notes are useful to end users; I found some examples that are in the 1.71 that are not useful when reading the notes: * [phrase library..[(a)/libs/flyweight/index.html Flyweight]:] * Maintenance work. * [phrase library..[@/libs/poly_collection/ PolyCollection]:] * Maintenance work. Thanks, Jim

2 1

meeting today
by Robert Ramey 12 Jul '19

12 Jul '19

I was impressed with your presentation today. you can find current renderings at this link: https://we.tl/t-TDoBHgw9AF Robert Ramey

1 1

The out_ptr review is now over
by Zach Laine 11 Jul '19

11 Jul '19

Thanks to all that participated. A review result with be posted sometime in the next couple of weeks (the upcoming C++ standards meeting next week will delay it a bit). Zach

1 0

Failed reconnection
by JH 11 Jul '19

11 Jul '19

Sorry for keeping posting questions about ASIO TCP socket reconnection regarding to network interface changes, I am very much stuck at the moment. As I described in other emails, when one network interface WiFi failed, the network interface Ethernet takes over, the client application using boost ASIO TCP socket cannot detect the broken of WiFi, it continually sent messages to the remote server via the broken WiFi interface without triggering errors but obviously the server could not receive messages any more. So my solution is prior to send message, it ping to 8.8.8.8 via the network interface WiFi, if it failed, it called the SetConnection again to close the socket binding to WiFi interface and to start reconnection to bind to Ethernet interface: void SetConnection(void) { if (this->mSocket.lowest_layer().is_open()) { std::cout << "Set connection close socket" << std::endl; this->mSocket.lowest_layer().close(); } boost::asio::ip::tcp::resolver resolver(this->mIoService); boost::asio::ip::tcp::resolver::query query(this->mHost, this->mPort); this->mIterator = resolver.resolve(query); this->mContext.load_verify_file("ssl/ca.pem"); this->mSocket.set_verify_mode(boost::asio::ssl::verify_peer); this->mSocket.set_verify_callback(boost::bind(&client::verify_certificate, this, _1, _2)); boost::asio::async_connect(mSocket.lowest_layer(), this->mIterator, boost::bind(&client::handle_connect, this, boost::asio::placeholders::error)); } But it did not work, the error: handle_connect connect failed: Network is unreachable What I am missing here? How can I make the TCP socket reconnection? Thank you. Kind regards, - jupiter

2 3

Link problem with graph and pending still appears unresolved?
by pbristow＠hetp.u-net.com 10 Jul '19

10 Jul '19

I have been bitten by this problem, again ☹ error: Cannot create link boost\pending\detail\disjoint_sets.hpp to libs\graph\include\boost\pending\detail\disjoint_sets.hpp. error: Link previously defined to another file, libs\disjoint_sets\include\boost\pending\detail\disjoint_sets.hpp. that was discussed https://lists.boost.org/Archives/boost/2019/04/246083.php I have got going again by deleting the contents of boost/boost/ containing the symlinks. But I note that a folder pending still exists, but not graph. Is this unresolved? Should it be fixed for the next release? Paul Paul A. Bristow Prizet Farmhouse Kendal, Cumbria LA8 8AB UK

5 14

[releaase] 1.71.0 closed for major changes
by Marshall Clow 09 Jul '19

09 Jul '19

The master branch is now closed for new libraries and breaking changes, and will be closing for the beta in one week. Also, if you're ready, you can also add your libraries' changes to the release notes at: < https://github.com/boostorg/website/blob/master/feed/history/boost_1_71_0.q… > After editing the release notes, you should get a form to create a pull request, remember to submit it, otherwise I won't see your change. As always, the calendar for the release cycle is available at: https://www.boost.org/development/ Thanks, -- The Boost Release Team

3 2

Beast repo history changed?
by Tom Kent 09 Jul '19

09 Jul '19

Did something get re-written in the beast repo? I was getting some weird errors on my cron mirror job: error: object file ./objects/3c/5bd5d909ee9b71f2b28d002dfe9d98355766c9 is empty error: object file ./objects/3c/5bd5d909ee9b71f2b28d002dfe9d98355766c9 is empty fatal: loose object 3c5bd5d909ee9b71f2b28d002dfe9d98355766c9 (stored in ./objects/3c/5bd5d909ee9b71f2b28d002dfe9d9835576 6c9) is corrupt error: object file /mnt/fs2/boostorg/beast.git/objects/3c/5bd5d909ee9b71f2b28d002dfe9d98355766c9 is empty error: object file /mnt/fs2/boostorg/beast.git/objects/3c/5bd5d909ee9b71f2b28d002dfe9d98355766c9 is empty fatal: loose object 3c5bd5d909ee9b71f2b28d002dfe9d98355766c9 (stored in /mnt/fs2/boostorg/beast.git/objects/3c/5bd5d909e e9b71f2b28d002dfe9d98355766c9) is corrupt Deleting and re-creating the repo worked fine: git clone --mirror git@github.com:boostorg/beast.git Cloning into bare repository 'beast.git'... remote: Enumerating objects: 296, done. remote: Counting objects: 100% (296/296), done. remote: Compressing objects: 100% (158/158), done. remote: Total 48131 (delta 142), reused 210 (delta 110), pack-reused 47835 Receiving objects: 100% (48131/48131), 35.50 MiB | 24.22 MiB/s, done. Resolving deltas: 100% (33475/33475), done. Not an issue for my just curious/suspicious. Tom

2 1

Contributing to Boost. Astronomy
by Siddhartha Sen 09 Jul '19

09 Jul '19

Hello, I want to get started in contributing to Boost. Astronomy. Could anyone help me out here? This is the first time I will be contributing to open source. Hence I don't have any idea how this works. I am proficient in C and C++ and have a keen interest in Astronomy. Could anyone tell me what all things I need to learn first before I am able to contribute? What documentation should I read or what issues should I be aware of, before I can start contributing? Any help would be appreciated.

3 2

out_ptr formal review
by Gavin Lambert 05 Jul '19

05 Jul '19

My apologies in advance for the light novel. # Do you think the library should be accepted as a Boost library? Not in its current form, although I encourage cleaning it up and resubmitting it. # Your knowledge of the problem domain I've used COM smart pointers (usually CComPtr) a few times, and more rarely wrapped some other C or C-like APIs. (Although mostly pre-C++11, requiring something more hand-rolled than unique_ptr.) # What is your evaluation of the library's: ## Design The API seems reasonable for both out_ptr and inout_ptr. (Although also see the end of this post.) Actual uses for inout_ptr outside of a "realloc" type function seems a bit rare to me (and such APIs also seem rather rare), but perhaps there are other justifying cases I am not aware of, or it's more common in a particular domain. I do like that unspecified function argument evaluation order was considered, and I agree that it is better to try to maintain safety regardless of evaluation order rather than simply telling users to not access the smart pointer in other arguments -- it is a very easy trap for users to fall into, especially where the same code that has been working forever may suddenly fail with a different compiler version or different compiler settings. (Sequencing of destructor execution with additional && conditionals is admittedly a similar problem with no good solution within this design, as is explained in the caveats.) I don't like that it is left unspecified whether release() is called on construction or destruction (as that decision is left to the custom specialisations), as this potentially reintroduces that problem. I think it should be required that all specialisations behave in the following manner: For out_ptr: - construction initialises a raw ptr to nullptr and does not alter the smart ptr. - destruction resets the smart pointer to the raw ptr (in all cases). - this provides a useful guarantee that the smart ptr is always reset to nullptr if the called method returns nullptr, even if it had some other value previously. For inout_ptr: - construction get()s the current value of the smart ptr in two separate raw ptrs (one passed as the function argument, one cached for the destructor to use for comparison), but does not release() it. - destruction will (only if the raw ptr now has some different value) release()s the smart ptr and then reset()s it to the new raw ptr. - this makes it safe to use the smart ptr's value in other arguments of the method call; unspecified release() timing would have made that unsafe. (There is a slightly dodgy step in there where technically the smart pointer could be pointing at something which it thinks it owns, but that the called function has already deleted. However given that any normal or exceptional exit path would then call the inout_ptr destructor [guaranteed before the smart pointer destructor], which would safely release() the pointer without double-deleting it, this seems sufficiently safe, and worth it to permit safe argument usage. The only caveat is that usage of the smart pointer sequenced after the method call but before the destructor execution [as in additional && conditions] is not safe, as it may access deleted memory; however that code would never have the correct behaviour anyway and the documentation already warns to avoid doing that.) Perhaps there are some types of smart pointer for which this contract wouldn't work (eg. if it is possible for release() to fail, or to release a different pointer from what get() returns)? But then if so I'm not convinced it's safe to give them a uniform interface with pointers where it is safe, because otherwise inevitably someone is going to hit the unspecified-parameter-evaluation-order problem (or assuming that it will be nullptr on failure). Especially given these suggested constraints, I would prefer that a simple ADL or traits-type customisation point were added, so that you can adapt to smart pointers which merely have different spellings of the reset and release methods and don't require deeper customisation -- though the existing customisation point could be retained for especially weird smart pointer types if needed. (ADL customisation points are superior because, if designed correctly, they would not introduce a dependency on Boost.OutPtr, and if named well could theoretically also be used by other libraries, as with non-member begin and swap.) Similarly, while the static_assert check in base_out_ptr_impl specifically for std::shared_ptr and boost::shared_ptr seems valuable to prevent a significant class of bugs, I question whether it might be better handled by checking a type trait or other customisation point rather than checking directly for those types, such that it would be possible for a user-defined smart pointer type to also participate if it has a similar concern. Or perhaps it should just discourage use of shared_ptr at all; there should be little performance difference between using shared_ptr directly and using a unique_ptr which is later moved to a shared_ptr. (Since neither can take advantage of the make_shared optmisation, and by definition ownership must be unique at that point.) ## Implementation I haven't verified whether the current implementation exactly follows my suggested contract above, as there are a few too many layers of indirection and inheritance for me to easily parse. Simplifying the implementation would be nice if possible, especially for out_ptr, to improve readability. (However I think that my description is close at least.) I am strongly opposed to both of the "clever" implementations in the library. They should be completely removed. I can think of absolutely no justification (performance or otherwise) for a "clever" out_ptr. Due to both the requirement to pass in nullptr and to not delete the original smart pointer on construction (as it might be used in other parameters), the raw pointer can never have the same storage as the smart pointer anyway. (At least not unless you absolutely promise to never use a non-nullptr smart pointer, which reduces usefulness, albeit admittedly for a slightly peculiar use case [which would have been unsafe when used with raw pointers directly].) (In theory you could pass in an uninitialised raw pointer and then conditionally reset or do nothing depending on whether it still has the same uninitialised value after the call, but this both requires capturing the actual value at construction and providing a weaker contract to the C API, so it seems like a bad idea and a pessimisation to me. Another option is to unconditionally reset() on construction, but this sacrifices use in other parameters.) There is a possible justification for the clever inout_ptr, in that you can save two raw pointer copies if you reuse the smart pointer's storage, and this does not have the same caveats as with out_ptr. I am not convinced that anyone should care about that (especially in code paths also including memory allocation), although it is possible that the savings may be more significant with a smart pointer more complex than unique_ptr. Having said that, this "clever" implementation should absolutely never be used for any existing smart pointer, especially including std::unique_ptr or boost::movelib::unique_ptr. If there is sufficient justification for its existence at all, then you should instead create a new smart pointer (bikeshed: boost::out_ptr::fast_ptr) which behaves equivalent to std::unique_ptr except that you can steal its raw pointer storage when using inout_ptr. This could be made move-compatible with std::unique_ptr for the people who want to keep that type in their interfaces -- although that would presumably also remove any dubious performance benefit. As previously brought up in a separate thread, the current review implementation also leaks public inheritance of std::tuple, which is presumably intended as an empty-base optimisation, but must not be public or it will allow inappropriate slicing (and Very Bad Things™). ## Documentation The documentation seems decent, although being split into many short pages as at present can at times make it harder to locate something specific. I would prefer longer single pages divided into sections, but that's a matter of taste and not a review condition. I dislike the assertion that a "well-designed" C API would always set the parameter to nullptr on failure. That is certainly one option (and typically a preferred one), but leaving the parameter unchanged is another entirely reasonable option, and does not signify "poor design". It is only reasonable to claim poor design if the API allocates and sets the value, internally deletes it, and then reports failure (while still returning the altered and deleted pointer), as this condition cannot be handled by out_ptr (or indeed by anything that doesn't understand the failure return semantics of the API). The time axis scale in the benchmarks seems not entirely helpful as a lot of the time the difference between two implementations is within one axis division of each other. And again, the magnitude of performance difference sitting in the <1ns range in code which inherently implies memory allocation suggests a severe case of premature optimisation to me. (Though perhaps that might be more justifiable when used in non-memory handle contexts -- but then that might be an abuse of calling it a "pointer".) ## Usefulness I think that this library or something like it could be quite useful to help unify and improve safety when interacting with C-style T** APIs (or T* output arguments for some opaque handle type that requires cleanup), without requiring exploitation of operator& tricks like CComPtr does. (Sure, it's trivial to write an RAII wrapper around such APIs, but this can become cumbersome when there are hundreds or thousands of such APIs, unless you're using a code generator. And it's easy to accidentally forget subtle but important things such as deleting copy operations.) # Did you try to use the library? With what compiler? Did you have any problems? I did not try it. However the "clever" implementation is highly compiler-and-library-specific and quite aside from its design issues I think it would also produce significant portability issues. # How much effort did you put into your evaluation? I spent several hours on this review over the course of several days, and some related prior discussion in the mailing list. I read through all the documentation and most of the code (though not the tests). ============================ Having said all of the above, I wonder whether the library author has considered a different design for this functionality? Rather than the given example code: using bop = boost::out_ptr; boost::shared_ptr<mll_driver> axis_driver(nullptr); mll_errno err = mll_driver_init( bop::out_ptr(axis_driver, mll_driver_free), /* additional args ...*/); if (err != MLL_SUCESS) { // ... } A wrapping lambda syntax could be used instead: boost::shared_ptr<mll_driver> axis_driver(nullptr); mll_errno err = bop::invoke( [&](mll_driver** p) { return mll_driver_init(p, /* additional args ...*/); }, bop::out_ptr(axis_driver, mll_driver_free)); if (err != MLL_SUCESS) { // ... } Here, rather than its current meaning, bop::out_ptr just defines a parameter grouping which is then turned into a raw pointer-pointer argument for the lambda; it has no destructor-based shenanigans. (This could also be used for other non-pointer argument types -- there just needs to be a way for invoke to query the expected API argument type from the out_ptr or from the lambda itself.) This is admittedly more verbose than the current design (although bop::invoke could be written as just "invoke" due to ADL, for a slight simplification); but it would allow you to more safely control the sequencing between the API call and the reassignment of the smart pointer -- in particular all of the existing caveats with order of evaluations and with if-statement and composite conditional ordering no longer apply. (You can safely "&& axis_driver" above as long as you do it outside of the invoke call.) The API would be called (via the lambda) from a try-catch block inside of bop::invoke (or instead of the try-catch an RAII helper can be used to perform a try-finally action), and either the existing guarantee of not calling reset() or release() until after the call can be maintained (thereby allowing the smart pointer to be used by reference within the lambda), or it could be forbidden to use the smart pointer inside the lambda and the caller could lambda-capture the necessary arguments by value instead. Either way, the caller should be less surprised about lifetime issues across a lambda "border", and would quickly discover if they did it "wrong" (because the reset/release would either always occur before or always occur after argument evaluation, never in mixed order). invoke would normally be called with only one out_ptr or inout_ptr argument (and consequently one argument to the lambda), but could in principle be extended to any number of arguments either by nested invoke calls or by supporting a variadic form which does the equivalent within the library. It could possibly also be extended to support user-defined argument types to do something more complex, by defining a concept interface that it uses to interact with the argument, rather than explicit overloads or specialisations on those specific types. This could leave the decision of when to reset/release up to the smart-pointer-specific specialisation (if that's useful for performance reasons), and without leaving any time bombs for the caller.

1 0

Mother of all Variants
by Robert Ramey 05 Jul '19

05 Jul '19

I'm way out of my depth in the variant discussion. Seems to me it revolves around all the trade offs regarding design choices. Could we perhaps decide not to decide. Suppose we create a type which looks like: template< bool BasicGuaranteeSupported, bool StrongGuaranteeSupported, bool EmptyStateProhibited, bool AssignmentSupported, bool MoveSupported, class T ... > struct mother_of_variants{ // some trivial mp11 code }; Now we could define: using boost_variant = mother_of_all variants< bool true, //BasicGuaranteeSupported, bool true, //StrongGuaranteeSupported, bool true, //EmptyStateProhibited, bool true, //AssignmentSupported, bool true, //MoveSupported, >; std_variant, std_optional, std_expect, boost_outcome, etc. would be similarly defined. And some "extras" like no_except_variant, trivial_variant, etc. would be added. and of course my favorite candidate: using safe_variant = mother_of_all variants< bool true, //BasicGuaranteeSupported, bool true, //StrongGuaranteeSupported, bool true, //EmptyStateProhibited, bool false, //AssignmentSupported, bool false //MoveSupported, >; In addition, we'd have some type traits: mother_of_all_variants::no_runtime_allocation<mov>; mother_of_all_variants::no_double_instancen<mov>; mother_of_all_variants::is_mother_of_all_variants<mov>; etc. Just think that of all the time we've spent on discussions about optional, expected, std::variant, boost::variant, etc. At this rate, these discussions will keep hounding us forever. Of course I realize that the main purpose of having these variants of variants is to justify the discussions - but perhaps we might be ready for a new topic. Robert Ramey

17 57

Boost Version 1.47 not building with 2017.
by nunna, sarath babu (GE Healthcare) 03 Jul '19

03 Jul '19

Hello, 1.47 boost is not being built with VS2017. We want to get boost 1.47 built with VS2017, So that we can integrate them with our VS2017 code base. Please guide us, it will be a great help. Thanks, Sarath.

4 9

Boost compatibility/communication issue with 1.47 to 1.7
by nunna, sarath babu (GE Healthcare) 03 Jul '19

03 Jul '19

Hello All, So far we have used Boost 1.47 VS2010 built binaries integrated with our VS2010 Code Base . But now we are upgrading VS2010 to VS2017 of our product code base, also we tried Boost 1.70 boost built using VS2017 and integrated with our VS2017 code base. Our product should be compatible with older versions of all tools including boost. We have not faced any issues except boost. Issue: 1.7 boost is not able to communicate to 1.47 boost and giving "SERIALIZATION ERRORS". 1.47 boost is not able to communicate with 1.7 boost and giving "SERIALIZATION ERRORS". Please help us and let us know which boost version we could upgrade that can be compatible with 1.47. Note: The customer is already using 1.47 2010 boost binaries with built VS2010 product which we can't change. Please suggest us the resolution or the version that we should use. Thanks, Sarath.

4 4

Construction of /defaultlib:XXX for boost::python
by Kacvinsky, Tom 01 Jul '19

01 Jul '19

I discovered while using boost 1.69 with Python 2.7 that a /defaultlib:XXX directive for the boost::python import library is injected into each object file that uses boost::python header files. What I have not been able to figure out is the magic for doing this. I presume it is a macro that makes a #pragma for default libs based on the threading model, the address model, the version of Python in use, and the _MSC_VER compiler macro. Am I am on the right track? Where would this code be? I could find it via searching for #\w?pragma in the code base. Thanks, Tom

2 1

out_ptr review
by Glen Fernandes 30 Jun '19

30 Jun '19

[Edit: Some changes for clarity within, as it was pointed out on Slack that some of the phrasing is confusing. Also updated subject.] Many thanks to JeanHeyd for going through the Boost review process, and to Zach for managing the review. Briefly: I cannot justify acceptance for out_ptr just yet in its current form. I hope to see it return for a new review if the feedback from this review shapes the design so that some of these concerns are resolved. Second: This excludes "inout_ptr" (for which I had even more concerns) and just covers "out_ptr" which is the simpler and more common use case of the two. Below when comparing "what happens under the hood" with out_ptr against the hand written code that a user would write to use a typical C out-pointer API with smart pointers, this is what I'm comparing: [Typical code user would write to use a smart pointer]: Type* raw; Result result = TheCApi(args..., &raw); if (!Success(result)) { // failure (e.g. return, or branch and handle error) } Smart<Type, Deleter> smart(raw, etc...); [What would happen under the hood when using out_ptr]: /* First, 'smart' already has to exist here before TheCApi is called. Either as Smart<Type, Deleter> smart; or Smart<Type, Deleter> smart(nullptr, etc...); depending on deleter */ /* User writes: Result result = TheCApi(args..., out_ptr(smart)); or Result result = TheCApi(args..., out_ptr(smart, etc...)); depending on deleter */ Type* raw = nullptr; Result result = TheCApi(args..., &raw); if (raw != nullptr) { smart.reset(raw); // or smart.reset(raw, etc...); depending on deleter } if (!Success(result)) { // failure (e.g. return, or branch and handle error) } Concern 1. Having to define the smart pointer before TheCApi is called. Ordinarily this might be fine for some smart pointers and stateful deleters, but it may not be fine or desirable for others (depending on the deleter, and depending on the use case). Concern 2. The original user code initializes the smart pointer based on Success(result). The out_ptr version does so based on whether the raw out pointer was changed to something non-null by TheCApi. This might be fine for some cases, but it may not be for others. That it isn't the same as fundamental logic as the user code bothers me, though. Concern 3. The equivalent of the hand written user code is less overhead. Personally I'm of the opinion that this doesn't matter too, but here the author does say he has users who cannot abide by it, and that this facility needs support from e.g. std::unique_ptr to be viable. I'm not a fan of needing unique_ptr implementations to add support for this to make it comparable to some user's hand written code (And this also leads to concern 4 below). Concern 4. The UB optimization that the author wrote because of Concern 3 is a real concern to him. The UB optimization has no place in Boost, and one of which doesn't even work with many C++ library vendors' unique_ptr. (Fortunately the Boost reviews have already echoed this sentiment and I believe this is going away). Concern 5. Supporting other custom smart pointers requires effectively re-implementing out_ptr_t by specialization. I have come to see this as not viable. (Already mentioned in other reviews, and I echo this.) Concern 6. C APIs where the deleter (its state, logic, etc.) are governed by some other result from TheCApi. This is can be worked around in many cases, but the workaround is clumsy. Or insupportable, in other cases. i.e. The stateful deleter in the example above is always initialized with 'etc...' either before-hand via Smart<Type> smart(nullptr, etc...) or at call site with: TheCApi(args, out_ptr(etc...)); before analyzing other results of calling TheCApi. [Concern 7. This concern I had made notes about pre-review has already been eliminated, when the unconditionally noexcept destructor is now only conditionally noexcept.] Other thoughts: The suggestion by Emil lead to an interesting alternative idea to this problem domain, but I had no time to fully explore it. I don't think it would address all of these concerns. It has some other greater appeal, e.g. a way to call C APIs that materializes the smart pointers as results (along with C API return value) of an "Invoke-style" thing. Or even a way to transform a C API with out-pointers into a C++ callable that returns smart pointers (along with C API return value) via a "Bind-style" thing. Glen

2 1

out_ptr's formal review starts now!
by Zach Laine 30 Jun '19

30 Jun '19

Dear Boost community, The formal review of JeanHeyd Meneide's out_ptr library starts Sunday, June 16th and ends on Wednesday, June 26th. out_ptr is a library for making it easy to interoperate between smart pointers and traditional C-style initialization and allocation interfaces. It also enables doing so in a way that allows library authors to opt into speed optimizations for their smart pointers that give them performance equivalent to typical C pointers (see benchmarks ( https://github.com/ThePhD/out_ptr/blob/master/docs/out_ptr/benchmarks.adoc) and the Standard C++ proposal for more details). Online docs can be found here: https://github.com/ThePhD/out_ptr/blob/master/docs/out_ptr.adoc The GitHub repository is available here: https://github.com/ThePhD/out_ptr Also, there is an associated standards proposal: https://thephd.github.io/vendor/future_cxx/papers/d1132.html We encourage your participation in this review. At a minimum, please state: - Whether you believe the library should be accepted into Boost - Your name - Your knowledge of the problem domain You are strongly encouraged to also provide additional information: - What is your evaluation of the library's: * Design * Implementation * Documentation * Tests * Usefulness - Did you attempt to use the library? If so: * Which compiler(s)? * What was the experience? Any problems? - How much effort did you put into your evaluation of the review? All issues discussed during this review will be tracked on the library's GitHub issue tracker at https://github.com/ThePhD/out_ptr/issues. Regards, Zach Laine

11 31

out_ptr review
by David Sankel 29 Jun '19

29 Jun '19

# Whether you believe the library should be accepted into Boost No. Not until some of the major issues are addressed. # Your name David Sankel # Your knowledge of the problem domain I've had to wrap C APIs on multiple occasions. # What is your evaluation of the library's: ## Design The design of the `out_ptr` type is reasonable as a shorthand for calling certain C APIs. In my experience a use case for `in_out_ptr` has never come up. Given the subtleties of its correct (and likely rare) usage, I'd be in favor of leaving this out of the library altogether. Especially given that the semantics of when 'release()' is called are not specified. I agree with the other comments that the customization point is not minimally complete. Ideally a customization point would not require one to replicate all the functionality of the class I'm customizing and, instead, only require a few general purpose functions that that interface can make use of. ## Implementation There are two implementations of `out_ptr`. The one called "clever" invokes undefined behavior as a means to squeeze out some extra performance. I do not think the performance overhead of using this library with the "non clever" implementation justifies the potential portability and and other risks associated with depending on undefined behavior working a particular way. It looks like "clever" mode was #ifdef'ed out, but removing it as cruft would improve maintainability of the implementation and remove the complexity of having an additional `core_out_ptr_t` class. The provided implementation works for smart pointers that follow conventions like the standard, but has some additional logic if the types happen to be `std::shared_ptr` or `boost::shared_ptr`. This hard coded special casing won't work with, say, a company specific shared pointer implementation. This relates to my earlier comment that the customization point should be simplified. ## Documentation The recommendation in the "caveats and caution" to not use out_ptr outside if/else conditionals goes a bit far in my opinion. It is common practice to make function calls that emit failure with return codes in conditionals, as in: ``` if (SQLITE_OK != sqlite3_open("test.db", boost::out_ptr::out_ptr(database, sqlite3_close))) { std::cout << "Problem opening the file"; } ``` For these cases it is safe to use `out_ptr` so I'd suggest rewording the recommendation to allow calls like this. "Almost all well-designed C APIs will set the user-provided output pointer argument to NULL/nullptr upon invalid parameters". This is a very difficult claim to make (what's the sample size?). I'd suggest changing "Almost all" to "Many". I don't understand what the issue is here with APIs not setting the out parameter on failure (which IMO is good practice especially as it relates to strong exception safety guarantees). These APIs have return codes that need to be inspected anyway. The reference documentation reads like a specification rather than what I would typically consider reference documentation. I'd expect to see it written with an intended audience of a casual user with examples and an organization that would be helpful for this reader (e.g.: purpose, description, examples, details) ## Tests The tests look reasonable and comprehensive although there seems to be some `#if 0` conditions that could either be cruft or perhaps the intent is the developer would manually change those to verify compilation failure. The tests are using the 'catch' library which is intended to be a submodule. Is there a precedence for using a third party library like this? For folks using Boost it could be painful to get another dependency approved to run all the Boost tests. It would be preferable IMO to use Boost.Test or something self contained. ## Usefulness I attempted to use the library with g++ 8.3.0 and clang 8.0.0. My example code is below: ```C++ #include <boost/out_ptr.hpp> #include <sqlite3.h> #include <iostream> int main() { std::shared_ptr<sqlite3> database; if (SQLITE_OK != sqlite3_open("test.db", boost::out_ptr::out_ptr(database, sqlite3_close))) { std::cout << "Problem opening the file"; } using Sqlite3Ptr = std::unique_ptr<sqlite3, decltype(&sqlite3_close)>; Sqlite3Ptr database2(nullptr, &sqlite3_close); if (SQLITE_OK != sqlite3_open("test.db", boost::out_ptr::out_ptr(database2, sqlite3_close))) { std::cout << "Problem opening the file"; } } ``` With this `Makefile` ```c++ main : main.cpp g++ -I/home/dsankel/code/out_ptr/include -o $@ $< `pkg-config sqlite3 --cflags --libs` .PHONY: clean clean: $(RM) main ``` I didn't run into any issues. Everything worked okay. I think this library would be handy for wrapping C libraries like sqlite. # How much effort did you put into your evaluation of the review? I spent a few hours on this review. I read through all the documentation, did a cursory review of the code, and came up with the example above. # Minor things * Copyright notices need to have a person's real name to have legal benefits. * In `aout_ptr.adoc` the examples link goes to the overview page. * Some grammar errors in the "C function calls are indeterminately sequenced..." paragraph. * When referring to a Boost library in free flowing text, the correct form is Boost.LibraryName with the same font as the surrounding text.

5 5

out_ptr review is extended until Wednesday, July 10
by Zach Laine 29 Jun '19

29 Jun '19

We don't have enough reviews yet, so we're extending the review by two weeks. Please review this small and useful library! >From the original announcement: The formal review of JeanHeyd Meneide's out_ptr library starts Sunday, June 16th and ends on Wednesday, June 26th. out_ptr is a library for making it easy to interoperate between smart pointers and traditional C-style initialization and allocation interfaces. It also enables doing so in a way that allows library authors to opt into speed optimizations for their smart pointers that give them performance equivalent to typical C pointers (see benchmarks ( https://github.com/ThePhD/out_ptr/blob/master/docs/out_ptr/benchmarks.adoc) and the Standard C++ proposal for more details). Online docs can be found here: https://github.com/ThePhD/out_ptr/blob/master/docs/out_ptr.adoc The GitHub repository is available here: https://github.com/ThePhD/out_ptr Also, there is an associated standards proposal: https://thephd.github.io/vendor/future_cxx/papers/d1132.html We encourage your participation in this review. At a minimum, please state: - Whether you believe the library should be accepted into Boost - Your name - Your knowledge of the problem domain You are strongly encouraged to also provide additional information: - What is your evaluation of the library's: * Design * Implementation * Documentation * Tests * Usefulness - Did you attempt to use the library? If so: * Which compiler(s)? * What was the experience? Any problems? - How much effort did you put into your evaluation of the review? All issues discussed during this review will be tracked on the library's GitHub issue tracker at https://github.com/ThePhD/out_ptr/issues. Zach

5 7