June 2017 - Boost - lists.preview.boost.org

Re: [boost] [cmake] Minimum viable cmakeification for Boost
by Thomas Heller 20 Jun '17

20 Jun '17

Am 20.06.2017 4:21 nachm. schrieb "Peter Dimov via Boost" < boost(a)lists.boost.org>: Thomas Heller wrote: > As a general observation, I see a lot of statements along the lines of "I > state that XYZ is preferable over UVW", it would be nice to have to have > background information (pros and cons anyone? what do the cmake > authors/docs have to say about this?) on those statements so that everyone > can form their own opinion instead of having to choose whom to trust about > what's "standard" cmake. > That's the problem with CMake, there's no way for someone like me who does not follow it to get a definitive answer to what idiomatic CMake 3.5+ is. There are several articles about it, they all say more or less the same thing - use target_*. I get that. But that's not enough. I see a general (and very predictable) trend of moving from imperative to declarative. Programmers like imperative, but a proper build system really prefers declarative, so CMake is trying to evolve towards declarative. Take for example find_package. It's a command, find me this package, now. But it's much better if a library does not issue "find me this package" commands, but rather declares which packages it needs. So we get "best practice" hacks like redefining find_package. I'm sorry, this doesn't feel right. I hear what you're saying. We'll end up innovating cmake, which for me isn't a bad thing. I'm favoring CMake due to its great support for generating for all kinds of different environments (including proper visual studio solutions). To be fair, I haven't invested as much time in boost.build as I did for cmake. For all platforms I work on, both work equally nice with different quircks on different ends. I'm not using an ide though. For the sake of ide support, I'd lean towards cmake. Regarding the discussion of what's right and wrong when writing your CMakeLists.txt files, it's almost bike shedding. If you want to depend on a library, you'll make it work, no matter what, that's what we do. Nevertheless, in terms of cmakeisms, I really like what Paul put together and what Daniel Pfeifer said in his talk makes a lot of sense in a cmake world. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman /listinfo.cgi/boost

1 0

proposal - modularize Boost build system
by Stefan Seefeld 20 Jun '17

20 Jun '17

