- Boost - lists.preview.boost.org

'is_palindrome' and 'const char*'
by Зайцев Александр 14 Aug '16

14 Aug '16

Hello. I have some question about some case for 'is_palindrome' algo. 'is_palindrome' algorithm checks a sequence - if sequence is a palindromeor empty, function returns true, in other cases returns false. But in case e.g. "a" (is_palindrome("a")) result is false, because "a" = {'a', '\0'}. And maybe this behaviour is unexpected for users. So... what do you think about it? Should I implement special version for const char* or not? -- Best regards, Zaitsev Alexander

3 4

filesystem 1.61.0 and cygwin: Windows assumed, posix expected
by Frédéric Bron 12 Aug '16

12 Aug '16

Hi, On cygwin, the following program #include <iostream> #include <boost/filesystem.hpp> int main() { auto p = boost::filesystem::path{"foo"}; p /= "bar"; std::cout << p.string() << '\n'; return 0; } outputs: foo\bar but cygwin is a posix system and I expect: foo/bar I read in the doc that "User-defined BOOST_POSIX_API and BOOST_WINDOWS_API macros are no longer supported." So how can I have posix support on cygwin? Thanks, Frédéric

1 1

[graph] Sync develop with master?
by Murray Cumming 12 Aug '16

12 Aug '16

Now that Boost 1.61 is out, it would be great if the various fixes in boost graph's develop branch could be merged/cherry-picked/whatever to master, please. There seem to be a couple of years of fixes that have not appeared in a release. -- Murray Cumming murrayc(a)murrayc.com www.murrayc.com

5 21

[thread][circular_buffer] Unmerged changes for 1.62
by Andrey Semashev 12 Aug '16

12 Aug '16

Hi, There are a couple of my PRs hanging for quite some time that I'd like to be merged before 1.62 is released: https://github.com/boostorg/circular_buffer/pull/9 Changes the default implementation of circular_buffer in debug mode to the thread-safe by default. https://github.com/boostorg/thread/pull/92 Fixes compilation of Boost.Thread with MSVC-8. There is also https://github.com/boostorg/thread/pull/94, which is not mine but it looks like it fixes a genuine problem. Could someone have a look at them and merge? Thanks.

2 3

[interprocess] weirdest bug with offset_ptr equality comparison
by Joaquin M López Muñoz 11 Aug '16

11 Aug '16

The following is a distilled testcase after the ticket reported at https://svn.boost.org/trac/boost/ticket/12367 #include <boost/interprocess/allocators/allocator.hpp> #include <boost/interprocess/managed_shared_memory.hpp> template<typename Allocator> struct node_base { using allocator_type=Allocator; }; template<typename Allocator> struct node_impl { using value_type= typename Allocator::template rebind<node_impl>::other::value_type; }; template<typename Super> struct trampoline:node_impl<typename Super::allocator_type>{}; template<typename Super> struct node:Super,trampoline<Super>{}; int main() { using node_type= node< node< node_base< boost::interprocess::allocator< int, boost::interprocess::managed_shared_memory::segment_manager > > > >; using pointer=boost::interprocess::offset_ptr<node_type>; pointer p=nullptr; bool b=(p==p); // here's the problem } This works fine with GCC. When compiled with Visual Studio 2015, we get: 1>------ Build started: Project: borrame2015, Configuration: Debug x64 ------ 1> sandbox.cpp 1>d:\usr\joaquin\proyectos\boost-repo\trunk\boost\interprocess\detail\mpl.hpp(74): error C2594: 'argument': ambiguous conversions from 'node<node<node_base<boost::interprocess::allocator<int,boost::interprocess::segment_manager<CharType,MemoryAlgorithm,IndexType>>>>> ' to 'node_impl<boost::interprocess::allocator<int,boost::interprocess::segment_manager<CharType,MemoryAlgorithm,IndexType>>> ' 1> with 1> [ 1> CharType=char, 1> MemoryAlgorithm=boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family,boost::interprocess::offset_ptr<void,ptrdiff_t,size_t,0x00>,0x00>, 1> IndexType=boost::interprocess::iset_index 1> ] 1> d:\usr\joaquin\proyectos\borrame2015\sandbox.cpp(39): note: see reference to class template instantiation 'boost::interprocess::ipcdetail::is_convertible<node_type *,PointedType *>' being compiled 1> with 1> [ 1> PointedType=node_impl<boost::interprocess::allocator<int,boost::interprocess::segment_manager<char,boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family,boost::interprocess::offset_ptr<void,ptrdiff_t,size_t,0x00>,0x00>,boost::interprocess::iset_index>>> 1> ] ========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ========== Note that it is the line bool b=(p==p); // here's the problem that triggers the problem; if removed, compilation goes fine. Almost anything in the testcase program is needed for the problem to arise: - using node_type=node<node<...>> --> using node_type=node<...> (just one node level): compilation OK - remove using value_type=... in node_impl: compilation OK - rebind<node_mpl> --> rebind<char>: compilation OK - use std::allocator rather than boost::interprocess::allocator: compilation OK Ion, I'm totally puzzled by this and unable to navigate through the internals of Boost.Interprocess. Totally at your disposal if you need further info or assistance running tests etc. Thank you, Joaquín M López Muñoz

