- Boost - lists.boost.org

[config] Macro for null pointer
by Edward Diener 08 Dec '12

08 Dec '12

I have found something like this to be helpful, when working with multiple compilers: #include <boost/config.hpp> #if defined(BOOST_NO_NULLPTR) #define BOOST_XXX_NULLPTR 0 #else #define BOOST_XXX_NULLPTR nullptr #endif where XXX is some local name for my own use. And then use BOOST_XXX_NULLPTR in places where a null pointer is needed. Would this be a candidate for a BOOST_NULLPTR macro in the config library instead ? Edward Diener

16 63

Re: [boost] [boost-steering] Re: [Git] Documentation for Git and Modular Boost conversion
by Brian Wood 08 Dec '12

08 Dec '12

Dave Abrahams: > Boost is making this transition. It *will* cause some disruption. It > will also make things easier for some people. I'm glad to hear this effort is continuing. > IMO we should not burden this move, which is supposed to > make it easier and more efficient overall for Boost to operate, > with any unnecessary obligations. That sounds harsh, but I guess that's the way the cookie crumbles. -- Brian Wood Ebenezer Enterprises -- so far G-d has helped us. http://webEbenezer.net

1 0

[serialization] Proposal: make 'version' trait (and others) enable_if-friendly
by Gabriel Redner 07 Dec '12

07 Dec '12

I have recently run up against a limitation of the serialization library in terms of specializing the 'version' trait. Fortunately, I believe the issue has a simple workaround which I don't believe will break existing code. In general, one can change the version of a serialized class by specializing the 'version' template class: ============================== template <typename T> struct version { BOOST_STATIC_CONSTANT(unsigned int, value = 0); }; ... template <> struct version<MyType> { BOOST_STATIC_CONSTANT(unsigned int, value = 1); }; ============================== However, this approach does not work if 'MyType' is of the form (see [1]): ============================== template <typename T> struct Foo { struct MyType { int data1; }; }; template <typename T> struct version<Foo<T>::MyType> // ERROR { BOOST_STATIC_CONSTANT(unsigned int, value = 1); }; ============================== It's not possible for the compiler to deduce the enclosing type, so this doesn't work. However, if MyType can be identified by a metafunction, then I can use enable_if to select the specialization of 'version' that I want. However, this requires support from 'version' itself: ============================== template <typename T, typename Enable = void> // NOTE new template parameter struct version { BOOST_STATIC_CONSTANT(unsigned int, value = 0); }; ... template <typaneme T> struct version<MyType, typename boost::enable_if<is_mytype<T> >::type> { BOOST_STATIC_CONSTANT(unsigned int, value = 1); }; ============================== So, my proposal is simply to add this extra template parameter to 'version'. I do not believe other uses of 'version' will be affected, but it would not surprise me if I've overlooked something. Presumably the same modification could be made to implementation_level etc. A patch (for 'version' only) against trunk is enclosed below. Comments are welcome! Thanks, -Gabe [1] http://boost.2283326.n4.nabble.com/serialization-versioning-for-class-neste… =================================================================== --- version.hpp (revision 81723) +++ version.hpp (working copy) @@ -32,7 +32,7 @@ // default version number is 0. Override with higher version // when class definition changes. -template<class T> +template<class T, class Enable=void> struct version { template<class U> @@ -53,8 +53,8 @@ }; #ifndef BOOST_NO_INCLASS_MEMBER_INITIALIZATION -template<class T> -const int version<T>::value; +template<class T, class Enable> +const int version<T, Enable>::value; #endif } // namespace serialization ===================================================================

5 12

Inspect Report
by Daniel James 07 Dec '12

07 Dec '12

Hi, The snapshot builds and inspect results haven't been running for some time, so I've added running the inspect script to the documentation build for more up to date results. You can see them at: http://boost.cowic.de/rc/docs-inspect-trunk.html http://boost.cowic.de/rc/docs-inspect-release.html These are generated after building documentation, which is not exactly the same as the final release, but it's close. Daniel

4 10

[context] asm_context_sources breaking regression testing for WinCE
by David Deakins 07 Dec '12

07 Dec '12

Hi Oliver, I finally got a little bit of time to investigate recent strange behavior on the VeecoFTC regression tester and found that the build jamfile for the context library is halting Boost.Build during the regression tests. It appears that, when it can't find an appropriate architecture to use, it actually generates an argument error in try-one-generator-really. I attached the output of the bjam.log and perhaps it will be useful for investigating. Let me know if you would like me to try anything. Thanks, -Dave

2 12

[iterator] UB when implicitly using default constructed counting_iterator<unsigned>
by Peter Sommerlad 07 Dec '12

07 Dec '12