One of Boost's bottlenecks is its monolithic build infrastructure. It would be beneficial for many different use cases (testing, packaging, etc.) to decouple the building of Boost libraries (well, those that require building, see the listing in http://www.boost.org/doc/libs/1_64_0/more/getting_started/unix-variants.htm…) such that they may optionally be built stand-alone. At present, building a Boost library requires the entire (super-)repository to be checked out, and the build logic itself involves traversing the entire source tree, looking for a "Jamroot". What would be beneficial to many would be a workflow like this: 1) Have a development environment with (some version of) Boost pre-installed (or at least the parts that the library being built depends on). 2) Check out a single Boost repository (e.g., https://github.com/boostorg/python) 3) Invoke a command to build it (if there is anything to build) 4) Invoke a command to test it 5) Invoke a command to install it 6) Invoke a command to package it (optional) While it's of course already possible to do all the above by adding support for another build infrastructure (point in case: Boost.Python right now uses SCons for this very reason), this means duplication of effort, as Boost as a whole is still built, tested (and even packaged for binary packages) using Boost.Build, meaning I need to maintain two sets of build infrastructure. This proposal thus has two parts: 1) Make the nested build logic independent of the outer bits, so individual libraries can be built stand-alone (for example, using b2 by adding a `--with-boost` set of options to point to the location of the prerequisite parts of Boost). 2) Define a clear interface the outer build logic will use to invoke the nested build commands. Note that for my own case above (Boost.Python), providing 2) would be enough, i.e. by having a way for me to "plug in" my SCons commands to build and test Boost.Python could obsolete the existing Boost.Build logic as defined in Boost.Python (as well as the prerequisite parts in Boost.Build's "python" module). However, as my proposal is *not* actually advocating to move away from Boost.Build, but rather to modularize it, I think 1) is essential to let everyone else (who may not be inclined to use anything other than Boost.Build) to also take advantage of modularization. While I'd rather avoid delving into the technical details of how this could possibly be implemented (if you really must, *please* do so in a new thread !), let me outline a few use-cases that would be made possible by the above: * individual projects would be free to switch to their preferred infrastructure, including CMake, SCons, etc., if they so wish * individual projects could be much more easily developed and contributed to * individual projects could be much more easily tested, notably in CI environments * individual projects could be much more easily packaged All of the above advantages are *huge*, and reflect real-world needs, and the technical issues to solve these are all minor. The question really is whether there is enough will to move into that direction. I'd be very happy to participate in the work needed to implement this. But first we need to agree that this is where we want to go. Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin...

14 46

Review of Nowide
by Chris Glover 20 Jun '17

20 Jun '17

Hi, The following is my review of the proposed Boost.Nowide library. This is my first official review of a boost library, so please forgive me if I've missed anything. - What is your evaluation of the design? At first I was surprised by lack of a platform agnostic encoding. However, through reading the docs and the discussion in the list, I believe this to be the correct choice. If a user has a need for a common encoding, I believe that would be best served by a different library that would ultimately have different issues and performance characteristics. One thing I'm not sure about is if the overlap between the fstream implementations in filesystem and nowide is necessary. It seems to me that if I set filesystem to be nowide aware (via boost::nowide::nowide_filesystem) then there's little reason for the nowide versions of the stream objects to exist, other than possibly eliminating one string copy on non-windows platforms and avoiding the filesystem dependency (and maybe those are good enough reasons). - What is your evaluation of the implementation? I only gave the implementation a glance. It looks good; clean, organized; with a full test suite and nothing weird stands out. It seems to be of the typical quality I expect from a boost library. - What is your evaluation of the documentation? The documentation is clear and complete, but I think it needs to explain at the top that the library does not present a uniform encoding for strings. This is discussed in the documentation near the end, under "Q & A", but I think it should be near the top. A suggestion is to add a section called "What Boost.Nowide is *not*" directly under the section titled "What is Boost.Nowide", otherwise I expect some users to be surprised. - What is your evaluation of the potential usefulness of the library? It is very useful. I am already using it. - Did you try to use the library? With what compiler? Did you have any problems? I converted one application that was using boost::filesystem::path to transport filenames around to use nowide instead. I had no issues, everything just worked. Some code was also simplified as a result -- not dramatically, but enough that it felt better. I tested the application on windows only using Visual Studio 2017. I also ran the tests under MSYS2 on Windows using gcc-6.3, on Windows using MSVC 2017 and on Ubuntu using gcc-7. Under MSYS, one test failed (Fail: Error boost::nowide::cin.putback(c) in test_iostream.cpp:17 main), but I haven't had a chance to look into why yet. All of the tests passed on the other platforms. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I followed the discussion, read the docs, integrated the library, used the API and tested the resulting program. All in, I think that took me about 4 hours. This seems quick, but to me that is a testament to a solid design and clear documentation because the conversion process was very simple. - Are you knowledgeable about the problem domain? I am aware of the problem and have worked around it in the past by using filesystem::path as a string. However, most of the environments I work in professionally are controlled in a way that allows us to avoid this problem most of the time, so I have not had extensive experience with it. - Do you think the library should be accepted as a Boost library? Yes. I am already using it and expect I will be using it a lot more going forward. -- chris

2 2

[nowide] review
by Andrzej Krzemienski 20 Jun '17

20 Jun '17

Hi All. This is a review of Boost.Nowide library. I am not really familiar with the problem. I used to do trivial tasks with files on Windows, but they were always ASCII, so the problems solved by Boost.Nowide never affected me. I am also not fa,iliar with the problems of converting from Windows encoding (*WTF* seems like the right choice of name) to UTF-8. I have read the documentation, and got some additional information from the author. I have downloaded the library and have run a toy program that plays with names that cannot be encoded in a single code-page. I am testing on Windows 7, MinGW, GCC 6.3, with -std=c++03. Compilation and linking works fine. Tests work fine too. Then, I tried the same example with normal `std::ifstream` and it did not work on Unicode file names and strings, which conforms that Boost.Nowide solves an existing problem. DESIGN: clear, logical, intuitive. IMPLEMENTATION: I did not look at. DOCUMENTATION: clear. POTENTIAL USEFULNESS: as specified in the docs, if you want to do things with multilingual strings in a platform independent way, you need a library like this. I vote to *ACCEPT* the library. I may not be qualified enough (the manager will weigh my vote), but the desctiption of the library, as well as the replies from Artyom convince me that the library addresses the problem in the right way and is reliable. Artyom, thanks for sharing this library, and submitting it for review. One minor thing. In th be docs (http://cppcms.com/files/nowide/html/) we read: boost::nowide::widen <http://cppcms.com/files/nowide/html/namespaceboost_1_1nowide.html#a6baacc1b…> returns std::string. I thing is thsould be std::wstring? Regards, &rzej;

2 5

Atomic Shared Ptr
by Olaf van der Spek 19 Jun '17

19 Jun '17

Hi, Does Boost have anything like concurrency TS' atomic_shared_ptr? Gr, -- Olaf

3 7

Re: [boost] Boost CRC maintainer (Daryle Walker) missing in action?
by Olaf van der Spek 19 Jun '17

19 Jun '17

Hi Daryle, Any luck on your new setup? Gr, Olaf On Mon, Nov 28, 2011 at 1:11 AM, Daryle Walker <darylew(a)gmail.com> wrote: > I can look at it once I've finished my new setup. > > I had to reset my computer after a partial crash years ago. I never > got around to recreating my programming setup. My computer had been > at its maximum Operating System level back then, which is now 3 > versions behind. For the past few months, I've had my sister's old > laptop, with Windows Vista, and am trying to add a programming setup > to it now. > > > On Tue, Nov 22, 2011 at 7:18 AM, Beman Dawes <bdawes(a)acm.org> wrote: >> Hi Daryle, >> >> This guy has volunteered to take over maintenance of Boost CRC. Should >> we take him up on his offer? > >> ---------- Forwarded message ---------- >> From: >> Date: Wed, Nov 2, 2011 at 7:51 AM >> Subject: [boost] Boost CRC maintainer (Daryle Walker) missing in action? >> To: boost(a)lists.boost.org >> >> >> Hi, >> >> It looks like the Boost CRC maintainer (Daryle Walker) is missing in action? >> >> No response to tickets from the past 3 years. What's the procedure in this case? >> >> https://svn.boost.org/trac/boost/ticket/2492 >> https://svn.boost.org/trac/boost/query?component=crc&col=id&col=summary&col… > > -- > Daryle Walker > Mac, Internet, and Video Game Junkie > darylew AT gmail DOT com -- Olaf

2 2

Sanitizer bug or undefined behavior in format?
by Olaf van der Spek 19 Jun '17

19 Jun '17

Hi, I think it's about rdbuf() which doesn't appear to be virtual. Is this a bug in the sanitizer or is this call not allowed? alt_sstream.hpp: basic_oaltstringstream(stringbuf_t * buf) : pbase_type(buf, No_Op() ), stream_t(rdbuf()) { } $ g++ a.cpp -fsanitize=undefined && ./a.out /usr/include/boost/format/alt_sstream.hpp:146:60: runtime error: member call on address 0x7fffdb4f36a0 which does not point to an object of type 'basic_oaltstringstream' 0x7fffdb4f36a0: note: object has invalid vptr 00 00 00 00 00 00 00 00 00 00 00 00 18 3a 4f db ff 7f 00 00 b0 4c 37 fa 66 55 00 00 28 5b 0d 80 ^~~~~~~~~~~~~~~~~~~~~~~ invalid vptr a.cpp: #include <iostream> int main() { std::cout << boost::format("%d") % 1 << std::endl; // std::cout << boost::format("%04d-%02d-%02d") % (date->tm_year + 1900) % (date->tm_mon + 1) % date->tm_mday << std::endl; return 0; } -- Olaf

2 2

Re: [boost] proposal - introduce API & ABI compatibility guidelines
by Brian Wood 19 Jun '17

19 Jun '17

Artyom Beilis writes: > The problem is that it isn't going to change in near future because > it is almost impossible to reach a consensus of some strategic > direction because any major change will find enough developers > who will not want one. > > So today I use boost only in applications and never in libraries. I'm only comfortable using Boost in private/closed source applications. I think on line code generation will help with some of the packaging problems discussed in this thread. Brian Ebenezer Enterprises - Enjoying programming again. http://webEbenezer.net

1 0

proposal - introduce API & ABI compatibility guidelines
by Stefan Seefeld 18 Jun '17

18 Jun '17

Following up on this point made by Peter Dimov in another discussion: > This is part of the price you pay for being accepted as part of Boost > - the duty to act as an integration test for your Boost dependencies. > This is beneficial for you in the long term, because you can detect > breaking changes in your dependencies before they get shipped. If you > only test against 1.56, and 1.64 breaks your library, you won't hear > about it before 1.72. This does you no good, and it does your users no > good. You WANT to know if changes in 1.65's SmartPtr would break you > BEFORE 1.65 gets released. The real problem that you are touching here is Boost's lack of any sort of ABI or even API stability. So Boost 1.X and Boost 1.(X+1) are two distinct packages, as there is no metric that enables even to measure the amount of incompatibility between the two. Any normal library that's used in-production would have strong requirements for backward compatibility, to enable users to reason about the risk of upgrading etc. Thus, to follow up (and not pollute the original discussion about modularization), I'll propose the following: I'd like to see guidelines to be established for: * what API and ABI changes may be applied in a given release * have a clear definition of version numbers (major, minor, bug fix) with associated semantics * impose testing requirements to enforce the above. Stefan -- ...ich hab' noch einen Koffer in Berlin...

2 1

[nowide] request for clarification
by Andrzej Krzemienski 17 Jun '17

17 Jun '17

Hi Everyone, I admit I am not quite familiar with the problem, but I understand that as one of the features, nowide offers a replacement for std::fstream that can be constructed with its string types. At the same time we have boost::filesystem that offers its own replacement for std::fstream that can be constructed with filesystem::path. Now, if I want to use `filesystem::path`s in my program (to be able to tell just any string from a filesystem path), can I still use the benefits of `nowide` library? Also, in the docs for nowide::ifstream, we read, "Same as std::basic_ifstream<char> but accepts UTF-8 strings under Windows." What about other systems? What does it accept on Linux? ascii? In documentation for `nowide::args`, we read, "args is a class that fixes standard main() function arguments and changes them to UTF-8 under Microsoft Windows." Does it write to the input strings in-place? is it even legal in C++? It "fixes", which implies that otherwise the args are "broken". How are args in function main() broken? (other than not being UTF-8)? Regards, &rzej;

5 9

[review] More reviews of Nowide are welcome
by Frédéric Bron 16 Jun '17

16 Jun '17

Hi all, More official reviews are welcome for the boost nowide library. It's a small and very useful library, please consider taking some time to give us your feedback. Please answer the questions at the bottom of this message. Cheers, Frédéric (review manager) ---------- Forwarded message ---------- Date: 2017-06-12 6:20 GMT+02:00 Subject: [boost][review] Review of Nowide (Unicode) starts today Hi Everyone, The formal review of Artyom Beilis' Nowide library starts today and will last until Wed. 21st of June. Your participation is encouraged, as the proposed library is uncoupled, focused and rather small. Nowadays, everyone needs to handle Unicode but this is very difficult using only the standard library in a platform independant way. Nowide offers a very simple way to handle Unicode the same way on Windows/MacOS/Linux. Key features: * work with UTF-8 in your code, Nowide converts to OS encoding * Easy to use functions for converting UTF-8 to/from UTF-16 * A class to fixing argc, argc and env main parameters to use UTF-8 * UTF-8 aware functions: - stdio.h functions (fopen, freopen, remove, rename) - stdlib.h functions (system, getenv, setenv, unsetenv, putenv) - fstream (filebuf, fstream/ofstream/ifstream) - iostream (cout, cerr, clog, cin) Documentation: http://cppcms.com/files/nowide/html GitHub: https://github.com/artyom-beilis/nowide git clone https://github.com/artyom-beilis/nowide.git Latest tarballs: - to be unzipped in boost source: https://github.com/artyom-beilis/nowide/archive/master.zip - as a standalone library: http://cppcms.com/files/nowide/nowide_standalone.zip Nowide has standard boost layout. So, just put it into the boost source tree under libs/nowide directory for building and running tests. Or alternatively - for header only part of the library add the nowide/include path to the include path of your projects. Please post your comments and review to the boost mailing list (preferably), or privately to the Review Manager (to me ;-). 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 most importantly: - Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. For more information about Boost Formal Review Process, see: http://www.boost.org/community/reviews.html Thank you very much for your time and efforts. Frédéric

1 0

Re: [boost] [review] Review of Nowide (Unicode) starts today
by Artyom Beilis 16 Jun '17

16 Jun '17

How would you therefore do this simple task: 1. get a directory from nowide::getenv -> base_dir (UTF-8 on Windows, unknown narrow on Posix) 2. create a file in base_dir which name is file_name encoded in UTF-8 (because it is created by the application). If I understand well, I should NOT do this: auto f = nowide::ofstream((boost::filesystem::path(base_dir) / file_name).string()); because this is guaranteed to work only on Windows where I have the guarantee that base_dir is UTF-8, right? Actually it is what exactly you should do. Once you turn on **nowide integration** with boost filesystem path::string does not perform any conversions on POSIX platforms. And you can safely concatenate two different strings and valid file will be created. Even if dir is in ISO 8859-1 and file in UTF-8. The file will be valid even if not representable in any encoding. Under windows you'll get the correct conversions from narrow to wide using the utf8/16 facet installed by boost.nowide/Filesystem integration as on Windows boost filesystem uses wide strings Artyom

4 4

[interprocess] how to use lock_file with Unicode file name?
by Frédéric Bron 16 Jun '17

16 Jun '17

Hi, I have been using lock_file with ASCII file names without any trouble. Now I would like to be able to use non ASCII file names. How does it work? Currently, lock_file uses as input const char *. What about the encoding? Cheers, Frédéric http://www.boost.org/doc/libs/1_64_0/doc/html/boost/interprocess/file_lock.… http://www.boost.org/doc/libs/1_64_0/doc/html/interprocess/synchronization_…

1 0

Re: [boost] [review] Review of Nowide (Unicode) starts today
by Frédéric Bron 15 Jun '17

15 Jun '17

> at Linux nowide fstream is > an alias to std::fstream If course! Frédéric

1 0

[config][android] GCC-5 and 6 failures.
by John Maddock 15 Jun '17

15 Jun '17

There are some runtime (segfault) failures running config_test on andoid, see for example: http://www.boost.org/development/tests/develop/developer/CrystaX-apilevel-2… Can anyone with access to this platform (or preferably the test runner) see if defining BOOST_NO_CXX11_THREAD_LOCAL fixes the issue? That would be my hunch for the problem anyway. Many thanks, John. --- This email has been checked for viruses by AVG. http://www.avg.com

2 2

[random] Request for Additional Generators
by degski 15 Jun '17

15 Jun '17

I would like to request the addition of 2 generators to Boost.Random. xoroshiro128+ <http://xoroshiro.di.unimi.it/xoroshiro128plus.c> Web page: http://xoroshiro.di.unimi.it/ A very fast PRNG, (quite a lot) faster than the fastest current boost generator, with a period of 2 ^ 128, which could/would be good for f.e. game programming (except for shuffling, see below). It also has a state of only 16 bytes on x64. The author states that the distribution is of higher quality than f.e. MT19937-64 <http://www.math.sci.hiroshima-u.ac.jp/%7Em-mat/MT/VERSIONS/C-LANG/mt19937-6…>. It's probably best to just read the web-page, as it goes into quite some detail and is in itself the summary of the research conducted in this area. Other than the normal boost complications, it's very easy to implement and I use my simplistic implementation to great satisfaction with the std and boost distributions. In this <https://www.codeproject.com/Tips/1083372/Random-Number-Generator-Recommenda…> article on CodeProject the issue of shuffling is raised. It's appears that shuffling of large arrays of data requires a generator with extremely long periods in order to be able to generate all the possible permutations. To this extent I would like to see in boost a generator like George Marsaglia's SuperKiss <https://groups.google.com/forum/#!topic/comp.lang.fortran/QiTrbq0XeyM> or/and a templated SFMT generator like this <https://sourceforge.net/p/int64/svn/HEAD/tree/snips/sfmt.hpp> one. degski -- "*Ihre sogenannte Religion wirkt bloß wie ein Opiat reizend, betäubend, Schmerzen aus Schwäche stillend.*" - Novalis 1798

2 3

[review] Review of PolyCollection starts today (May 3rd)
by Ion Gaztañaga 15 Jun '17

15 Jun '17

Hi everyone, The formal review of Joaquín M. López Muñoz's PolyCollection library starts today. I'd like to encourage your participation as the proposed library is small and focused, and reviewers don't need to be domain experts to appreciate the potential usefulness of the library and propose improvements. PolyCollection implements fast containers of polymorphic objects. Typically, polymorphic objects cannot be stored directly in regular containers and need be accessed through an indirection pointer, which introduces performance problems related to CPU caching and branch prediction. Boost.PolyCollection implements a novel data structure that is able to contiguously store polymorphic objects without such indirection, thus providing a value-semantics user interface and better performance. Three polymorphic collections are provided: * boost::base_collection * boost::function_collection * boost::any_collection dealing respectively with classic base/derived or OOP polymorphism, function wrapping in the spirit of std::function and so-called duck typing as implemented by Boost.TypeErasure. The library can be found here: Incubator: http://blincubator.com/bi_library/polycollection/?gform_post_id=1643 Github: https://github.com/joaquintides/poly_collection and the documentation here: http://rawgit.com/joaquintides/poly_collection/website/doc/html/index.html Please post your comments and review to the boost mailing list (preferably), the Boost Library Incubator. or privately to the Review Manager (to me ;-). 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 most importantly: - Do you think the library should be accepted as a Boost library? For more information about Boost Formal Review Process, see: http://www.boost.org/community/reviews.html Waiting your reviews! Ion

13 51

[review] Review of Nowide (Unicode) continues - summary of the dicussions so far
by Frédéric Bron 15 Jun '17

15 Jun '17

Dear all, The formal review of Artyom Beilis' Nowide library continues until Wed. 21st of June. Here is a summary of the discussions so far: 7 people participate to the review (not counting Artyom and my-self): - Degski - Niall Douglas - Paul Groke - Peter Dimov - Vadim Zeitlin - Yakov Galka - Zach Laine 2 official reviews have been shared, both positive for inclusion in boost (Degski, Peter Dimov). Discussions: Everybody is positive about the usefullness of the library but some major questions arose: 1. how should we handle invalid Unicode sequences (bytes or multi-bytes)? Allow? throws error? 2. there is an unsymmetric way of treatment between Windows and Posix: - on Windows, the conversion from UTF-16 checks for Unicode conformance and returns only valid UTF-8 or fails - on Posix, no check is performed that the input is a valid UTF-8 sequence. 3. in particular, on Windows, the roundtrip conversion UTF-16 -> UTF-8 -> UTF-16 is not guaranted if the initial string is non conformant One main issue is that existing files may have non conformant names and would therefore not been reachable by the nowide API on Windows. On Posix platforms, non conformant paths would work transparently. Different proposals have been made to address this: - convert from UTF-16 to a superset of UTF-8 so that the round-tip conversion is possible, this would mean that the library accepts non conformant strings on Windows as is done on Posix. Question: which enconding should be used (Modified UTF-8, WTF-8, CESU-8)? WTF-8 has the issue of being difficult to handle with string concatenations. - use RtlUTF8ToUnicodeN functions which replace wrong UTF-16 characters by U+FFFD but is this OK for round-trip? - see glib approach - add function to explicitly convert from wide to WTF-8 However, for the Posix case, the issue is that we cannot guarantee that the encoding is always UTF-8 so checking for conformance may be impossible. Hence the choice for not checking on Posix. Minor points: - Missing some documentation on what happens if invalid UTF-8 is provided (getenv, setenv, cout, cerr). - ::setenv on cygwin gives a compile time error (Peter Dimov proposed a fix) - suggestion to add stat and readdir Frédéric

1 0

Packt: Mastering Git - Jakub Narębski
by degski 15 Jun '17

15 Jun '17

To those interested. On Packt, the ebook Mastering Git - Jakub Narębski <https://www.packtpub.com/application-development/mastering-git> is today avaialble for free download, free membership (registration) required. I don't work for Packt. degski -- "*Ihre sogenannte Religion wirkt bloß wie ein Opiat reizend, betäubend, Schmerzen aus Schwäche stillend.*" - Novalis 1798

1 0

[poly_collection] Help with Intel 16.0
by Joaquin M López Muñoz 14 Jun '17

14 Jun '17

Hello, Boost.PolyCollection will be released with Boost 1.65 on Aug 9. So far regression tests are looking OK for MSVC>=14.0, GCC>=5.0 and Clang>=3.7: http://www.boost.org/development/tests/develop/developer/poly_collection.ht… For Intel>=16.0, though, all tests pass except test_algorithm (admittedly the one involving more complex code): http://tinyurl.com/ya52o3e5 As I don't have local access to that compiler it is very difficult for me to try to find the needed workarounds. If someone with interest in Intel and access to the tools wants to volunteer to help fix the offending test case, please be my guest. Contact me either through this list or by private email. Thank you, Joaquín M López Muñoz

1 0

Mangled "From" field in mailing list posts
by Vladimir Prus 14 Jun '17

14 Jun '17

Hi, it seems that most of recent posts to the mailing lists have rather strange "From" field, e.g. From: Daniel James via Boost <boost(a)lists.boost.org> I see this problem both via NTTP and regular mail, including emails that appear to be posted directly with a mail client. That extra "via Boost" adds no value, and clutters mailbox. Is there any change to return back to having "From" field have just the name of the person? Thanks in advance, Volodya

7 18

[trac] Add Boost.Process to Boost.Trac component list
by Ion Gaztañaga 13 Jun '17

13 Jun '17

Hi, I recently received a bug report for Boost.Process. Since it is not selectable in the component list the reporter selected "interprocess" which minimizes the error ;-) Could someone with permissions add "process" to the trac component list? Many thanks! Ion

3 2

[beast] Request for Discussion
by Vinnie Falco 12 Jun '17

12 Jun '17

Beast provides low level HTTP and WebSocket interfaces built on Boost.Asio, the project is here: https://github.com/vinniefalco/Beast The plan is to solicit feedback from the Boost community before submitting a request for a formal review. First a brief update: I have attended CppCon 2016 and provided a 15 minute Lightning Talk on the library. There should be a video up at some point with all the talks, including mine. I spread the word about Beast and discovered that there are several folks in the wild already using the library and happy with it. There are also a couple of commercial products that are using it. One point brought up during the conference is that Beast does not offer sufficient higher level HTTP functionality. This omission is intentional. It is my idea to offer the building blocks (serializing and deserializing HTTP/1 messages, in synchronous and asynchronous flavors, and a universal HTTP message model), upon which other developers more knowledgeable than me could build those interfaces. The higher level pubic operations requested were: 1. Perform HTTP GET or POST and receive the response. Presumably this would handle both plain and TLS connections, handle redirects, and handle HEAD requests. Not sure about traversing proxies. 2. Expose an asynchronous HTTP server class which callers can instantiate with some sort of handler that returns the HTTP response given a request. It should be possible, in a minimal number of lines, to quickly get a server up and running. The requestor informed me that this functionality did not need to provide every possible feature or handle every use case. It just needed to handle the common use-cases. For the record, I am against this higher level functionality for a number of reasons. The higher the level of functionality, the more contentious the feature becomes, and the harder it is to satisfy a quorum of reviewers. No one would dispute that we need the ability to read a complete HTTP message from a socket. But not everyone will agree that a HTTP server needs an option to allow multiple listening sockets with different level of permissions. Another problem with offering higher level functionality is that it could be less likely to be approved for standardization in the C++ standard library. For example, the attributes of ease of use and fully functional oppose each other. If the functionality offered by a hypothetical std::http::client is not sufficient, a developer would be forced to write their own with little possibility to reuse parts of the implementation from the stdlib. I doubt the committee would approve of such a thing. I know I wouldn't. Admittedly I have little experience or knowledge on what would or would not get approved. A point was raised that a low-level-only HTTP implementation in Boost has the potential to discourage new users that need to perform simple operations like HTTP GET from using Boost in the future, given that robustly handling such operations would require the developer to write a significant amount of code. I can see some validity here. On the other hand, if Boost.Asio was submitted for a formal review today, would those same points be raised? Would Asio get rejected because it doesn't offer public interfaces for doing simple tasks like requesting an object from a web server? I wonder if perhaps the Boost formal review process has become defective. For reference here is what the current API offers: Example program that performs HTTP GET, then receives and prints the response: https://github.com/vinniefalco/Beast/blob/master/examples/http_example.cpp This is a high performance asynchronous HTTP server that serves local files as static pages. It is not an official API, it is part of the examples. Users who want a server need to copy the source code and modify it to suit their needs: https://github.com/vinniefalco/Beast/blob/master/examples/http_async_server… My initial purpose for requesting this discussion is two-fold: 1. Determine the level of consensus on the issue that Beast needs to do more for HTTP than the lowest level of functionality (reading and writing messages). I'm open to hearing all arguments for and against. 2. Get feedback on what official public interfaces to higher level functionality might look like. Specifically, a client that handles GET and POST, and a generic asynchronous server. And what features those interfaces would support. For example, is traversing a proxy a necessary feature for an official client interface? The best answers would provide function signatures or class declarations using the existing Beast HTTP types. In case its not clear, I am asking stakeholders and reviewers to help design the library. I'll open a discourse on the HTTP client to illustrate the proposed style of discussion: We want to provide a HTTP client implementation that lets users perform simple tasks like fetch a resource from a remote host. Calling code should be compact, letting people get their job done without getting mired in boilerplate. Here's a possible signature with example use: response_v1<string_body> get(std::string const& url, error_code& ec); error_code ec; auto res = get("http://boost.org", ec); if(! ec) std::cout << res; else std::cerr << ec.message() << '\n'; The get function would automatically perform the name resolution, connect the socket, request the resource with uri "/", and return the result. There's a problem here though, the caller is forced to use a message with std::string as the container for the body. An obvious fix is to add a template parameter: template<class Body = string_body> response_v1<Body> get(std::string const& url, error_code& ec); Better, but what if the body is not DefaultConstructible? We can add some parameters to forward to the Body constructor: template<class Body = string_body, Args&&... args> response_v1<Body> get(std::string const& url, error_code& ec, Args&&... args); We're getting somewhere now. Most users will use the default body, while an option exists for advanced users. But the implementation of get now has a complication. If an error occurs, it still has to construct a return value. This problem is likely surmountable but lets table it and start a new line of reasoning. What if the URI indicates https, e.g. "https://boost.org"? We can hide that under the hood by using a separate code path that uses asio::ssl::stream instead of ip::tcp::socket. But how does the caller provide the root CA certificates? How does the caller provide a client certificate? We are left with a client that satisfies two thirds of users but is unusable for the remaining one third. Is this Boost worthy? Is this std-lib worthy? I think not. Lets revisit the SSL issues later and think about a new problem. What happens to the socket when the request is done? In the proposed interface, the socket is destroyed. This means you can only make one request on a connection. At this point, I think its clear that the current interface is a non-starter. Here's a better idea. Lets define a class called client and make get a member function. Now we can have state, including configurable settings with reasonable defaults. class client { public: template<class Option> void set_option(Option&&); template<class Body = string_body, Args&&... args> response_v1<Body> get(std::string const& url, error_code& ec, Args&&... args); }; client c; error_code ec; auto res = c.get("http://boost.org", ec); if(! ec) std::cout << res; else std::cerr << ec.message() << '\n'; We still have some of the original problems, but other problems are solved. The class can keep the socket around, so that a subsequent call to get with the same server will use the already-open socket. The caller can set options on the client object instance before invoking get, such as any TLS certificates. Unfortunately we have new problems. Where is the io_service? If the class creates it for you, how many threads? How do I use my existing io_service, or is that even necessary? The class interface allows the connection to be kept alive but what if now the caller wants to close it (i.e. specify "Connection: close" in the request)? And there are some problems which are applicable to any interface. How does the caller adjust the parser options, for example change the limit on the size of the body? What if the caller wants the request made using a specific HTTP version? How does this handle basic authentication? How can the caller adjust the headers in the request? etc... This is why I think that offering a HTTP client is a rabbit hole which can only lead to a rejected formal review. Or maybe I am overthinking this? I'd love to hear proposed solutions to the issues (which could be just to say "forget about those features"). Despite my objection I have started work on these features anyway. Here are the beginnings of a HTTP client: https://github.com/vinniefalco/Beast/blob/88b485df7e6216282842f40cf99cc75de… Here is some work on a generic server: https://github.com/vinniefalco/Beast/blob/server/extras/beast/http/async_se… Please reply to this thread instead of starting a new thread, and keep the subject line prefix (e.g. "Re: [boost] [beast] ...") Thank you

21 58

Boost Build configure checks improvement. [config/predef]
by Rene Rivera 12 Jun '17

12 Jun '17

There's been a long standing "issue" with how the b2 configure checks work. Or rather how some times they don't work. In particular the issue is that the set of properties considered relevant for the configuration checks was fixed. As of last night that is now resolved < https://github.com/boostorg/build/commit/450c25c3b52f5ddcb323140f8423adf3b8… >. As the commit mentions the set is no longer fixed and is configurable by users. The changes now mean that: 1. Any subfeatures of the top level relevant feature set are also considered as part of the set. This means that one can a configuration like below to support multiple invocations of the same toolset with different options. In particular the STD options: === user-config.jam === import feature ; using clang ; feature.subfeature toolset clang : std : cxx03 cxx11 cxx14 cxx17 : optional composite propagated ; feature.compose <toolset-clang:std>cxx03 : <cxxflags>-std=c++03 ; feature.compose <toolset-clang:std>cxx11 : <cxxflags>-std=c++11 ; feature.compose <toolset-clang:std>cxx14 : <cxxflags>-std=c++14 ; === And one can then invoke "b2 toolset=clang-cxx14,clang-cxx11" and get non-colliding configuration checks. 2. The set of relevant features is now soft wired as the set of subfeatures of the "<composite>" feature. Which means ones can add to the default set < https://github.com/boostorg/build/blob/develop/src/build/configure.jam#L26>. For example to add threading choice to the relevant features: === user-config.jam === import feature ; import configure ; feature.compose <configure> : <threading> ; === Enjoy. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

1 0

[outcome] Second high level summary of review feedback accepted so far
by Niall Douglas 11 Jun '17

11 Jun '17

Firstly thanks to everyone who has contributed no less than **618** emails at the time of writing to the Outcome review. Despite some on Reddit calling this review a "train wreck" and indeed some lovely things about me personally, I have found this review deeply helpful, and I believe so have most of its contributors in helping us all firm up our differing opinions about what such a vocabulary type ought to be. With regard to the previous high level summary at http://boost.2283326.n4.nabble.com/outcome-High-level-summary-of-review-fee…, I have made only these changes to the changes in that summary: 1. I have been persuaded to use longer more appropriate naming for result<T> and outcome<T>, so now the typedefed varieties with implicit conversions to their empty-capable form indicated by "=>" are: - static_checked_outcome<T> => static_checked_optional_outcome<T> static_checked_result<T> => static_checked_optional_result<T> These have narrow observers which reinterpret_cast and are therefore undefined behaviour if the state does not match, but use __builtin_unreachable() to help static analysis tooling like clang-tidy spot UB where it can be statically deduced. Conceptually, they are a very thin convenience wrap of std::variant<...>. - runtime_checked_outcome<T> => runtime_checked_optional_outcome<T> runtime_checked_result<T> => runtime_checked_optional_result<T> The runtime_checked_optional_* varieties are identical and unchanged to the outcome<T> and result<T> in the submitted library. They have wide observers with a formal empty state and it is never undefined behaviour to call any observer. This allows the programmer to save typing considerable boilerplate knowing that the runtime checks save the programming needing to spell things out. I have not been persuaded to change a single thing in their design yet apart from removing unnecessary member functions, but thanks to everybody who has tried, and if you think I am making a critical mistake, you still have a few days left to persuade me of it! For anyone not familiar with the discussion and feels that the names are excessively long, be aware they are just convenience typedefs of a more complex to configure "template<...> class outcome_impl". It is expected that end users of the library will choose the varieties they want for their code and typedef them into their local namespace as "result<T>" or whatever. Nobody is proposing that end users actually type out the full name each and every time they use them, and the documentation will make that clear. 2. I have been persuaded to replace the implicit conversion from static_checked_* varieties to runtime_checked_* varieties with explicit conversion instead as the implicit conversion could produce runtime failure where the programmer did not expect that to occur. Regarding other changes that I have accepted since the previous high level summary: 1. Outcome's STL exception throw catch to result<T> super-macro was found to be overkill given that current compilers won't replace simple throw...catch sequences with a branch, and still invoke the full throw-catch runtime machinery whatever the case. Therefore an exception to error code conversion function makes more sense than a macro. https://github.com/ned14/boost.outcome/issues/50 2. Outcome's usage of git submodules is felt by some reviewers to be a showstopper for acceptance as they could bring in non-Boost code unexpectedly in the future. I have agreed to make a cronjob script generated Boost.Outcome from standalone Outcome in the same fashion as Boost.ASIO is script generated from standalone ASIO. https://github.com/ned14/boost.outcome/issues/51 - Licensing to be BSL only - No cmake, just bjam - No git submodules at all - std-flavoured, not boost-flavoured - No code to be brought in except that written by me i.e. a hardcoded whitelist applies. - Contents of Boost repo to only contain material directly relevant to Boost. Nothing else. 3. Under the assumption that error_code_extended's use of a static global ring buffer would be controversial in this review, I hacked a quick and dirty solution expecting to have to remove it. Now we know that few disapprove, a more serious implementation will be needed. https://github.com/ned14/boost.outcome/issues/52 4. Given where Vicente appears to be heading next with expected<T, E1, E2, ...> it may be wise to make the static_checked_* varieties use std::variant<...> for storage when being compiled on C++ 17. https://github.com/ned14/boost.outcome/issues/53 Thanks, Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

10 52

[sort] Timsort review reminder
by Steven Ross 11 Jun '17

11 Jun '17

The review for C++ Timsort in Boost is ongoing and will continue through June 12. I am the review manager. The code can be found here: https://github.com/boostorg/sort/pull/12 To merge it into a local copy of the Boost.Sort library: git checkout -b ZaMaZaN4iK-feature_branch/TimSort develop git pull https://github.com/ZaMaZaN4iK/sort.git \ feature_branch/TimSort If you want to see a proposed version of the Sort library source with Francisco's changes and Timsort included, download the zip file <https://drive.google.com/file/d/0B4s-GPKYVV0jOGx5ckJUTkZzMWM/view?usp=shari…>. Feel free to compare flat_stable_sort with Timsort. Please answer these questions in reply to this thread: 1. What is your evaluation of the Timsort implementation? 2. What is your evaluation of the comments? 3. Did you try to use the library? With what compiler? Did you have any problems? 4. How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? 5. How familiar are you with the details of hybrid and stable sorts? 6. Would you actually use Timsort if it was in Boost.Sort? If so, how is it better than the next best alternative? 7. Do you think Timsort should be included in Boost.Sort? Please ask Alexander Zaitsev any questions you have about Timsort for this review before submitting your final review. Thanks, Steven Ross

11 19

[static_views] [gsoc17] Proposal for a library
by Tom Westerhout 10 Jun '17

10 Jun '17

Hi! I'm Tom Westerhout, one of this year's GSoC interns. The module I'm planning to work on, StaticViews, is essentially a subset of Ranges TS optimised for usage with compile-time homogeneous datasets. It can be used to implement compile-time associative maps, compile-time checking of non-type constraints, and compile-time generation of datasets from other compile-time datasets. Some more explanation and motivating examples are on this page: https://boostgsoc17.github.io/static-map/doc/123_build/html/getting_started… Do you think this would be a worthwhile addition to Boost? Is the choice to use Ranges TS as inspiration for the API wise, or would a different API (please, suggest one) be better? All comments are welcome. Thanks in advance! Tom

2 1

Repeated super project commits
by Daniel James 10 Jun '17

10 Jun '17

Hi, You might noticed that some of today's super project commits were repeated. I was working on a change to do one commit per push event, and it went a bit wrong. It turns out there was an existing bug, which meant the script wasn't always updating the position in the event queue. I fixed it while writing the new version, but assumed it was a new bug that I'd introduced today. So when the new version started, it replayed the events since the position was last updated. I backed out the change and I'm going to try to make the script a bit more robust before changing it again - even without the bug, a similar thing could happen if someone manually updated a submodule in the super project. Because the commits were all in a single push, and the last commit was correct, it shouldn't cause any real problems, but there are a few wonky commits in the history, so sorry about that. Because of the way the script worked, the bug only affects that batch of commits, older commits are fine. Daniel

1 0

Re: [boost] [Boost-testing] [EXTERNAL] Run.py test failure 'minimal' is an invalid property
by Tom Kent 10 Jun '17

10 Jun '17

On Wed, Jun 7, 2017 at 10:39 PM, Belcourt, Kenneth via Boost-Testing < boost-testing(a)lists.boost.org> wrote: > Hi, > > To followup with more info on this issue, testing is broken on master when > building on the Mac, though not sure why. Here’s what works okay: > > python run.py --tag=develop --runner="Sandia-clang-3.8" > --toolset=clang-darwin --pjl-toolset=darwin --bjam-options="-j8” > > and what fails (same command with —tag=master): > > python run.py —tag=master --runner="Sandia-clang-3.8" > --toolset=clang-darwin --pjl-toolset=darwin --bjam-options="-j8" > > The error from the failed master build is the error below. It seems to be > related to the context library use of alias (highlighted below). Are there > perhaps boost build or context changes that need to be merged to master > into order to fix this issue? From what I can tell, testing master on > MacOS is hosed. > > Noel > > > On Jun 7, 2017, at 6:03 PM, Belcourt, Kenneth via Boost-Testing < > boost-testing(a)lists.boost.org> wrote: > > > > /Users/jenkins/slave/workspace/build-tpls/boost_bb/src/build/property.jam:529: > in property.translate from module property > > error: 'minimal' is not a valid property specification > > /Users/jenkins/slave/workspace/build-tpls/boost_bb/ > src/build/property-set.jam:432: in property-set.create-from-user-input > from module property-set > /Users/jenkins/slave/workspace/build-tpls/boost_bb/ > src/build/property-set.jam:484: in property-set.refine-from-user-input > from module property-set > /Users/jenkins/slave/workspace/build-tpls/boost_bb/src/build/targets.jam:1619: > in targets.main-target-requirements from module targets > /Users/jenkins/slave/workspace/build-tpls/boost_bb/src/build/alias.jam:65: > in test-suite from module alias > *../libs/context/test/Jamfile.v2:97: in modules.load from module * > Jamfile</Users/jenkins/slave/workspace/build-tpls/boost_ > root/libs/context/test> > /Users/jenkins/slave/workspace/build-tpls/boost_bb/src/build/project.jam:325: > in load-jamfile from module project > /Users/jenkins/slave/workspace/build-tpls/boost_bb/src/build/project.jam:64: > in load from module project > /Users/jenkins/slave/workspace/build-tpls/boost_bb/src/build/project.jam:145: > in project.find from module project > Jamfile.v2:118: in run-tests from module Jamfile</Users/jenkins/slave/ > workspace/build-tpls/boost_root/status> > Jamfile.v2:171: in modules.load from module Jamfile</Users/jenkins/slave/ > workspace/build-tpls/boost_root/status> > /Users/jenkins/slave/workspace/build-tpls/boost_bb/src/build/project.jam:325: > in load-jamfile from module project > /Users/jenkins/slave/workspace/build-tpls/boost_bb/src/build/project.jam:64: > in load from module project > /Users/jenkins/slave/workspace/build-tpls/boost_bb/src/build/project.jam:145: > in project.find from module project > /Users/jenkins/slave/workspace/build-tpls/boost_bb/src/build-system.jam:535: > in load from module build-system > /Users/jenkins/slave/workspace/build-tpls/boost_bb/src/kernel/modules.jam:295: > in import from module modules > /Users/jenkins/slave/workspace/build-tpls/boost_bb/src/kernel/bootstrap.jam:139: > in boost-build from module > /Users/jenkins/slave/workspace/build-tpls/boost_root/boost-build.jam:17: > in module scope from module > > I see the same error for master on linux and windows runners. Tom

5 10

[review] **NEXT WEEK** Review of Nowide (Unicode) Mon. 12th -> Wed. 21st June
by Frédéric Bron 10 Jun '17

10 Jun '17

Hi Everyone, ** HEADS UP, NEXT WEEK'S REVIEW ** The formal review of Artyom Beilis' Nowide library starts next week (Mon. 12-June to Wed. 21-June). Your participation is encouraged, as the proposed library is uncoupled and focused. Nowadays, everyone needs to handle Unicode but this is very difficult using only the standard library in a platform independant way. Nowide offers a very simple way to handle Unicode the same way on Windows/MacOS/Linux. Key features: * work with UTF-8 in your code, Nowide converts to OS encoding * Easy to use functions for converting UTF-8 to/from UTF-16 * A class to fixing argc, argc and env main parameters to use UTF-8 * UTF-8 aware functions: - stdio.h functions (fopen, freopen, remove, rename) - stdlib.h functions (system, getenv, setenv, unsetenv, putenv) - fstream (filebuf, fstream/ofstream/ifstream) - iostream (cout, cerr, clog, cin) Documentation: http://cppcms.com/files/nowide/html GitHub: https://github.com/artyom-beilis/nowide git clone https://github.com/artyom-beilis/nowide.git Latest tarball: get it from GitHub (Download as zip) NEXT WEEK (when the public review is started): Please post your comments and review to the boost mailing list (preferably), or privately to the Review Manager (to me ;-). 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 most importantly: - Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. For more information about Boost Formal Review Process, see: http://www.boost.org/community/reviews.html Thank you very much for your time and efforts. Frédéric

2 1

[Format] User-defined literals for Boost.Format
by Корсунов Игорь 09 Jun '17

09 Jun '17

1 0

Re: [boost] [property_tree] Issue: erase is corrupting the tree
by lukas.exler＠barclays.com 09 Jun '17

09 Jun '17

The minimal code that crashes is: boost::property_tree::ptree loadedJSON; boost::property_tree::read_json("animalList.json", loadedJSON); auto assoc_it = loadedJSON.find("animals"); auto it = loadedJSON.to_iterator(assoc_it); it = it->second.begin(); it++; // move to second item loadedJSON.erase(it); boost::property_tree::write_json("shorterList.json", loadedJSON); Where content of "animalList.json" file is: { "animals" : ["fox","dog","cat"] } -----Original Message----- From: Mert Büyüktuncay [mailto:mert.buyuktuncay@sestek.com] Sent: Tuesday, June 06, 2017 9:22 AM To: boost(a)lists.boost.org Cc: Exler, Lukas: IT (PRG) Subject: RE: [property_tree] Issue: erase is corrupting the tree This mail originated from outside our organisation Do you use "it" iterator after the call to erase in that case you shall use it = loadedJSON.erase(it); instead of it++ If this is not your problem you can share a little more code for us to see in detail what is happening here. May be the code up to the point where "write_json" is being called. Regards Mert -----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Lukas via Boost Sent: Monday, June 5, 2017 4:08 PM To: boost(a)lists.boost.org Cc: lukas.exler(a)barclays.com Subject: [boost] [property_tree] Issue: erase is corrupting the tree I have following JSON structure loaded into boost::property_tree: { "animals" : ["fox","dog","cat"] } I'm trying to delete the second item from the array by: auto assoc_it = loadedJSON.find("animals"); auto it = loadedJSON.to_iterator(assoc_it); it = it->second.begin(); it++; // move to second item loadedJSON.erase(it); After this, when I try to use boost::property_tree::write_json to write the JSON back the app crashes. Do I use the property tree in a wrong way, or is there a bug? Thanks, Lukas. _______________________________________________ This message is for information purposes only, it is not a recommendation, advice, offer or solicitation to buy or sell a product or service nor an official confirmation of any transaction. It is directed at persons who are professionals and is not intended for retail customer use. Intended for recipient only. This message is subject to the terms at: www.barclays.com/emaildisclaimer. For important disclosures, please see: www.barclays.com/salesandtradingdisclaimer regarding market commentary from Barclays Sales and/or Trading, who are active market participants; and in respect of Barclays Research, including disclosures relating to specific issuers, please see http://publicresearch.barclays.com. _______________________________________________ _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost Bu elektronik posta mesajı ve ekleri sadece gönderildiği kişi veya kuruma özeldir ve gizli bilgiler içerebilir. Eğer bu mesajı hataen aldıysanız lütfen bu durumu gönderen kişiye derhal bildiriniz ve mesajı sisteminizden siliniz. Eğer doğru kişiye ulaşmadığını düşünüyorsanız, bu mesajın gizlenmesi, yönlendirilmesi, kopyalanması veya herhangi bir şekilde kullanılması yasaktır. Internet iletişiminde güvenlik ve hatasız gönderim garanti edilemeyeceğinden, mesajın yerine ulaşmaması, geç ulaşması, içeriğinin bozulması ya da mesajın virüs taşıması gibi problemler oluşabilir. Gönderen taraf bu tip sorunlardan sorumlu tutulmaz. SESTEK Ses ve İletişim Teknolojileri A.Ş. www.sestek.com<http://www.sestek.com> This e-mail message and any attachments are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this message in error, please notify the sender immediately and delete it from your system. If you are not the intended recipient you are hereby notified that any dissemination, forwarding, copying or use of any of the information is prohibited. Internet communications cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, arrive late or contain viruses. The sender therefore does not accept liability for any errors or omissions in the context of this message which arise as a result of Internet transmission SESTEK INC. www.sestek.com <http://www.sestek.com> Bu elektronik posta mesajı ve ekleri sadece gönderildiği kişi veya kuruma özeldir ve gizli bilgiler içerebilir. Eğer bu mesajı hataen aldıysanız lütfen bu durumu gönderen kişiye derhal bildiriniz ve mesajı sisteminizden siliniz. Eğer doğru kişiye ulaşmadığını düşünüyorsanız, bu mesajın gizlenmesi, yönlendirilmesi, kopyalanması veya herhangi bir şekilde kullanılması yasaktır. Internet iletişiminde güvenlik ve hatasız gönderim garanti edilemeyeceğinden, mesajın yerine ulaşmaması, geç ulaşması, içeriğinin bozulması ya da mesajın virüs taşıması gibi problemler oluşabilir. Gönderen taraf bu tip sorunlardan sorumlu tutulmaz. SESTEK Ses ve İletişim Teknolojileri A.Ş. www.sestek.com<http://www.sestek.com> This e-mail message and any attachments are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this message in error, please notify the sender immediately and delete it from your system. If you are not the intended recipient you are hereby notified that any dissemination, forwarding, copying or use of any of the information is prohibited. Internet communications cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, arrive late or contain viruses. The sender therefore does not accept liability for any errors or omissions in the context of this message which arise as a result of Internet transmission SESTEK INC. www.sestek.com <http://www.sestek.com> _______________________________________________ This message is for information purposes only, it is not a recommendation, advice, offer or solicitation to buy or sell a product or service nor an official confirmation of any transaction. It is directed at persons who are professionals and is not intended for retail customer use. Intended for recipient only. This message is subject to the terms at: www.barclays.com/emaildisclaimer. For important disclosures, please see: www.barclays.com/salesandtradingdisclaimer regarding market commentary from Barclays Sales and/or Trading, who are active market participants; and in respect of Barclays Research, including disclosures relating to specific issuers, please see http://publicresearch.barclays.com. _______________________________________________

2 1

What is the process for adding a library suggestion?
by Adrian H 07 Jun '17

07 Jun '17

I have a suggestion for adding something to the boost library. It is simple but I believe that it would be useful. Do I just post it here or is there some process? Thanks, A -- ======================================== Adrian Hawryluk BSc. Computer Science ---------------------------------------- Specialising in: OOD Methodologies in UML OOP Methodologies in C, C++ and more RT Embedded Programming GUI Development ========================================

3 2

svn.boost.org schedule maintenance - DOWN TIME
by Michael Caisse 07 Jun '17

07 Jun '17

Hi all - svn.boost.org is scheduled for maintenance on June 8 from 1700 - 1900 UTC. Expect outages for Trac during this time. Happy coding! michael -- Michael Caisse Ciere Consulting ciere.com

1 0

[review] Outcome Review Report
by charleyb123 . 07 Jun '17

07 Jun '17

# Boost.Outcome REVIEW REPORT In conclusion to the Outcome Library Review (19-May to 02-June, 2017): The library is REJECTED. Rejection is principally due to: (1) Unresolved key behavior at conclusion of the review period (2) Misunderstanding/disagreement regarding library’s intended purpose (3) Unclear precedent/implications from accepting this library in its current configuration into the Boost distribution The following weighed heavily to consider accepting the library into Boost: (a) The library demonstrates solutions to fundamental issues (error and exception handling) (b) The library effectively addresses constraints to serve the needs of several user-bases (c) New paradigms/idioms are enabled (d) Implementation is of high quality Some 20+ participants sent 850+ email messages to the public list discussing the Outcome library, plus additional (non-trivial) off-list discussion. Public reviews sent to the list were from: *- Paul Bristow -- ACCEPT (Tue-23-May) *- Deniz Bahadir -- ACCEPT (Wed-24-May) *- Robert Ramey -- REJECT (Fri-26-May) *- Peter Dimov -- REJECT (Sun-28-May) *- Emil Dotchevski -- REJECT (Sun-28-May) *- Vicente J. Botet Escriba -- REJECT (Tue-30-May) *- Andrzej Krzemienski -- REJECT (Wed-31-May) *- Gavin Lambert -- REJECT (May 31) *- Bjorn Reese -- REJECT (Fri-02-June) The remainder of this report is a summary of discussion with select issues specific to the Outcome library, plus some possible topics for further consideration by the Boost Community and Boost Steering Committee. This further elaboration is not intended to be comprehensive regarding issues raised during the review; Rather, it is to: (a) Provide historical “summary/context” for the level of discussion exhibited during this review, and which contributed to the final decision; (b) Highlight issues that may provide assistance in considering “readiness” for a later review for an evolved form of this library (or for a similar library intending to address the same domain); (c) Provide “discussion-points” for the Boost Community and Boost Steering Committee regarding possible future evolution or guidance associated with Boost tooling, distribution, and individual library dependencies (related to topics raised during this review). The conclusions will be: (1) Outcome Library Author: Consider re-submitting for review when... (a) Key behavior/design issues are resolved (see below) (b) Integration plan with Boost is more clear (and consistent with Boost Steering Committee Guidance) (2) Boost Community / Boost Steering Committee: Consider providing guidance to future library submissions regarding... (a) Attempted dual-license, this submission attempted: *- BSL+Apache2 dual-license (b) “Extra-build-steps”, this submission attempted: *- Custom preprocessing to “generate-source” (to significantly improve compile-time speed) (Note: During review, a template-based solution was proposed as a possible replacement mechanism, but code-gen should probably be explicitly addressed) (c) Class/namespace versioning, this submission attempted: *- Stable ABI/versioning mechanism through a framework provided with this submission (to enable multiple versions of this library used by differing third-party libraries to correctly coexist within the same binary) (d) Use of outside source; use of git (git-submodules), this submission attempted: *- Dependency to an outside (git-submodule) lib archive (gsl-lite: https://github.com/martinmoene/gsl-lite.git ) (e) Use of (non-test/Jamfile) for test, this submission attempted: *- Custom test mechanism (because “Boost.Test” won’t work with C++ exceptions disabled; lib needed “boost-lite” to run the test suite) (f) Use of CMake, Dependency upon Boost, this submission attempted: *- No Boost dependency (but provided a “boost-lite” shim to coexist in user-workspaces with-or-without Boost, providing common cmake machinery and test-running) # SUMMARY OVERVIEW As demonstrated through the volume and depth of discussion, the library attracted wide interest, which is consistent with a perception that it attempts to address an active need. Comments suggested the library’s purpose (enabling public APIs to pass <value|error|exception>) was useful, and that enabling a shared handling of <error|exception> to be somewhat novel. Several participants further suggested that the library attempts to serve a role as a “fundamental” library: to provide vocabulary types and pose new idioms, to be used in public APIs as a common <error|exception> exchange mechanism. One reviewer commented that the library’s documentation under-sold the library’s motivation, suggesting it compelling for: *- Cases where errors cannot be propagated by throwing exceptions (e.g., within callbacks where an error value is provided [e.g., ASIO]); *- When passing values between threads, such as in an Actor model where a message queue handles return values (e.g., pass outcome<T> instead of an std::error_code to handle <error|exception> in addition to desired <T>) Many/most reviewers that voted REJECT commented that they would like a similar library to be accepted, or perhaps an evolved form of this library after necessary changes (see below). To accept the importance of the domain which the library attempts to address, one need not agree with the design nor implementation of Outcome (indeed, the library is rejected in its current form at the conclusion of this review). Rather, this summary assertion is that the Outcome proposal successfully demonstrates a need for such a fundamental (and community-endorsed) solution (or direction) for error handling. # ISSUE: Unresolved key behavior at conclusion of the review period Key behavior (or design) issues that did not reach consensus by the end of the review period: (1) Narrow vs. Wide contracts -- consensus is not reached (2) Empty-state (allowed?) remains controversial (3) Ring-buffer appears uncontroversial; but perhaps needs additional scrutiny (a) Separate library implementation (for reuse elsewhere, and to enable evolution without touching the ‘result<>’/’outcome<>’ API)? (b) Bigger buffer? Some of the difficulties in this evaluation likely trace to the (in-progress) evolution of the proposed ‘std::expected<>’ (also discussed during this review). A future Outcome review would likely benefit from the clarity provided by fully resolved semantics for ‘std::expected<>’. # ISSUE: Misunderstanding/disagreement regarding library’s intended purpose The Outcome library attempts to define a paradigm and propose idioms in <error|exception> handling, where few can successfully argue that current practice, libraries, and idioms are sufficient. The review concluded that Outcome proposes a new paradigm that is demonstrated to be useful and effective. However, disagreement exists on the nature of that framework: PURPOSE: Outcome is a unified/universal <error|exception> handling framework for use in public APIs; (a) ...enabling user-customization to address domain-specific constraints ...versus... (b) ...for possible future consideration in a C++ Standards Track, likely within <system_error> The Library Author intended (a), while multiple reviewers advocated for (b). This disagreement-in-vision resulted in many difficult discussions during the review, and ultimately lack of consensus for several important API and design decisions (due to the corresponding implied future limitations). For example: Static-checked vs. Runtime-checked behavior. The library-as-presented attempts to serve both, citing orthogonal user bases with differing (latency) constraints, such as “with-or-without” runtime overhead, and “with-or-without” Undefined Behavior (UB). Current implementation enables integration of arbitrary third-party libraries (each with their own preferred error handling strategy and tradeoffs), with zero-cost conversion and inter-operation. However, this *significantly* complicates the design: The user composes ‘result<>’ and ‘outcome<>’ types with regards to module-specific static or runtime type safety and performance requirements, which (transparently) propagate through the library internals and across threads and public APIs to external modules. In contrast, a C++ Standards Track implementation is likely much simpler, introducing one-or-two vocabulary types merely parameterized on ‘<T>’, providing a simplified (and “standard”) mechanism to bridge <T|error|exception> transport across third-party module boundaries. For example, in advocating for a “Standards-Track” vocabulary type, reviewers argued for a mechanism that would enable user-libraries to obsolete the duplicate “throw/no-throw” APIs with a single API: R filesystem_api(); // throws filesystem_error R filesystem_api( error_code& ec ) noexcept; ...becomes... outcome<R> filesystem_api(); // <R|error|exception> The contrast between the two visions can more distinctly be termed: (a) “Multi-Modal” Usage -- Many varieties of usage style within the API is necessary, because there are a multitude of ways for library abstractions to be used in composition patterns due to domain-specific constraints (likely with some idioms not yet discovered, or not yet in widespread use) (b) “Single-Modal” Usage -- One (single) clean design and use model is encouraged The Library Author states that normal C++ design principles should prefer (b), but due to the vocabulary-type nature of the problem and domain-specific constraints encountered by real-world users, this particular library was forcefully evolved into (a). It is perhaps ironic that the suitability of a proposed library as providing vocabulary types and possibly evolving into a future standard demands that the Library Author change the library’s stated purpose due to this potential popularity; but that seems consistent with the current circumstance. The Library Author (of course) should have authority to characterize the actual intended use-case and resulting behavior provided through the authored work; with the Review Process providing analysis and feedback regarding possible missed opportunity resulting from those decisions. However, this review’s conclusion seems to encounter the curious scenario where the vision itself remains in conflict. Of course, these very differing outlooks resulted in some apparent “impasses” or circular discussions regarding type-safety (and number-of-types), wide or narrow contracts, optimization opportunities, “too-big” (or “cluttered”) interfaces, implicit or explicit conversion, the need for iterator and visitor patterns on ‘outcome<T>’, and the “empty” state and sentinel values. In support of the “Multi-Modal” design, the Library Author posits three main use patterns exist for error-handling objects-returned, and that a single design can serve only two at best: (Quoting the Library Author): > <quote> > (1) User wants failure reason type to be local to only the code to which > it applies. So think custom E type, nonconvertible to any other E type, and > E is never error_code nor exception_ptr. They specifically want to keep > failure handling local a small patch of code e.g. constexpr evaluation > contexts. > > All-narrow observers make sense for this use case as object usage is > tightly integrated to the code using it, and failure is handled entirely > locally. > > (2) User wants failure reason type to be globally understood and will be > choosing either E = std::error_code, or E = std::exception_ptr. They > specifically want failure handling to be able to traverse any or all code, > just like C++ exception throws. This is where Outcome was primarily aimed > at. > > All-wide observers make sense for this use case, as due to handling a wide > degree of uncertainty, most failure handling code is *generic* i.e. we test > for some specific failure causes, and for everything else we either ignore > or hand it off to other code to handle. > > (3) User wants to write functional programming logic using the basic > vocabulary of Maybe, Either and i/o monads and basic operators of bind, > fmap, do etc and probably some subset or refinement of Hana for the > collections monads, though my GSoC student may be making the Ranges TS a > choice here as well later this summer. > > All-narrow observers make sense for this use case as the monadic operators > ensure your function will never be called with the wrong state. > </quote> The Outcome library uses a, “single implementation, multiple personalities” to solve this problem, and makes the intentional decision to attempt targeting (2). # ISSUE: Unclear precedent/implications from including this library in its current configuration into the Boost distribution The library in its current configuration is perceived as setting precedent for changes to the Boost distribution, which reviewers commented added complexity to their analysis. Specific topics: *- Dual-license (BSL and Apache2) confused reviewers *- Add bjam support (author agreed) *- Packaging relied upon git-submodules to an outside lib archive (gsl-lite, https://github.com/martinmoene/gsl-lite.git) *- Library does tricks with the preprocessor to avoid significant compile-time costs; but these tricks were commented by some reviewers as being unnecessarily complex. *- The Author found these tricks necessary to reach reasonable compile metrics for large projects using Outcome in their public APIs, and believes some mechanism must address this build-speed-need. A proposed metaprogramming mechanism may eliminate the need for these preprocessor tricks in the future. # FINAL THOUGHTS In the very active years of “Classic Boost” (such as 2004-2008), fundamental libraries had a good chance of becoming vocabulary types that attempt to establish new Best Practice for the industry (and not merely be “just another library”). This awareness drove much of the review discussion, and underscored the importance of experimentation and “lessons learned” to result in a library that offered: (1) behavior and idioms that are understood; and (2) sufficient experience to make use recommendation to the wider user base in contrast to existing alternative approaches. Consistent with this historical context, it should be relatively uncontroversial to recognize that the Outcome library does not reach that threshold at this time (so it is rejected). However, this review also suggests: (1) A similar library is needed; (2) The community lacks agreement on direction (e.g., “Multi-Modal” vs. “Single-Modal”) In support of experimentation and to expand on our “lessons-learned”, it seems somewhat obvious that Outcome provides a strongly-implemented Multi-Modal low-latency library that will assist the community in gaining experience with these idioms proposed. Since conclusion of the review period, discussion continues (on and off-list) regarding possible evolution to the Outcome library, related to feedback provided during this review, and related to discussions of design evolution for pertinent libraries (e.g., possible changes to std::expected<>, and evolution of a never-empty ‘variant2<>’). It is promising that such a strong library as Outcome continues to receive critical attention and evolution by multiple interested parties. Great thanks to the Boost Community for their tremendous efforts, disciplined review, and detailed exploration of topics in considering this library submission. Sincerest appreciation to Niall Douglas (Author of the Outcome Library) for pushing the envelope for low-latency <error|exception> handling and for submitting his work to the Boost Review process. -- charley (Outcome Review Manager) If there be any in this assembly, any dear friend of Caesar's, to him I say that Brutus' love to Caesar was no less than his. If then that friend demand why Brutus rose against Caesar, this is my answer: not that I loved Caesar less, but that I loved Rome more. (3.2.19-24)

7 8

Deprecation indication
by Raffi Enficiaud 06 Jun '17

06 Jun '17

Hi, Is there anything in eg. boost.config or other that expands to a compiler indication that something is "deprecated", possibly with a message that appears only once? It may expand to `[[deprecated]]` or `[[deprecated("reason")]]` if available and supported, or `__declspec(deprecated)` / `__declspec(deprecated("reason"))`, `__attribute__ ((deprecated))` ... I could not find anything in boost.config. Has anyone an example of this in boost? Is there any indication/policy in boost about deprecation? Thanks in advance, Raffi

1 0

[Nowide] Links to source code
by Artyom Beilis 06 Jun '17

06 Jun '17

Hello Frederic and Boost Developers. I had noticed that the links to the source and git repository at http://www.boost.org/community/review_schedule.html are incorrect. It should be links to github https://github.com/artyom-beilis/nowide Can it be fixed before the review begins in order to prevent confusion? Thanks, Artyom Beilis

1 0

[outcome] High level summary of review feedback accepted so far
by Niall Douglas 05 Jun '17

05 Jun '17

Some reviewers have asked what form Outcome will take in the near future. The following is a high level summary of the changes already made on develop branch or will be made according to https://github.com/ned14/boost.outcome/issues logged from review feedback. I have left out some minor issues, this lists just the major changes. This should help reviewers to decide whether to recommend acceptance or rejection. If there are any questions, please do ask. Major design changes: ===================== - option<T> to be removed https://github.com/ned14/boost.outcome/issues/48 - outcome<T> and result<T> will have their empty state removed, and all observers gain narrow contracts. Default construction is disabled. https://github.com/ned14/boost.outcome/issues/44. Example: ``` result<Foo> v(make_errored_result(std::errc::invalid_argument)); assert(v.has_error()); // true assert(!v.has_value()); // true // As if Foo(reinterpret_cast<Foo &&> // (error_code_extended(std::errc::invalid_argument)); Foo f(std::move(v.value())); assert(v.has_error()); // still true assert(!v.has_value()); // still true ``` (NOTE: expected<T, E> will track whatever LEWG Expected does, but it differs from what will become result<T> by having a wide contract on .value() and narrow contracts on operator*(), .error(), operator->(). result<T> will have narrow contracts on everything, it is basically a thin wrap of std::variant<T, error_code_extended> except with strong never empty warranty) - New typedefs outcome_e<T> and result_e<T> are identical to outcome<T> and result<T> except for adding a formal empty state. Observer contract slightly widens, an attempt to use an empty object throws a bad_outcome_access exception. Implicit conversion from non-empty-capable varieties is permitted to empty-capable varieties, but not the other way round. Default construction is to **empty**. https://github.com/ned14/boost.outcome/issues/44 - New typedefs checked_outcome<T>/checked_result<T>, checked_outcome_e<T>/checked_result_e<T> are added. These mirror the editions just described, but checks and default actions occur on all observer usage so hidden reinterpret_cast<> never occurs. Implicit conversion from non-checked varieties is permitted to checked varieties, but not the other way round. https://github.com/ned14/boost.outcome/issues/47. Examples: ``` // Note result<T> implicitly converts to checked_result<T>, but not // the other way round. So we can use same make_errored_result(). checked_result<Foo> v(make_errored_result(std::errc::invalid_argument)); assert(v.has_error()); // true assert(!v.has_value()); // true // .value() throws std::system_error( // std::make_error_code(std::errc::invalid_argument)); Foo f(std::move(v.value())); ``` ``` checked_result<Foo> v(make_valued_result(Foo())); assert(!v.has_error()); // true assert(v.has_value()); // true // .error() returns a default constructed (null) error_code_extended // when result is valued to indicate "no error here" error_code_extended ec(std::move(v.error())); assert(!ec); // true ``` - The presented library self generates using lots of preprocessor based multiple #include's to stamp out finished editions of implementation. The git repo partially preprocesses this into a nearly finished edition for minimum compile time load for end users. Due to the many more varieties of outcome<T> and result<T> provided, the preprocessor machinery would be replaced with a template based machinery instead. I will look into making optional use of extern template and a static library to retain minimum compile time load, but header only usage will remain possible. Smaller design changes: ======================= - tribool stuff to go away in default configured build. https://github.com/ned14/boost.outcome/issues/22 - .get*() functions will be removed. https://github.com/ned14/boost.outcome/issues/24 - Don't include <windows.h> on winclang. https://github.com/ned14/boost.outcome/issues/39 Documentation changes: ====================== - Licence boilerplate missing on some files. https://github.com/ned14/boost.outcome/issues/38 - Reference API docs need to spell out exact preconditions, postconditions and semantics per API. https://github.com/ned14/boost.outcome/issues/26 - Reference API docs need to describe types void_rebound, *_type and raw_*_type in detail. https://github.com/ned14/boost.outcome/issues/29 - User overridable macros which throw exceptions and provide customisation points have vanished from the docs somehow. https://github.com/ned14/boost.outcome/issues/35 - Landing page and introduction to be broken up into bitesize single page chunks. https://github.com/ned14/boost.outcome/issues/41 Still to be decided: ==================== - Should *_e() varieties provide convenience .get(), .get_error(), .get_exception() which returns T, error_code_extended and std::exception_ptr by value moved from internal state, resetting state afterwards to empty? These would mirror future.get()'s single shot observers. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

10 104

DocBook toolchain: Disable auto toc for just one section's children?
by Vinnie Falco 05 Jun '17

05 Jun '17

My documentation has a reference section whose children are themselves sections automatically generated by a doxygen->xml->xslt->QuickBook chain. I want an automatically generated table of contents, but when I turn that on I get hundreds of entries for all of the individual classes and functions in the reference. Is there a way to disable just the child sections of my Reference section? Perhaps marking the section somehow and passing an xsl:param in the Jamfile or something? This would really help to put that last bit of polish on these docs. I noticed that Boost.Asio docs had the same problem, so the author just disabled the auto-toc and created a very small, manual one. Not the same. Ideas?

3 5

[property_tree] Issue: erase is corrupting the tree
by lukas.exler＠barclays.com 05 Jun '17

05 Jun '17

I have following JSON structure loaded into boost::property_tree: { "animals" : ["fox","dog","cat"] } I'm trying to delete the second item from the array by: auto assoc_it = loadedJSON.find("animals"); auto it = loadedJSON.to_iterator(assoc_it); it = it->second.begin(); it++; // move to second item loadedJSON.erase(it); After this, when I try to use boost::property_tree::write_json to write the JSON back the app crashes. Do I use the property tree in a wrong way, or is there a bug? Thanks, Lukas. _______________________________________________ This message is for information purposes only, it is not a recommendation, advice, offer or solicitation to buy or sell a product or service nor an official confirmation of any transaction. It is directed at persons who are professionals and is not intended for retail customer use. Intended for recipient only. This message is subject to the terms at: www.barclays.com/emaildisclaimer. For important disclosures, please see: www.barclays.com/salesandtradingdisclaimer regarding market commentary from Barclays Sales and/or Trading, who are active market participants; and in respect of Barclays Research, including disclosures relating to specific issuers, please see http://publicresearch.barclays.com. _______________________________________________

1 0

[outcome] non-interface-related concerns
by Andrzej Krzemienski 05 Jun '17

05 Jun '17

The discussion mostly revolves around the design of the interface of `outcome::expected` and even `std::expected`. My questions here are about the way this library will be distributed to users. And I am uncomfortable with the situation. I am not necessarily saying it is wrong, but I do not understand what is going on here. 1. The current GitHub repository consists of sub-repos. Do you (Niall) plan to have it like this when the library is accepted? Is it relevant? 2. This macro BOOST_OUTCOME_DISABLE_PREPROCESSED_INTERFACE_FILE, it controls whether I use this "preprocessed" file versus if I use... what? Normal header files? What is gained by this preprocessed file? Not having to include more than one header, or something else? Can I get different results when compiling with and without this macro? 3. I am recommended to use this macro BOOST_OUTCOME_V1_NAMESPACE. I am told it has something to do with ABI stability? Can you elaborate on how this guarantees ABI stability. Or is its purpose different? I have a certain problem with understanding this philosophy. A couple of days back, I reported the compilation failure in MinGW. I can see that the issue (https://github.com/ned14/boost.outcome/issues/36) is reorted as fixed in branch 'develop'. I would like to confirm that the bug is fixed. I checkout branch develop. There is no branch develop for the sub-repos, so what am I supposed to checkout, master, or some particular commit? I went with master. I do not understand a lot of CMake, but since it is a header-only library, I assume that I can just #include the file "include/boost/outcome.hpp", and my programs (compiled manually) should compile. But the only change in the commit that was supposed to fix the bug, was in a .cmake file, so I cannot see how it would help fix a header only library. Also, would the fix be visible in a "precompiled" header, or normal headres, or both? I am not complaining about this particular fix. I would like to know how in this system of mcros, sub-modules and preprocessed headers, I can figure out what changes will be observed in my program, when I see a particular change in git sub-repo. Regards, &rzej;

10 42

[outcome] Review
by Bjorn Reese 03 Jun '17

03 Jun '17

I apologize in advance for the rather meek review below; I did not have the time to be more thorough. > - What is your evaluation of the design? The review discussions provided many insightful arguments in favour or against various aspects of the design, and I have not formed a final opinion about most of these. I do believe that fixing E for result<T> to error_code is the right decision. I would prefer a design without an empty state, because we already have a vocabulary type for it. The choice of C++14 seems motivated solely by performance considerations. A slower C++11 version should be considered. > - What is your evaluation of the implementation? I did not have enough time to review it. > - What is your evaluation of the documentation? The introduction (Description) only provides a vague description of the purpose of the library. For example, it does not mention that its types are used to carry either a value or an error. Instead, it assumes that the reader can derive this from prior familiarity with expected<T> (or Rust.) The first motivating example is too large (as indeed are the examples in the tutorial.) Instead I suggest a "Tony table" that shows the essense of the library (either value or error.) For example: Before: FILE *file = fopen("myfile", "r"); if (!file) throw std::system_error(errno, std::system_category(), "Error delivered out-of-band by errno"); fclose(file); After: result<FILE *> file = fopen_wrapper("myfile", "r"); if (!file) throw std::system_error(file.error(), "Error delivered in-band by file.error()"); fclose(file.value()); This may not look overly convincing, but it does demonstrate the either value or error aspect in a few lines. The library is weakly motivated -- the motivation boils down to a less expensive alternative to throwing exceptions. A stronger motivation would have been to mention use cases were errors cannot be propagated by throwing exceptions. Here are two examples: One motivating use case where exceptions cannot be throw are callbacks, such as Boost.Asio asynchronous handlers. Here the return value is not returned by the asynchronous operation (the initiating function), but will be passed to the provided callback once the operation completes. In other words, the following synchronous operation return_type operation(arg_type, error_code&); is turned into this asynchronous operation: void async_operation(arg_type, void (*)(return_type, error_code)); Exceptions cannot be thrown into the functions (here the callback), so errors have to be passed as arguments (whether error_code or exception_ptr.) The above works if the return_type has a reasonable "unengaged" value that can be passed as the first argument in case of an error. While this is true for Boost.Asio, where return_type is a std::size_t, it is not necessarily true in general. A much better solution is to pass an outcome<T>, result<T>, or expected<T>: void async_operation(arg_type, void(*)(result<result_type>)); Another motivating use case is passing results between threads. For instance, in the Actor model of concurrency information is passed between actors/threads via a message queue. Some of these messages are replies to requests that may or may not have failed. A queue containing one of the Outcome types is well-suited for this kind of interaction. Apart from the above-mentioned shortcomings, I found the remainder of the documentation quite readable. I did not find the inheritance diagrams in the reference documentation useful though. > - What is your evaluation of the potential usefulness of the library? The idea of an either-value-or-error return type is very useful. > - Do you think the library should be accepted as a Boost library? No, not in its current form. I have two reasons for this rejection. First, some of the design discussions (especially on narrow/wide contracts) are not settled yet, so it would be premature to vote for the design. Second, whilst the lastest offer from the author about a fully-fledged Boost.Outcome repository without a dependency on the non-reviewed library called "boost-lite" is a step in the right direction, it is unclear to me how that repository will end up. Having been surprised by the current submission and the author's opinions, I will defer any vote of acceptance until the a repository is submitted for review.

2 2

[outcome] expected, etc. why are these assignable
by Robert Ramey 03 Jun '17

03 Jun '17

It just occurred to me that for a similar component I created some time ago for my own purposes, I (intentionally?) support of the assignment operator. Copy construction was permitted however. So the only way to use the component is: checked_result<int> = function(...); something void function(checked_result & cr, ....) will be the same as void function(const checked_result & cr, ...) because checked_result only contains const functions. That is, once constructed, it's immutable. Personally I never use an interface which passes a mutable type to a function. To me it violates the mathematical idea of what a function is. Doesn't this simplify things? Doesn't this eliminate the whole questions about about empty state, etc. Doesn't this better model the "mondad" concept we're trying to leverage on. And why the hell are we modifying and an object designed to model a result in the first place? It doesn't make logical sense in terms of we expect a "result" to be. I plunk down my money (a function) and ask for a pepperoni pizza. Either they say they don't have pepperoni and give me my money back or give me a pizza. I don't think of modifying this result - it's an artifact of history. And wouldn't making these things immutable, eliminate a large part of the whole controversy? Just a thought. I think sometimes something is hard because we haven't thought enough about what we're really trying to do - what problem we're trying to solve. Robert Ramey

6 16

[outcome] To variant, or not to variant?
by Gavin Lambert 03 Jun '17

03 Jun '17

I probably should have thought of asking this earlier, but it occurs to me now that my own mental model of how an "outcome"-ish type should act is probably not suited to variant storage at all. So just out of curiosity I thought I'd ask whether people prefer this sort of interface: template<typename T> class outcome { public: bool has_value() const { return m_storage.has<T>(); } T& value() { return m_storage.get<T>(); } bool has_error() const { return m_storage.has<error_code>(); } error_code& error() { return m_storage.get<error_code>(); } bool has_exception() const { return m_storage.has<exception_ptr>(); } exception_ptr& exception() { return m_storage.get<exception_ptr>(); } void set(none_t) { m_storage = none; } void set(const T& val) { m_storage = val; } void set(error_code err) { m_storage = err; } void set(exception_ptr ep) { m_storage = ep; } private: variant<none_t, T, error_code, exception_ptr> m_storage; }; Or this sort of interface: template<typename T> class outcome { public: bool has_value() const { return !!m_value; } T& value() { ensure(); return m_value.value(); } //bool has_error() const { return !!m_error; } const error_code& error() const { return m_error; } //bool has_exception() const { return !!m_exception; } const exception_ptr& exception() const { return m_exception; } void ensure() const { if (m_exception) { rethrow_exception(m_exception); } if (m_error) { throw system_error(m_error); } } void set(none_t) { m_value = none; m_error = error_code(); m_exception = nullptr; } void set(const T& val) { m_value = val; m_error = error_code(); m_exception = nullptr; } void set(error_code err) { m_value = none; m_error = err; m_exception = nullptr; } void set(exception_ptr ep) { m_value = none; m_error = ep ? error_code(errc::has_exception) : error_code(); m_exception = ep; } private: optional<T> m_value; error_code m_error; exception_ptr m_exception; }; (Don't get too hung up on the specifics. This is a sketch, not a real implementation. I've obviously omitted things that a real implementation would need such as more const methods and move support, and construction and assignment rather than using set methods. The focus is on variant vs. non-variant.) Anyway, the point is that this could actually transport multiple things; in particular as above both an error_code and an exception_ptr; perhaps set(error_code) could construct an exception as well, although I've explained elsewhere why I don't like that option. Perhaps this could even be exposed even more so that user code could explicitly provide both a value and an error -- think "here's a value, but it was truncated" or "here's the 5 values you asked for, but there's more", both fairly common in system APIs. Or for things like ambiguous matches where you still return the most likely candidate. Or dictionary insertion (duplicate key, but here's the value that's already there). Or many more such examples. (Though obviously in this case value() couldn't call ensure(). But that should make some people happy.) Also note has_error() and has_exception() don't even need to be provided in this version since you can always call error() and exception() in a boolean context anyway, with the same result. (Or actually a slightly better result than the implementation shown here.) The obvious downside is that it now uses more storage, which might hinder some inlining cases.

9 63

[sort] Timsort review
by Steven Ross 03 Jun '17

03 Jun '17

The review for C++ Timsort in Boost will commence tomorrow, June 3, and continue through June 12. I am the review manager. The code can be found here: https://github.com/boostorg/sort/pull/12 To merge it into a local copy of the Boost.Sort library: git checkout -b ZaMaZaN4iK-feature_branch/TimSort develop git pull https://github.com/ZaMaZaN4iK/sort.git \ feature_branch/TimSort If you want to see a proposed version of the Sort library source with Francisco's changes and Timsort included, download the zip file <https://drive.google.com/file/d/0B4s-GPKYVV0jOGx5ckJUTkZzMWM/view?usp=shari…>. Feel free to compare flat_stable_sort with Timsort. Please answer these questions in reply to this thread: 1. What is your evaluation of the Timsort implementation? 2. What is your evaluation of the comments? 3. Did you try to use the library? With what compiler? Did you have any problems? 4. How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? 5. How familiar are you with the details of hybrid and stable sorts? 6. Would you actually use Timsort if it was in Boost.Sort? If so, how is it better than the next best alternative? 7. Do you think Timsort should be included in Boost.Sort? Please ask Alexander Zaitsev any questions you have about Timsort for this review before submitting your final review. Thanks, Steven Ross

1 0

[poly_collection][VS 2017] Potential compiler bug
by Joaquin M López Muñoz 02 Jun '17

02 Jun '17

Hi, Boost.PolyCollection tests have started to cycle and I found VS 2017 aka MSVC 14.1 fails at test_algorithm.cpp: http://tinyurl.com/yb4zdkys whereas this test compiles and runs OK with VS 2015 aka MSVC 4.0 (_MSC_FULL_VER = 190023026). I've distilled down the problem to this test case: #include <algorithm> #include <utility> template<typename... Ts> struct all_of { template<typename... Args> auto operator()(Args&&... args)const-> decltype(std::all_of<Ts...>(std::forward<Args>(args)...)) { return std::all_of<Ts...>(std::forward<Args>(args)...); } }; int main() { int x; all_of<> alg; alg(&x,&x,[](int){return true;}); } which works fine with GCC and VS 2015 but fails in webcompiler.cloudapp.net with Compiled with /EHsc /nologo /W4 /c main.cpp main.cpp(9): error C3546: '...': there are no parameter packs available to expand main.cpp(18): note: see reference to class template instantiation 'all_of<>' being compiled (_MSC_FULL_VER = 191125331, which I think is VS 2017.3 or something). This looks like a regression to me. Deleting the ->decltype(...) bit makes the problem go away but I need to stay within C+11. * Can someone (STL?) confirm this is indeed a compiler bug? * Any rewording of the code that might be generally applicable to C++11 so that I don't have to include a specific workaround for VS 2017? Thank you, Joaquín M López Muñoz

2 1

[outcome] Outcome Review Period Closes Today (Fri-02-June)
by charleyb123 . 02 Jun '17

02 Jun '17

Hello Everyone, Today concludes the Outcome library review period (Fri-02-June-2017). Great thanks to all that invested so much time and effort to explore in such a disciplined and professional manner the dark corners of error/exception composition and a paradigm/API/implementation proposed by the Outcome library. Your efforts are truly appreciated. Reviews sent to the public list are the following (PLEASE contact me if I've missed your review): *- Paul Bristow (Tue-23-May) *- Daniz Bahadir (Wed-24-May) *- Robert Ramey (Wed-24-May) *- Peter Dimov (Sun-28-May) *- Emil Dotchevski (Sun-28-May) *- Vicente J. Botet Escriba (Tue-20-May) *- Andrzej Krzemienski (Wed-31-May) *- Gavin Lambert (Wed-31-May) My understanding is that as the review concludes today, further reviews are permitted only until the end-of-day UTC. In addition, many notable discussions and topics raised during the review period will also contribute to a final submission decision and summary report. Preparing this report will take some time. I've accumulated extensive notes, but my intention is to review (re-read) all discussion in the context of the "story-arc" and (in some cases) the shifted opinions of some persons during the course of the review (as topics were clarified and alternatives were explored). I assume other "satellite discussions" will continue (e.g., evolution of std::expected<>, suitability of wide vs. narrow contract in APIs, generalization of variant<>, etc.), which I will endeavor to continue to follow as the Outcome Review summary report is prepared (because these continued discussions may further clarify issues previously raised during the Outcome Review); but no more reviews can be accepted after the review period closes. Thank you all (again) for your (often thankless) contributions to the community, where the personal sacrifice in time and effort (and perhaps stressful emotional investment) is quite obviously extensive in many cases. --charley

2 2

[outcome] where is the monadic style tutorial?
by Mathias Gaunard 02 Jun '17

02 Jun '17

Hi, I just took a quick look at outcome today and I don't really understand what it is doing. I expected to have some kind of mechanism to manage control flow with propagation between states only happening if the previous expression in the chain resulted in an expected value, like with the Expected monad. I searched throughout the documentation and didn't find any. Why is there no example of this? More than how the error state is captured and stored or how to capture custom errors, I believe the programming model is what the tutorial should really focus on.

3 4

[outcome] Formal review
by Gavin Lambert 01 Jun '17

01 Jun '17

With the extended review period ending soon (or perhaps slightly overdue, depending on timezone), and given my many posts regarding the library, I feel like I should probably express my thoughts in review form. This is my first formal review and I am not myself a Boost library author (just a user) so please take that into account. - What is your evaluation of the design? A lot of thought has clearly gone into it, though I'm not sure I agree with some of the decisions made. Empty state I'm on the fence about; I can see it's convenient both for optional<T> success return semantics and for not-yet-populated/called pending result semantics, but I'm not sure these are consistently applied as it stands, and they seem at least partly opposed to the "empty state is weird, let's aggressively throw" behaviour in the actual implementation. Simplifying expected<T, E> into result<T> and outcome<T> makes sense, and the design of error_code_extended seems reasonable, including the content and ring buffer history. However I wonder if perhaps some middle ground might be better, where result<T, E> and outcome<T, E> exist but E is constrained to a type with specific characteristics (such as being constructible from error_code and having noexcept move). This might allow for more flexible error payloads. Alternately some way to use a similar error_code_extended-linked-to-ring-buffer system but with a user-defined payload data type. I don't consider this to be a defect or reason to reject the library, though, just something that would be useful if possible. I don't like that result<error_code{,_extended}> is not legal, as this seems like unnecessary asymmetry, though again I don't consider this a rejection reason. - What is your evaluation of the implementation? I have not looked in depth at it. The dual licensing and dual source distribution (preprocessed vs. not) bother me, but that will apparently be addressed in future. I don't like the total duplication of interface methods (get vs. value, error vs. get_error), but this will apparently also be addressed in future. (I am not opposed to having both narrow and wide accessors in the same type, though I prefer that the ones that can cause UB if abused require more typing. I *am* opposed to having multiple names for the exact same behaviour.) I'm not sure why it would be useful to provide const&& overloads of some of the value methods. Usually the only time I've seen these is to explicitly delete that overload. (Unless that is what's actually happening and doxygen is just not showing that correctly.) I like the use of wide contracts by default, such that it is safe to call value(), error(), or exception() without inspecting the underlying type and they will react sensibly (eg. throwing) rather than having UB, although some of the finer points of what a sensible reaction means are still being debated. But I can understand the desire of some people to have the other versions available for specific cases or in environments where static checking is more common. Even so, I hope that the narrow versions will at least BOOST_ASSERT their preconditions. The lack of use of Boost facilities such as Config, Assert, and Core (esp. BOOST_NO_EXCEPTIONS) bothers me more, and I do consider that a rejection reason. Use of StackTrace would be good as well but at this point I don't consider that a defect since it's not quite "in" Boost yet. (Possibly also Exception for boost::throw_exception, though using std::exception_ptr is the correct choice.) There is a critical defect in error_code_extended's backtrace API, which has already been brought to the author's attention and should hopefully be resolved later. - What is your evaluation of the documentation? Generally good, although it seems to spend a lot of time and pages talking about expected<T, E>, and only towards the end adds "but you should probably use outcome<T> instead" as a sort of afterthought, which seems a bit backwards. This is perhaps the correct order in a presentation, but it feels wrong in library documentation somehow. I think it needs to be more up-front about outcome and result (since those are the core types of the library) and recommended usage, and cover the other things as background material afterwards. The documentation refers to "monads" a lot, which is an unfamiliar concept to me. Not sure if this needs more explanation or just rewording. Doxygen's habit of putting hyperlinks that go nowhere in the reference pages is a bit disconcerting as well. - What is your evaluation of the potential usefulness of the library? Direct usefulness to me right now will be limited due to compiler support, but this seems like the sort of thing that would be quite useful in the future, especially to tidy up dual APIs such as those in ASIO. They have a fairly good chance of becoming standard vocabulary types, which of course has also helped drive a lot of the discussion thus far. - Did you try to use the library? With what compiler? Did you have any problems? I have not, as the compilers I use day-to-day are only C++11 or less, not C++14. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? Primarily a fairly detailed reading of the documentation, combined with discussion here. - Are you knowledgeable about the problem domain? Mixed. I have experience with exception handling internals in MSVC and regularly work with software in both contexts of using error codes everywhere with exceptions banned, and of allowing exceptions but preferring they never actually be thrown. I also regularly work with both low-latency and fixed-latency environments, in addition to more "normal" software. But other than interaction with ASIO I have not made much use of error_codes to date, or mixing the two environments in the "sea of noexcept" fashion, though I can see the appeal. - Do you think the library should be accepted as a Boost library? Eventually, yes, but currently no (rejection, with encouragement to resubmit). While the author claims that the actual implementation has changed little since initial submission, the changelog in the "review accepted feedback" threads sounds fairly serious, and I'm not sure I like some of its directions (such as separate types for contract variations). Perhaps it will indeed end up being no big deal, but I don't feel like I have a good handle on what the end result will look or behave like so I don't feel comfortable endorsing it until I can get a better look at it. Primarily though I think the Boost integration was done backwards; the library should make use of Boost facilities first (as previously mentioned); if also distributed separately then that separate distribution should have the Boost emulation layer in it, and not the reverse. (To clarify: using std:: facilities is preferred, so using <system_error> is better than using <boost/system/system_error.hpp>, although it would be nice if compatible with the latter without actually depending on it unless requested explicitly. But the main problem is lack of use of Config, Assert, and Core, unless I missed something.)

2 2