- Boost - lists.preview.boost.org

Update for the Cxx dual library
by Edward Diener 22 Jul '16

22 Jul '16

The Cxx dual library, or CXXD for short, is a C++ macro header-only library which chooses between using a Boost library or its C++ standard equivalent library for a number of different C++ implementations, while using the same code to program either choice. An 'implementation', called a 'dual library', is a Boost library which has a C++ standard library equivalent whose public interfaces are nearly the same in both cases. I have updated the Cxx dual library, for those who prefer to minimize their use of macros in source code, by providing an alternate method to the use of macros for including the appropriate header files and specifying the appropriate namespace for a dual library. In this alternate method including the appropriate header files is done by including an implementation header file, and specifying the appropriate namespace is done by using a C++ namespace alias. The alternate method, called the alias mode, is fully documented. You can get the latest version of the Cxx dual library at https://github.com/eldiener/cxx_dual. Instructions for using the library are in the README.md file. PDF documentation is available in cxx_dual.pdf, HTML doc is availavble online at http://eldiener.github.io/cxx_dual and you can generate local HTML documentation using the doc jam file. Questions, comments, bug reports are always welcome.

1 0

does boost support multimedia framework
by qw 22 Jul '16

22 Jul '16

Hi, Does boost support multimedia framework, just like gstreamer? Thanks! Regards Andrew

2 1

[contract] Class invariants (also for static and volatile/const-volatile public functions)
by Lorenzo Caminiti 21 Jul '16

21 Jul '16

