- Boost - lists.boost.org

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