2 3

[contract] noexcept and throwing handlers
by Lorenzo Caminiti 10 Aug '16

10 Aug '16

Hello all, I would like to discuss contracts and exception specifications (e.g., noexcept) specifically with respect to what Boost.Contract does. On one hand, it seems silly to allow a contract failure handler to throw an exception to only translate such an exception into a call to terminate() for noexcept functions. However, noexcept can be considered part of the function contract (namely, the contract that says the function shall not throw) and contract failure handlers should not be allowed to break such contract, not even when they are allowed to throw. For example consider a noexcept function fclose() that is called from a destructor without a try-catch statement (correctly so because fclose is declared noexcept). If fclose() is now allowed to throw when its preconditions fail, that will cause the destructor ~x() to throw as well?! void fclose(file& f) noexcept [[requires: f.is_open()]] ... class x { ~x() noexcept { fclose(f_); // f_ might not be open because of some bug... ... } file f_; }; (A point similar to the above is also made in N4160, in contrast with what argued in N4110.) Functions should honor their exception specifications (noexcept, etc.) even when their contracts fail and contract failure handlers are configured to throw. That is what Boost.Contract does (given that contract checking code appears within the function definition so it is subject to the exception specifications that appear in the enclosing function declaration): void fclose(file& f) noexcept { // This will call terminate()... boost::contract::guard c = boost::contract::function() .precondition([&] { BOOST_CONTRACT_ASSERT(f.is_open()); // ...even if this throws. } ; ... } int main() { boost::contract::set_precondition_failure( [] (boost::contract::from where) { // Re-throw exceptions (assertion_failure, user-defined, etc.). if(where != boost::contract::from_destructor) throw; std::terminate(); // But destructors never throw. } ); ... } Also note that a contract framework that allows to install failure handlers that throw exceptions should also pass some sort of parameter to the handler function to indicate if the contract failure happened in a destructor or not. That is so the failure handlers can choose to never throw for destructors, not even if class invariants (or postconditions) fails when checked by destructors. --Lorenzo

3 4

[release] Continuous release archives.
by Rene Rivera 09 Aug '16

09 Aug '16

Starting with this release the archives for the prospective beta and release candidates are continuously built from the master branch and uploaded to SourceForge [1] (and to Bintray [2]). The release team would really appreciate if authors would download the archives and check the contents. In particular that the archives contain all the content you expect of your library, or libraries. And if you can also try building in your system that would stupendous. The more eyes we have on the final release products the smoother the process will be. And result in more time that the master branch is not blocked. Please report any problems sooner rather than later. So that we can try and address them before it's took late. Thank you, The Release Team [1] <https://sourceforge.net/projects/boost/files/boost/snapshots/master/> [2] <https://bintray.com/boostorg/master/snapshot#files> -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

5 7

Feature suggestions for Boost's program_options
by Eyal Rozenberg 09 Aug '16

09 Aug '16

Greetings Boost developers, [ Disclaimer: I'm new to this list - I joined by Vladimir Prus' suggestion that I raise my feature ideas here on the list. I've read the posting guidelines, and I haven't seen any discussion of program_options (at least not by Vladimir himself) for at least a year back in the list archives, so I think my post is legit. ] I've been using Boost's program_options library for several months now. It mostly does the job (that's a compliment...) - but there are some features whose lack is really bugging me. For some of them (especially Feature Idea 1) I actually work around by taking some options as unparsed remainders, sticking them in a string->string map and parsing them myself. Without further ado, and in decreasing order of importance to me: -------------------------------- Feature Idea 1: Support specifying multiple alternative long option names, using comma-separation. Right now we can specify, for example, "include-path,I" - one short form, one long form. Why not allow specifying "include-path,include-dir,headers-path,I" ? Only the first long option name would be printed as part of the usage information, to not complicate things overmuch, and merely tolerate alternative phrasing. Feature Idea 2: Have a (new?) parser which supports taking "semi-parsed command-line options" as input: A map from string keys to string values, or to optional<string> values to represent options without an argument as well. This is actually very close to environment parsing, except that the environment parser gets its "map" from, well, the environment variables. So the implementation might be simply exposing the existing functionality with a slightly richer interface. Feature Idea 3: A facility for pretty-printing parsed options to an std::ostream, in which the option description starts the line, and the option value (not the name used for parsing) is printed after it. There is some pretty-printing for the usage info to the console, so why not this? (Argument against this idea: Choosing a default is a very touchy subject. Counter-argument: ... but that's also somewhat true of printing usage information; and nobody has to use this default, it would be entirely optional.) Feature Idea 4: Support three rather than just two levels of describing options: name, for the command line; short description, for listing values (see Feature Idea 3; long description for the usage info. Feature Idea 5: Create a variant of update_with which doesn't just set the option value, but creates a link of sorts between the variable which the app would use and the variable_map entry. With this in place, further changes to the variable map automagically affect the app variable. -------------------------------- So, - What do you think about these suggestions, in principle? - If you find some of them relevant, can you help estimate the necessary development effort and possible negative implications/caveats to consider? - Assuming a feature idea is both relevant and feasible, is it customary to request implementation by the maintainer? Commit yourself to implementing it vis-a-vis statement of statement of partiality to accepting a patch? Some other practice? Thank you for getting through the long(ish) email and for your hard work, Eyal Rozenberg DB architecture group CWI Amsterdam

3 4

[release] Boost 1.62 closing for new libraries this week
by Rene Rivera 07 Aug '16

07 Aug '16

Hopefully everyone has had a good Summer and has gotten all the new libraries and breaking changes in.. As we are closing the release window for that this week. Please consult the calendar [1] for the full release schedule. And take this as a reminder to merge your changes that you want in the next release as soon as possible. [1] <http://www.boost.org/development/index.html> -- -- 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

[boost-process] Beta & Review
by Klemens Morgenstern 07 Aug '16

07 Aug '16

Hi, boost-process is now in beta, you can check it out here: https://github.com/klemens-morgenstern/boost-process and read the doc here: http://klemens-morgenstern.github.io/process/ It will probably be in review in the beginning of November, Antony Polukhin will be the review manager. I really hope I'll get some feedback before that, so I can work on the weak points and also get more detailed in the documentation. Thanks, Klemens

4 10

[boost-spirit-qi] Support for n-ary operators PR
by Frank Hein 06 Aug '16

06 Aug '16

Hello, some days ago I raised an PR (https://github.com/boostorg/spirit/pull/200) which adds support for a new class of parsers, in particular named n-ary operators. Joel de Guzman reviewed that. The code is ok. Because this addition touches the inner core of qi, the metagrammar, Joel asked me to drum for support in the community. So if you are in qi, may I kindly ask you to review this PR, the code, the discussion so far, and respond, if you want to support this PR or if you think, it's not needed. Thank you very much. I highly appreciate your feedback. The PR description is very detailled, so this mail has not to be. :) Regards, Frank

1 0

Review Schedule and Review Manager for PODs Flat Reflection (ex magic_get)
by Antony Polukhin 05 Aug '16

05 Aug '16

Hello, PODs Flat Reflection (or PFR) is a C++14 library that represents POD structures as tuples and provides tuple-like methods for PODs. Library has a set of predefined operators for PODs and useful functions for everyday use. Works with user-defined types without any macro or boilerplate code. Library: https://github.com/apolukhin/magic_get Docs: http://apolukhin.github.io/magic_get/ Boost Library Incubator: http://blincubator.com/bi_library/pfr-pod-flat-reflection/?gform_post_id=16… Could the PODs Flat Reflection library be put on review schedule? Anyone wishing to become a Review Manager for the library? -- Best regards, Antony Polukhin

6 9

[config] RFC PR 82
by Domagoj Saric 01 Aug '16

01 Aug '16

Hi everyone, I am finally getting back to (trying to) contributing some of my personal projects to Boost. For two of those, Err (https://github.com/psiha/err) and especially Functonoid (a C++11 generalization and rewrite of my previous Boost.Function related work) I need some lower level codegen and/or optimiser control functionality (i.e. portable macros wrapping toolset specific attributes and pragmas) that I've added to my personal fork of Boost.Config and which I've now submitted in the subject PR (https://github.com/boostorg/config/pull/82) I don't expect this PR to be accepted as is/'just like that' so I'm opening this thread where we can discuss which of those changes/macros are welcome, which need more work and which, for some reason, should not be part of Boost.Config (and which, in turn then, I have to move to some 'internal implementation headers' in libraries that will need them). To avoid 'spamming' (and save time;) I'll skip the explanation of the individual macros as I expect them to mostly be self-explanatory (if not from their name then from the minimal Boost.Config documentation additions that are part of th PR). ps. I'll be on the (off) road for the next three weeks so I don't know when I'll be able to respond until I get back... -- "What Huxley teaches is that in the age of advanced technology, spiritual devastation is more likely to come from an enemy with a smiling face than from one whose countenance exudes suspicion and hate." Neil Postman

8 31

constexpr, cmath functions and other functions and distributions
by Paul A. Bristow 01 Aug '16

01 Aug '16

After much head scratching (and some head banging) - against a string of "Computer Says No" inscrutable diagnostic messages. I believe that I have now produced a (partial) version of Boost.Math normal_distribution that can be a constexpr using GCC6.1.1. (diagnosis has got to improve if constexprizing existing code is to become popular? ) constexpr normal_distribution<double> n01(0., 1.); producing this code 960 .loc 1 47 0 961 000d 660FEFC0 pxor %xmm0, %xmm0 # tmp89 962 0011 F20F1145 movsd %xmm0, -32(%rbp) # tmp89, n01.m_mean 962 E0 963 0016 F20F1005 movsd .LC1(%rip), %xmm0 #, tmp90 963 80080000 964 001e F20F1145 movsd %xmm0, -24(%rbp) # tmp90, n01.m_sd 964 E8 and more interestingly, a PDF can be calculated at compile-time constexpr double p = pdf(n01, 0.5); 965 .loc 1 56 0 966 0023 F20F1005 movsd .LC2(%rip), %xmm0 #, tmp91 966 88080000 967 002b F20F1145 movsd %xmm0, -8(%rbp) # tmp91, p 967 F8 Perhaps the assembler whizzes can confirm that this looks like a compile-time computation? This relies on lots of C++14 and 17 constexpr features, and Most crucially it relies on being able to use several cmath functions as constexpr. For a couple of trivially simple examples: abs(x) and isfinite(x). constexpr double ax42 = abs(-42.); // Unspecified version of abs. constexpr double ax42g = ::abs(-42.); // C double version? constexpr double ax42b = __builtin_abs(-42.); // builtin GCC only constexpr double ax42s = std::abs(-42.); // std:: version Without most cmath functions it seems to me impossible to write any reasonable (so-called special or not) mathy function or statistical distribution that can be constexpr. At present, only GCC 6.1.1 authors have foreseen this need and provided these so-called built_in_* cmath function versions that are constexpr, see https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html. (Aside on other compilers: · Clang 3.8 has some problem deep inside type_traits that I haven't yet investigated. · VS2015 update 3 still doesn't compile many essential C++17 features from my experiments so far, and doesn't provide any constexpr cmath functions. ) The many potential benefits of compiler-time computations are quite enticing to contemplate :-) * No run-time where possible * Errors caught at compile-time * Improved code readability * Reduce executable footprint and potentially most important * Avoid global initialization order issues * Avoid initialization thread races See · Scott Schurr, C++ Developer, Ripple Labs https://cppnow2015.sched.org/event/2oLK/constexpr-c-at-compile-time · Dietmar Khul Constant Fun https://www.youtube.com/watch?list=PL9hrFapz4dsM1B9bI8VmEE4JJlR0m-dvo <https://www.youtube.com/watch?list=PL9hrFapz4dsM1B9bI8VmEE4JJlR0m-dvo&v=T37…> &v=T37ElKPICvo&app=desktop Is there any support for making std::abs and friends constexpr where possible in future versions of the C++ Standard? Paul PS I can't conceive of any UDT using or providing floating-point without some function like frexp to get and set exponent and significand. I also note that making constexpr frexp and ldexp and other functions passing a pointer to a variable to be updated may be more difficult/impossible, and is very likely to require at least initialization of the to-be-updated variable before calling frexp. I've investigated overcoming this by writing a naïve new constexpr version of frexp returning a std::pair (significand and exponent) but, of course, it can never be a 'drop-in' replacement because it has a different signature, so lots of code changes are inevitable. --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830

5 6

[type_erasure] Do we have a maintainer (minor fix needed)?
by John Maddock 31 Jul '16

31 Jul '16

This trivial PR is open for type_erasure and fixes an issue introduced by changes to Boost.Config (enabling constexpr support for VC14up3). https://github.com/boostorg/type_erasure/pull/11 BTW the failure is not caused by buggy constexpr support, there's some other issue going on once that code path is enabled. Anyhow, since we really should be merging Config to master soon, I'd like to see this collateral-damage fixed if possible. Thanks, John.

1 0

[contract] Template types
by Lorenzo Caminiti 29 Jul '16

29 Jul '16

Hello all, I would like to discuss the extra type requirements that contracts can impose of generic types and how Boost.Contract handles that. I think I mentioned some of this already in different emails to this list, but I wanted to summarize this topic in one email. For example, note that the following code will not compile when the old value template parameter T is not copyable: template<typename T> void swap(T& a, T& b) [[ensures: a == old(b)]] ... In Boost.Contract (approach 1): template<typename T> void swap(T& a, T& b) { boost::contract::old_ptr<T> old_b = BOOST_CONTRACT_OLDOF(b); boost::contract::guard c = boost::contract::function() .postcondition([&] { BOOST_CONTRACT_ASSERT(a == *old_b); }) ; ... } In some cases, that might be what the contract writers want: the generic old value type T is not copyable so postconditions cannot be checked and the program should not compile. However, in some other cases the contract writes might not want to add the extra copyable requirement on T and check the related postconditions only when callers specify a template parameter T that happens to be copyable. That can be done allowing some sort of static-if in contracts: template<typename T> void swap(T& a, T& b) [[ensures: static if(is_copyable<T>::value) a == old(b)]] ... In Boost.Contract (approach 2): template<typename T> void swap(T& a, T& b) { boost::contract::old_ptr_if_copyable<T> old_b = BOOST_CONTRACT_OLDOF(b); boost::contract::guard c = boost::contract::function() .postcondition([&] { if(old_b) BOOST_CONTRACT_ASSERT(a == *old_b); }) ; ... } Both approach 1 and 2 above are valid and should be supported by the framework. The decision between which approach to use for a specific contract should be left up to the programmers. Like old values can introduce the extra copyable type requirement, any contract assertion can in general introduce an number of extra requirements on generic types, namely the type requirements necessary to support the operations used to program the contract assertions. For example, the following code will not compile if T is not equality comparable (which is not a type requirement vector normally imposes on T): template<typename T> class vector { void push_back(T const& value) [[ensures: back() == value]] ... }; In Boost.Contract (approach 1): template<typename T> class vector { void push_back(T const& value) { boost::contract::guard c = boost::contract::public_function(this) .postcondition([&] { BOOST_CONTRACT_ASSERT(back() == value); }) ; ... } }; Again, that might be what contract writes want in some case but in other cases they might want to just skip the assertion when T does not meet all the type requirements needed by the operations used in the assertion: template<typename T> class vector { void push_back(T const& value) [[ensures: static if(has_equal_to<T>::value) back() == value]] ... }; In Boost.Contract (approach 2): template<typename T> class vector { void push_back(T const& value) { boost::contract::guard c = boost::contract::public_function(this) .postcondition([&] { BOOST_CONTRACT_ASSERT( boost::contract::check_if<has_equal_to<T>::value >( boost::bind(equal_to<T>, cref(back()), cref(value)) ) ); }) ; ... } }; --Lorenzo

1 0

Gmane going away
by Tom Kent 29 Jul '16

29 Jul '16

So it looks like Gmane is under attack and the guy who runs it is thinking about just turning it off (that would be sad). https://lars.ingebrigtsen.no/2016/07/28/the-end-of-gmane/ Anyway, I know a lot of boost users use is as the gnu mailman archive pages are really hard to use. I would like to propose that we (specifically the list owner(s)) mirror the boost mailing lists to the mail-archive.com site. It has good search features and decent thread browse-ability. Thoughts? Tom

1 0

Boost Social Event at CppCon 2016
by Jon Kalb 28 Jul '16

28 Jul '16

Boost Developers, Because a lot of Boosters are going to be attending CppCon, we¹d like to arrange a social event for Boosters/C++Now attendees. http://cppcon.org/ If you are planning to attend CppCon or even If you are just going to be in or around Bellevue, Washington between September 17th and 23rd and you¹d like to join us for dinner, please let us know so we can get a count. Please send mail to: social(a)boost.org Once we settle on a date, etc, we¹ll let everyone who responded know when and where, so please let us know, even if you are a ³maybe.² If you are attending, please make your hotel reservations soon. We are likely to sell out of our room block. http://cppcon.org/lodging/ I hope to see you at CppCon. Jon

2 1

Approximate matching to Boost.Algorithm
by Зайцев Александр 27 Jul '16

27 Jul '16

Hello. I want to discuss about some proposals. I am working on Levenshtein distance and Damerau-Levenshtein distance algortihms. I hope, that these implementations will be pulled to the Boost String library. But i think that we can add to the Boost String Library some more algorithms for fuzzy searhing. You can find this list here: https://fuzzystring.codeplex.com/ List: 1)Hamming Distance 2)Jaccard Distance 3)Jaro Distance 4)Jaro-Winkler Distance 5)Levenshtein Distance 6)Longest Common Subsequence 7)Longest Common Substring 8)Overlap Coefficient 9)Ratcliff-Obershelp Similarity 10)Sorensen-Dice Distance 11)Tanimoto Coefficient Maybe something else... What do you think about this idea? If you think that it can be implemented to the Boost String Algo, i will start work on this list immediately. Best regards, Zaitsev Alexander.

2 1

I am working on Aho-Corasik
by Зайцев Александр 27 Jul '16

27 Jul '16

Hello. FYI: Now i am working on Aho-Corasik algorithm. Best regards, Alexander Zaitsev.

1 0

Fast nth-elemnt on the segment
by Зайцев Александр 26 Jul '16

26 Jul '16

Hello. What do you think about algorithm of fast searching nth-elemnt on the segment with O(logN), where N is count of elements. I would implement it to Boost.Algorithm. Best regards, Alexander Zaitsev

1 0

[type_erasure] Conflict with private member called data
by Nigel Pattinson 22 Jul '16

22 Jul '16

Hi I'm running into a problem with the type erasure library when trying to declare a member called 'data', e.g. BOOST_TYPE_ERASURE_MEMBER((has_data), data) using SomeClass = any< vector< copy_constructible<>, typeid_<>, relaxed, has_data<void*()> > >; This conflicts with the private member variable called 'data' in the any class. SomeClass does compile, but attempting to call the data() does not compile due to the conflict, with the error message being 'cannot access private member ... ' . I'm not sure if this is a limitation in the library or a compiler bug - I'm using Visual Studio 2015 Update 1. Using boost 1.57.0 at present, I could use a more recent version if that would help. Does anyone know of a possible workaround ? Thanks Nigel Pattinson

2 2

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