Hi Jeffrey, hi all, I believe the usability of counting iterator could be improved, by value-initializing its Iterator type in the default constructor, because integral types won't be initialized by its default constructor. This can lead to hard to recognize user errors, e.g., when wrapping such a counting iterator with a filter iterator. counting_iterator is special in that sense, because to my understanding it is intended to adapt integral types to become iterators. And a default initialized scalar type, isn't. I suggest a one line change: counting_iterator() { } should become counting_iterator() : super_t(Incrementable()) { } The following example program shows the interesting UB, because the 3rd argument of make_filter_iterator, default constructs a counting_iterator<unsigned>(). Any thoughts? Objections? Teachings... Regards Peter. =====>8 #include <iostream> #include <boost/iterator/filter_iterator.hpp> #include <boost/iterator/counting_iterator.hpp> #include <algorithm> #include <iterator> #include <functional> struct is_prime{ bool operator()(unsigned int val) const { if (val < 2) return false; using std::placeholders::_1; auto ce=boost::make_counting_iterator(val); return ce==std::find_if_not(boost::make_counting_iterator(2u),ce, bind(std::modulus<unsigned>{},val,_1)); } }; int main(){ std::copy_n(boost::make_filter_iterator(is_prime{},boost::make_counting_iterator(1u) // if the following line is omitted we have undefined behavior, because of uninitialized unsigned value // ,boost::make_counting_iterator(std::numeric_limits<unsigned>::max()) // must be different from above value ),40,std::ostream_iterator<unsigned>{std::cout,", "}); } =====8< -- Prof. Peter Sommerlad Institut für Software: Bessere Software - Einfach, Schneller! HSR Hochschule für Technik Rapperswil Oberseestr 10, Postfach 1475, CH-8640 Rapperswil http://ifs.hsr.ch http://cute-test.com http://linticator.com http://includator.com tel:+41 55 222 49 84 == mobile:+41 79 432 23 32 fax:+41 55 222 46 29 == mailto:peter.sommerlad@hsr.ch

3 2

[coroutine] permission to merge to boost-release?
by Oliver Kowalke 07 Dec '12

07 Dec '12

Hello, because the merge window for new libraries is closed on Monday I'd like to ask for permission to merge boost.coroutine into boost-release. regards, Oliver

2 2

Re: [boost] [iterator] UB when implicitly using default constructed counting_iterator<unsigned>
by Peter Sommerlad 07 Dec '12

07 Dec '12

Hi Jeff On 01.12.2012, at 02:53, Jeffrey Lee Hellrung, Jr. wrote: >> And a default >> initialized scalar type, isn't. >> > > "isn't"...what, exactly? it isn't initialized with a defined value. struct X{ X(){} unsigned x; }; void foo(){ X y; // -> y.x has an uninitialized value AFAIK if it is local } that is the situation we run into with the default constructed counting_iterator<unsigned>() > I'm not opposed to giving defined behavior to a default constructed > counting_iterator< [integral type] >, I'm just not sure what that defined > behavior should be. Maybe I'm over-analyzing it... I still believe the most simple change I suggested is enough (at least it would cover my situation well enough). Those input iterators where a default constructed one is the end iterator is IMHO more of an exception, because it is a special case for the stream iterators. Your idea with std::numberic_limits< Iterator >::max() requires a much more complex solution with template meta programming, i.e., enable_if<is_arithmetic<Iterator>> or similar. And it won't provide the default value of Iterator, which is zero in the case of the built-in arithmetic types, i.e., unsigned(). What do you think? Regards Peter. -- Prof. Peter Sommerlad Institut für Software: Bessere Software - Einfach, Schneller! HSR Hochschule für Technik Rapperswil Oberseestr 10, Postfach 1475, CH-8640 Rapperswil http://ifs.hsr.ch http://cute-test.com http://linticator.com http://includator.com tel:+41 55 222 49 84 == mobile:+41 79 432 23 32 fax:+41 55 222 46 29 == mailto:peter.sommerlad@hsr.ch

7 21

[array] last check in break serialization for array
by Robert Ramey 06 Dec '12

06 Dec '12

A particular test in the serialization library spontaneously has broken. By "spontaneously" I mean that I haven't checked anything in lately. The test is test_array_xml_warchive in the serialization library test matrix. Here are a few facts: a) I haven't checked anything in so the serialization library itself hasn't changed. b) It occurs on all GCC platforms. c) it "seems" to have started around 30 November d) it occurs only on the trunk - all these tests have been run since 30 November e) it doesn't occur on the release branch - none of these tests run since 30 November f) it occours on my development machine. Note that I use release branch for all testing - except for the serialization library itself which I use the trunk version. g) The nature of the error suggests that it is related to memory allocation/deallocation > From all of the above I'm looking at change on the release branch #81635 > (or there abouts) by glenfe Merged revision(s) 81608-81610 from trunk: Optimization: Add specializations of make_array_helper, allocate_array_helper, and array_deleter for fixed size arrays to avoid storing size. ........ Consistent formatting across overloads of make_shared and allocate_shared (array forms). ........ More consistency in type parameters in helper details of allocate_shared and make_shared. ... Does anyone have any insight into this? Robert Ramey

3 2

[Interprocess] message_queue should use timed_lock
by Hartmut Kaiser 06 Dec '12

06 Dec '12

Hey, I'm running into a timing issue with interprocess::message_queue even when I use the timed send and received functions: One end: if (!mq_->timed_receive(&msg, sizeof(msg), recvd_size, priority, boost::get_system_time() + boost::posix_time::milliseconds(1))) { // ... return false; } // ... The other end: while (!mq_->timed_send(&msg, sizeof(msg), 0, boost::get_system_time() + boost::posix_time::milliseconds(1))) { break; } (mq_ is a shared_ptr<message_queue>) here both ends sit forever inside the timed_receive/timed_send function, both waiting to acquire a lock (ipc/message_queue.hpp, lines 702 and 799), which is held by a third participating process. Shouldn't this lock be using a timed_lock to allow to maintain the API post condition (i.e. returning after the given amount of time in any case)? Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu

2 1