- Boost - lists.boost.org

[contract] move operations and class invariants
by Lorenzo Caminiti 01 Dec '17

01 Dec '17

Hello all, This is not really a question about Boost.Contract, but more a question on how contract programming interacts with C++ move operations. C++ requires that moved-from objects can still be destructed. Because contract programming requires class invariants to hold at destructor entry, it follows that moved-from objects must still satisfy class invariants. That sounds restrictive... and it might force the class invariants to be empty. For example, for vector a class invariant is size() <= capacity(). Should that sill hold after the vector has been moved? That means I can still call size() and capacity() on a moved-from object, which might not be the case. If some sort of moved() function could be called on a moved-from object, the invariants could be programmed as follow to work around this issue: class vector { void invariant() cont { if(!moved()) BOOST_CONTRACT_ASSERT(size() <= capacity()); ... // Only invariants that are truly needed to execute the destructor. } bool moved() const; public: vector(vector&& other) { boost::contract::check c = boost::contract::constructor(this) .postcondition([&] { BOOST_CONTRACT_ASSERT(!moved()); BOOST_CONTRACT_ASSERT(other.moved()); }) ; ... } ... }; I'm not really sure... What do you think? Do you know if this topic "C++ move & class invariants" has already been discussed somewhere? Thanks. --Lorenzo

6 11

Re: [boost] [contract] move operations and class invariants
by Peter Dimov 01 Dec '17

01 Dec '17

Lorenzo Caminiti wrote: > > read() can fail, so you can drop its "valid" precondition and just fail > > when the handle is invalid. > > Calling read() on a moved-from object so violating its is_valid() > precondition is a bug, not a run-time error while reading the file. The > precondition legitimately remains in place to catch bugs, even after it is > noted that read() can fail because of file-system or other run-time > errors. On one hand, you want to have a precondition. On the other, you say that if you have the precondition, the class would be crippled and not very useful: >> 2. How useful is a class like the one above with "crippled" invariants >> and is_valid() preconditions on all its useful public methods like >> read()? The answer seems to be: not very useful. These are contradictory. Either the class that has preconditions is crippled and not very useful, in which case we drop the preconditions as I suggest; or it's useful, in which case we keep them.

1 0

[spirit] x3 status and docs?
by Andrey Semashev 29 Nov '17

29 Nov '17

Hi, I'm wondering what is the status of Boost.Spirit x3? Is it considered stable and ready for production use? If yes, how can I find its docs? There seem to be no mention of x3 in the docs on the Boost website.

3 2

[histogram] Working with standard algorithms
by Bjorn Reese 29 Nov '17

29 Nov '17

I would like to see a better integration between boost.histogram and standard algorithms, especially those from <numeric>. Today they do not work together because the dereference operator of the axis iterator returns a pair (index and content) rather than the content. An example of where standard algorithms could be useful is calculating the cumulative distribution of a one-dimensional histogram, which ought to be a simple as: auto& axis = h.axis(); std:partial_sum(axis.begin(), axis.end(), axis.begin()); Another example is ranking a set of histograms based on the cosine similarity [1] using std::inner_product(). [1] https://en.wikipedia.org/wiki/Cosine_similarity

2 4

[release][fusion] Permission to merge
by Kohei Takahashi 29 Nov '17

29 Nov '17

Hi release manager, I'd like to merge a PR, which fixes a regression on buggy compiler. https://github.com/boostorg/fusion/pull/162 Boost.regression shows the test was passed on develop. Regards, Kohei Takahashi

1 0

[Build] x32
by Olaf van der Spek 28 Nov '17

28 Nov '17

Hi, > libboost_system-vc141-mt-gd-x32-1_66.lib Why is this named x32? AFAIK the normal name is x86. -- Olaf

5 4

Re: [boost] Adding polymorphic_value to boost
by Phil Endecott 28 Nov '17

28 Nov '17

Peter Dimov wrote: > You can have > > vector<polymorphic_value<Shape>> v; > > and then > > v.push_back( Circle(10) ); > v.push_back( Ellipse(10, 15) ); > v.push_back( Square(11) ); Good example. Yes please. There's another way of implementing this, though; rather than pointing to the object in the heap you can store it in-place by allocating enough space for the largest possible derived subclass: class Base { ... }; class Derived: public Base { ... }; template <typename B> class polymorhpic_value_2 { B base; char enough_space_for_dervided_classes_members[1024]; public: template <typename D> // requires D is same as or derived from B void operator=(const D& d) { B::~B(this); new (this) D(d); } }; polymorphic_value_2<Base> p; Derived d; p = d; That's just a sketch; many details omitted! There are some obvious advantages and disadvantages of each approach and I'm definitely not saying this is better than the pointer-to-heap design. But I mention it for this reason: * If your proposed interface for polymorphic_value could also work for this method of implementation, then it is probably a better interface. > It's unfortunate we have to use -> instead of . but that's what's available. There have been proposals for operator. ; has this been evaluated to see how it would work with them? Similarly the unified a.b() vs. b(a) syntax proposal. Regards, Phil.

4 6

Outcome v2 peer review dates set
by Niall Douglas 28 Nov '17

28 Nov '17

Outcome v2 will be up for its post-peer-review second review between Friday 19th January and Sunday 28th January with Charley Bay once again serving as review manager. In case you'd like to give it a whirl before then: Docs: https://ned14.github.io/outcome/ Single file edition: https://github.com/ned14/outcome/raw/develop/single-header/outcome.hpp Boost edition repo: https://github.com/ned14/boost-outcome Standalone edition repo: https://github.com/ned14/outcome List of changes since v1: https://github.com/ned14/outcome#changes-since-v1 Compilers needed: GCC 6, clang 4, VS2017 (C++ 14 minimum, C++ 20 preferred) Acknowledgements ---------------- This post-peer-review complete rebuild of Outcome was actually a collaborative effort by a number of the Boost community, and it has been significantly influenced for it. I'd firstly like to thank Charley for taking on the role of review manager for a second time, especially given that he knows from the first time what an awful lot of work it's going to be for him. I am *hoping* that seeing as v2 Outcome is literally a tick box set of the changes you guys recommended last time, that this review will be a quick and simple review. We shall see. I'd like to thank Andrzej for writing the beginning of the tutorial. It set the tone and pacing which I then extended to the rest of the tutorial, and I think the benefit of that shows through as this should be a vast improvement on the (many) v1 tutorials. Andrzej also found many bugs, asked many clever "stupid questions", and acted as a constant peer reviewer throughout the development of v2, including suggesting the present design for payload transport. Andrzej has had a huge influence in the shape, and direction, of this library. I cannot thank him enough, and although he declined being listed as coauthor, I'm thinking of "special thanks to" or something like that in the authorship list as he went above and beyond in his contribution. I'd like to thank Jonathan Müller for doing so much work on his Standardese tool to support Outcome. The current reference API docs on the Outcome website are but a wisp of what will hopefully be in place by the time of the review. Jonathan has had to wrestle with many libclang demons smoked out by Outcome pushing the state of the art, and will have to wrestle with many more yet, but already the huge improvements over the doxygen reference API docs are evident. If anybody has any questions or feedback between now and the review, please let rip. Otherwise thanks for reading! Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

1 0

Fwd: Using 'detail' folder from a another Boost library
by Jean Guegant 27 Nov '17

27 Nov '17

Hi everyone, I am trying to unify the way Boost.Beast and Boost.Asio pick an implementation of string_view (std::experimental::string_view, std::string_view). In order to do so, I am including the header file <boost/asio/detail/string_view.hpp> within <boost/beast/core/string.hpp> (see PR: https://github.com/boostorg/ beast/pull/910/files). Is that a bad practice to include the a "detail" folder from another library? If so, what would you recommend to solve my unification problem? Sincerely, Jean

2 1

Getting started with open source
by Faisal Riyaz 26 Nov '17

26 Nov '17

Hi, I am Faisal.I am new to open source community.I am familiar with C and C++ language.I am pursuing computer engineering and presently i am in first year.I am interested in contributing to your organisation and learn some stuff. It will be very helpful for me if someone can help me get started. Faisal Riyaz

1 0