Hello all, I would like to discuss class invariants, but also for static and volatile/const-volatile public member functions, and specifically with respect to how Boost.Contract handles them. Class invariants are important... almost as important as preconditions. For example for a vector container, class invariants specify among other things the equivalence relationship `(size() == 0) == empty()` that could be found useful by static analyzers and optimizes (also discussed in N4160): template<typename T> class vector { [[invariant: (size() == 0) == empty()]] [[invariant: size() <= capacity()]] public: void push_back(T const& value) ... { ... } }; The above contract cannot be programmed using preconditions and postconditions unless: it is repeated (together with all other invariant assertions) in pre- and postconditions of each public member functions, it is asserted with try-catches also when those functions throw, it is repeated in constructor postconditions, in destructor preconditions, and with try-catches also when destructors throw... Even if invariants are programmed in some `bool invariant() const` function to avoid repeating all invariant assertions in each pre- and postcondition, the code will be cluttered by boiler-plate code (try-catch to assert invariants on throw, etc.) and an invariant failure will just report that the invariant() function returned false, but it will not report which specific invariant condition actually failed (plus static analyzers and optimizes will not be able to parse the conditions from the invariant function): template<typename T> class vector { bool invariant() const { // But cannot distinguish which of the two assertions failed... // and cannot be used by static analyzers and optimizers. return (size() == 0) == empty() && size() <= capacity(); } public: void push_back(T const& value) ... [[requires: invariant()]] [[ensures: invariant()]] { try { ... } catch(...) { [[assert: invariant()]]; throw } } }; Class invariants cannot be effectively emulated using pre- and postconditions... they should be added to a contract framework as their own feature. In Boost.Contract: template<typename T> class vector { void invariant() const { BOOST_CONTRACT_ASSERT((size() == 0) == empty()); BOOST_CONTRACT_ASSERT(size() <= capacity()); } public: void push_back(T const& value) { boost::contract::guard c = boost::contract::public_function(*this) ... ; ... } }; Note that the above invariant function `void invariant() const` cannot be declared static or const-volatile because it will need to call queries like size(), empty(), capacity(), etc. that are const and not static or const-volatile. Thus the above invariant function, being const, cannot be called at entry and exit of static and volatile/const-volatile public functions. A contract framework for C++ should support also static and const-volatile class invariants to properly handle static and volatile/const-volatile public functions (even if static and const-volatile class invariants are not mentioned in any C++ contract proposal): * Static public functions check static class invariants at entry, at exit, and if body throws. * Volatile and const-volatile public functions check static and const-volatile class invariants (in that order) at entry, at exit, and if body throws. * Non cv-qualified and const public functions check static, const-volatile, and const class invariants (in that order) at entry, at exit, and if body throws. * Constructors check static class invariants at entry, at exit, and if body throws (because those do not require the object to be constructed). Then constructors check const-volatile and const class invariants (in that order) at exit (if body does not throw, because those require the object to be constructed). * Destructors check static class invariants at entry, at exit, and if body throws (because those do not require a constructed object). Then destructors check const-volatile and const class invariants (in that order) at entry and if body throws (because those require a constructed object). In Boost.Contract: struct a { static void static_invariant() { BOOST_CONTRACT_ASSERT(...); } void invariant() const volatile { BOOST_CONTRACT_ASSERT(...); } void invariant() const { BOOST_CONTRACT_ASSERT(...); } // Following check all static_invariant(), invariant() const volatile, and invariant() const (in that order). a() { boost::contract::guard c= boost::contract::constructor(this); } virtual ~a() { boost::contract::guard c = boost::contract::destructor(this); } void m() /* no cv qualifiers */ { boost::contract::guard c = boost::contract::public_function(*this); } void c() const { boost::contract::guard c = boost::contract::public_function(*this); } // Following check both static_invariant() and invariant() const volatile (in that order). void v() volatile { boost::contract::guard c = boost::contract::public_function(*this); } void cv() const volatile { boost::contract::guard c = boost::contract::public_function(*this); } // Following check only static_invariant(). static void s() { boost::contract::guard c = boost::contract::public_function<a>(); } }; Maybe volatile member functions are rarely used in C++ so const-volatile class invariants will also be used rarely if at all... Nevertheless, if const-volatile class invariants are not supported, it will not be possible to specify invariants for classes with volatile public functions so const-volatile class invariants should be supported for completeness. Static class invariant could instead be useful when programming contracts for the static part of the object state. In particular, Boost.Contract also supports postconditions for destructors (those should be checked by a static function because they should not access the object `this` that has been destroyed after the execution of the destructor body). Destructor postconditions are not mentioned in any contract proposal... but together with constructor and other function pre- and postconditions, and together with static class invariants, they can specify contracts for the static part of the object state. For example, consider the contracts for a class that counts the number of its object instances: struct a : private noncopyable, private nonmovable { static void static_invariant() { BOOST_CONTRACT_ASSERT((instances() != 0) == exists()); } a() { boost::contract::old_ptr<unsigned> old_instances = BOOST_CONTRACT_OLDOF(instances()); boost::contract::guard c = boost::contract::constructor(this) .postcondition([&] { BOOST_CONTRACT_ASSERT(instances() == old_instances + 1); }) ; ++instances_; } virtual ~a() { boost::contract::old_ptr<unsigned> old_instances = BOOST_CONTRACT_OLDOF(instances()); boost::contract::guard c = boost::contract::destructor(this) .postcondition([&] { // Must never use object `this`. BOOST_CONTRACT_ASSERT(instances() == old_instances - 1); }) ; --instances_; } static unsigned instances() { boost::contract::guard c = boost::contract::public_function<a>(); return instances_; } static bool exists() { boost::contract::guard c = boost::contract::public_function<a>(); return instances_ != 0; } private: static unsigned instances_; }; unsigned a::instances_ = 0; --Lorenzo

1 0

double_ended - request formal review
by Benedek Thaler 21 Jul '16

21 Jul '16

Dear Boost, I'd like to request the review of the double_ended library. Code: https://github.com/erenon/double_ended Documentation: http://erenon.hu/double_ended The library contains two classes. Excerpt from the documentation: * `devector` is a hybrid of the standard vector and deque containers, as well as the small_vector of Boost.Container. It offers cheap (amortized constant time) insertion at both the front and back ends, while also providing the regular features of std::vector, in particular the contiguous underlying memory. In contrast to the standard vector, however, devector offers greater control over its internals. Like small_vector, it can store elements internally without dynamically allocating memory. * `batch_deque` is very similar to the standard deque, with a slight twist. It lets you specify its segment size: The size of the contiguous memory segments it uses to store its elements. This provides a consistent layout across platforms, and lets you iterate over the segments with batch operations. I'm also looking for a review manager. Thanks, Benedek

2 1

[contract] Friend functions
by Lorenzo Caminiti 19 Jul '16

19 Jul '16

Hello all, I would like to discuss contracts for friend functions and specifically how they are handled in Boost.Contract. Consider the following example: class a; class b; class data { ... friend bool deep_equal(a*, b*); bool equal(data const&); }; class a { ... friend bool deep_equal(a*, b*); data data_; }; class b { ... friend bool deep_equal(a*, b*); data data_; }; bool deep_equal(a* x, b* y) { return x->data_.equal(y->data_); } Via friendship, deep_equal can be considered to extend a and b public interfaces, but not data's public interface (in fact, deep_equal does not take instance of data as an argument). Therefore, it is reasonable to think that deep_equal should check a and b class invariants (if so... in which order?), but not data's class invariants. As discussed in N4160, that would probably require some new language feature to specify which subset of friend functions also extend a class public interface. Plus such a feature should identify some preferred order in which class invariants should be checked for a friend function that extends public interfaces of multiple classes. That seems rather complicated so I think a language proposal (like N1962) is better off going with the general rule that friends functions do not check class invariants (even if that might not always be ideal in all cases): bool deep_equal(a* x, b* y) [[requires: x && y]] // Does not check a and b (and c) invariants... even if arguably it should. { return x->data_.equal(y->data_); } In Boost.Contract: bool deep_equal(a* x, b* y) { boost::contract::guard c = boost::contract::function() .precondition([&] { BOOST_CONTRACT_ASSERT(x && y); }) ; // Does not check a and b (and c) invariants... even if arguably it should. return x->data_.equal(y->data_); } Maybe programmers could manually check a and b invariants (but then also from the function body when it throws) when those checks are truly essential for friend function: bool deep_equal(a* x, b* x) [[requires: x && y]] // Check a and b invariants in that order (if contract writes decide to), does not check c invariants. [[requires: x->invariant() && y->invariant()] [[ensures: x->invariant() && y->invariant()] { try { return x->data_.equal(y->data_); } catch(...) { [[assert: x->invariant() && y->invariant()]]; throw; } } (That seems somewhat verbose... plus it assumes that class invariants are somehow specified in a `bool invariant() const function (that can be private), or using a set of [[invariant: ...]] attributes that automatically generate such a callable `bool invariant() const` function.) This is possible in Boost.Contract: bool deep_equal(a* x, b* y) { boost::contract::guard c = boost::contract::function() .precondition([&] { BOOST_CONTRACT_ASSERT(x && y); }) ; // Check a and b invariants in that order (if contract writers decide to), does not check c invariants. boost::contract::guard inv_x = boost::contract::public_function(*x); boost::contract::guard inv_y = boost::contract::public_function(*y); return x->data_.equal(y->data_); } Finally, note that in this case preconditions are checked before entry invariants (while usually public functions check preconditions after entry invariants). That is desirable/needed for friend functions because the class object is not *this (which is always well defined and therefore subject to no precondition). For friend functions, the class object can be any computation of the friend function arguments and those arguments must be validated by preconditions before they can be used to access the class object. In the examples above, the arguments are checked to be not null by preconditions so they can be safely dereferenced to get the objects *x and *y (and in general the computations required might be even much more complex than dereferencing pointers). Thank you. --Lorenzo

1 0

[contract] Without the macros
by Lorenzo Caminiti 19 Jul '16

19 Jul '16

Hello all, In the last few years my professional and personal lives changed quite a bit limiting my ability to contribute to Boost. However, in my spare time I slowing continued to revise Boost.Contract hoping to be able to commit it to a Boost release someday (after the library was accepted 3+ years ago... https://groups.google.com/forum/?fromgroups=#!topic/boost-list/jQ7OjAmos_Y) While doing so I realized that leveraging C++11 lambda functions, Boost.Contract could be re-implemented without its crazy macros that alter C++ function declaration syntax. Boost.Contract still remains the only C++ library that implements *all* features of Contract Programming (a.k.a., Design by Contract or DbC): subcontracting, class invariants (also static and volatile), postconditions (with old and return values), preconditions, customizable actions on assertion failure (terminate, throw, etc.), optional assertion compilation, disable assertion checking while already checking other assertions (to avoid infinite recursion), etc. Furthermore, in its new incarnation Boost.Contract no longer uses crazy macros so it is easier to use, faster to compile, and gives readable compiler errors. For example: #include <boost/contract.hpp> int inc(int& x) { int result; boost::contract::old_ptr<int> old_x = BOOST_CONTRACT_OLDOF(x); boost::contract::guard c = boost::contract::function() .precondition([&] { BOOST_CONTRACT_ASSERT(x < std::numeric_limits<int>::max()); }) .postcondition([&] { BOOST_CONTRACT_ASSERT(x == *old_x + 1); BOOST_CONTRACT_ASSERT(result == *old_x); }) ; return result = x++; // Function body. } Or with subcontracting: #include <boost/contract.hpp> #include <vector> template<typename T> class pushable; // Arbitrary base to demo subcontracting. template<typename T> class vector #define BASES public pushable<T> : BASES { public: typedef BOOST_CONTRACT_BASE_TYPES(BASES) base_types; // Subcontracting. #undef BASES void invariant() const { // Checked in AND with base class invariants. BOOST_CONTRACT_ASSERT(size() <= capacity()); // Line 25. } virtual void push_back(T const& value, boost::contract::virtual_* v = 0) /* override */ { boost::contract::old_ptr<unsigned> old_size = BOOST_CONTRACT_OLDOF(v, size()); // Old values. boost::contract::guard c = boost::contract::public_function< override_push_back>(v, &vector::push_back, this, value) .precondition([&] { // Checked in OR with base preconditions. BOOST_CONTRACT_ASSERT(size() < max_size()); // Line 35. }) .postcondition([&] { // Checked in AND with base postconditions. BOOST_CONTRACT_ASSERT(size() == *old_size + 1); // Line 38. }) ; vect_.push_back(value); // Function body. } BOOST_CONTRACT_OVERRIDE(push_back) // For `override_push_back`. // Could program contracts for those as well. unsigned size() const { return vect_.size(); } unsigned max_size() const { return vect_.max_size(); } unsigned capacity() const { return vect_.capacity(); } private: std::vector<T> vect_; }; Full documentation and examples at: https://lcaminiti.github.io/boost-contract What do you think? Thanks, --Lorenzo P.S. The library can also be used without C++11 lambda functions (or any C++11 specific feature) but programmers have to write a fare amount of extra code to program the precondition and postcondition functors (using non-local functions, Boost.LocalFunction, Boost.Funsion, Boost.Lambda, or some other approach) so that might not useful in practice.

6 14

[graph] Compilation error with adjacency_list and C++11
by Sebastien Loriot (GeometryFactory) 18 Jul '16

18 Jul '16

Hello, the program below does not compile at least with g++ 5.3.1 and clang++ 3.5.2-1 when using c++11 standard. If I comment line #1 it compiles. If I change #2 to undirectedS it compiles. Is there anything wrong in my code or is it a problem in boost's? Thanks, Sebastien. #include <boost/graph/adjacency_list.hpp> struct A { A(){} A(const A& ){} // #1 A& operator=(const A&){return *this;} }; typedef boost::adjacency_list<boost::listS, boost::vecS, boost::directedS, //#2 A > Graph; int main() { Graph g; boost::add_vertex(g); return 0; }

2 2

[type_index] Interest in dynamic_cast emulation?
by Chris Glover 17 Jul '16

17 Jul '16

Hi, I reached for Boost.TypeIndex the other day expecting to find a kind of dynamic_cast I could use in the absence of Rtti. I didn't find it, so I wrote something to emulate it using type_index internally. It's working, but before I go too far and clean this up and possibly submit a pull request, I would like to gauge if there's interest in such a thing or if there's some fundamental reason why it doesn't exist. So, thoughts? Thanks, -- chris

5 8

[contract] Strong exception safety guarantees
by Lorenzo Caminiti 15 Jul '16

15 Jul '16

Hello all, I've been considering adding a .except(...) construct to Boost.Contract that will allow to specify conditions to check at function exit but when the function body throws (in contrast to postconditions that are checked at function exit but only when the function body does not throw). I think .except(...) could be used to assert strong exception safety guarantees... (note that class invariants are already checked at exit of public functions and also when the public function bodies throw, but invariants are suited to assert only basic, and not strong, exception safety guarantees). That might help addressing a point made in P0147R0 under the "Contracts and Exceptions" section: ``Some operations make stronger exception safety claims. In particular, they claim that an exception thrown from a member function will leave the state of an object unchanged from its state on function entry. If we invalidate postconditions on exceptions, we appear to have no mechanism to describe strong exception safety.'' For example, the following swap ensures to leave its arguments unchanged when it throws: void swap(std::string& a, std::string& b) { boost::contract::old_ptr<std::string> old_a = BOOST_CONTRACT_OLDOF(a); boost::contract::old_ptr<std::string> old_b = BOOST_CONTRACT_OLDOF(b); boost::contract::guard c = boost::contract::function() .postcondition([&] { // Checked at function exit but only if body does not throw. BOOST_CONTRACT_ASSERT(a == *old_b); BOOST_CONTRACT_ASSERT(b == *old_a); }) .except([&] { // Checked if body throws (strong exception safety guarantees). BOOST_CONTRACT_ASSERT(a == *old_a); BOOST_CONTRACT_ASSERT(b == *old_b); }) ; ... // Body implementation (which might throw). } Would this be beneficial? Thanks, --Lorenzo

2 5

smartptr maintained
by Karolin Varner 15 Jul '16

15 Jul '16

Hi, is smartptr still being maintained? There are four pull requests, one more than a year old. Best, Karolin Varner

2 3