December 2012 - Boost - lists.preview.boost.org

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

[trunk-tests] msvc-8.0 internal compiler error
by Oliver Kowalke 06 Dec '12

06 Dec '12

Hi, msvc-8.0 generates an internal compiler error in the regression tests for boost.coroutine (tests in boost-trunk - http://www.boost.org/development/tests/trunk/developer/output/VC8%20jc-bell… ). Is it possible to prevent this error a code modification? Other versions like msvc-9.0/10.0/11.0/12.0 do pass the regression test. Oliver test_coroutine.cpp ..\boost/mpl/eval_if.hpp(41) : fatal error C1001: An internal error has occurred in the compiler. (compiler file 'msc1.cpp', line 1393) To work around this problem, try simplifying or changing the program near the locations listed above. Please choose the Technical Support command on the Visual C++ Help menu, or open the Technical Support help file for more information ..\boost/foreach.hpp(364) : see reference to class template instantiation 'boost::mpl::eval_if<C,F1,F2>' being compiled with [ C=boost::mpl::false_, F1=boost::range_const_iterator<boost::coroutines::coroutine<int (void)>>, F2=boost::range_mutable_iterator<boost::coroutines::coroutine<int (void)>> ] ..\libs\coroutine\test\test_coroutine.cpp(415) : see reference to class template instantiation 'boost::foreach_detail_::foreach_iterator<T,C>' being compiled with [ T=coro_int_void, C=boost::mpl::false_ ] Internal Compiler Error in C:\Program Files (x86)\MSVC8\VC\BIN\cl.exe. You will be prompted to send an error report to Microsoft later.

1 0

[compond_file_binary] Gauging interest in a possible library submission.
by А В 06 Dec '12

06 Dec '12

Hi, all. Is there any interest in a cross-platform C++ library which allows to create/read/write binary compound files? Briefly, compound file is filesystem for storing files and directories within a single file on a disk. Initially compound file format is developed by Microsoft and now is the part of Microsoft's Open Specifications Documentation. Compound files are used across various platforms and applications, and not restricted by some specific domain. In general, any application can store information in such a way. I've found on the Internet interest in such library and decided to implement it. Additional information can be found here: Article on the Wikipedia: http://en.wikipedia.org/wiki/Compound_File_Binary_Format Benefits of Compound Files: http://msdn.microsoft.com/en-us/library/windows/desktop/aa378938(v=vs.85).a… [MS-CFB] Open specification for compound files: http://msdn.microsoft.com/en-us/library/dd942138.aspx Regards, Alexander Voitenko.

11 26

generating docu fails
by Oliver Kowalke 05 Dec '12

05 Dec '12

Hello, 'quickbook context.qbk' generates context.xml but generating the html via bjam fails: /boost_1_52_0/tools/build/v2/build/generators.jam:1085: in ensure-type from module generators error: target { context.qbk. } has no type /boost_1_52_0/tools/build/v2/build/generators.jam:1319: in generators.construct from module generators /boost_1_52_0/tools/build/v2/build/targets.jam:1495: in construct from module object(typed-target)@927 /boost_1_52_0/tools/build/v2/build/targets.jam:1298: in object(typed-target)(a)927.generate from module object(typed-target)@927 /boost_1_52_0/tools/build/v2/build/targets.jam:732: in generate-really from module object(main-target)@958 /boost_1_52_0/tools/build/v2/build/targets.jam:704: in object(main-target)(a)958.generate from module object(main-target)@958 /boost_1_52_0/tools/build/v2/build/targets.jam:258: in object(project-target)(a)926.generate from module object(project-target)@926 /boost_1_52_0/tools/build/v2/build-system.jam:736: in load from module build-system /boost_1_52_0/tools/build/v2/kernel/modules.jam:283: in import from module modules /boost_1_52_0/tools/build/v2/kernel/bootstrap.jam:142: in boost-build from module /boost_1_52_0/boost-build.jam:17: in module scope from module how can it be fixed? Oliver

2 2

[mpl] [bimap] BOOST_MPL_LIMIT_METAFUNCTION_ARITY issue on g++ 4.6.3 and boost 1.50
by Adam Lach 05 Dec '12

05 Dec '12

Hi, I have already asked for help on Boost.users, but with no luck, see here <http://boost.2283326.n4.nabble.com/Problems-in-boost-mpl-aux-template-arity…> . Since then I have managed to reproduce this problem in a simpler case: #define BOOST_MPL_CFG_NO_PREPROCESSED_HEADERS #define BOOST_MPL_LIMIT_METAFUNCTION_ARITY 10 #include <boost/mpl/inherit.hpp> #include <boost/bimap.hpp> struct S0 {}; struct S1 {}; struct S2 {}; struct S3 {}; struct S4 {}; struct S5 {}; template<typename T0, typename T1, typename T2, typename T3, typename T4, typename T5> struct example : boost::mpl::inherit<T0,T1,T2,T3,T4,T5> {}; int main() { example<S0,S1,S2,S3,S4,S5> pasta; return 0; } The weird thing is that it occurs only if bimap.hpp is included. Please help. Thank you in advance, Adam Lach -- View this message in context: http://boost.2283326.n4.nabble.com/boost-mpl-bimap-BOOST-MPL-LIMIT-METAFUNC… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 2

Looking for someone with MSVC 8 or MSVC 9
by Marshall Clow 04 Dec '12

04 Dec '12

One of the string_ref tests is failing on these two compilers - neither of which I have access to. I would appreciate some help debugging this failure [ FWIW, the same tests pass on MSVC 10 and 11 ] Thanks in advance! -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki

3 4

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

04 Dec '12

Hi Jeff, On 04.12.2012, at 18:59, Jeffrey Lee Hellrung, Jr. wrote: > On Sun, Dec 2, 2012 at 8:41 AM, Peter Sommerlad <peter.sommerlad(a)hsr.ch>wrote: > just consider the following small program: >> >> #include <iostream> >> #include <boost/iterator/counting_iterator.hpp> >> >> int main(){ >> std::cout << unsigned() << '\n'; // zero >> std::cout << *boost::counting_iterator<unsigned>()<< '\n';// >> undefined behavior >> } >> > > Not quite UB :) It just outputs an undefined value. It won't blow up the > moon, for example. That is not true. According to the standard reading an uninitialized value incurs undefined behavior. While in practice your computer might not explode, it is inherently unsafe and unportable to rely on something like this. See below. Therefore my concerns (I am a regular attendant of the standard committee meetings, so I can check with the real experts about that, if you doubt). 4.1 Lvalue-to-rvalue conversion [conv.lval] • 1 A glvalue (3.10) of a non-function, non-array type T can be converted to a prvalue.53 If T is an incomplete type, a program that necessitates this conversion is ill-formed. If the object to which the glvalue refers is not an object of type T and is not an object of a type derived from T, or if the object is uninitialized, a program that necessitates this conversion has undefined behavior. If T is a non-class type, the type of the prvalue is the cv-unqualified version of T. Otherwise, the type of the prvalue is T.54 > > I understand your concerns, I think, but I believe it's somewhat misguided. > I believe your proposal could do at least as much to mask errors as it will > to find errors. Indeed, your original example would've silently worked as > expected (with the present implementation of filter_iterator, anyway) with > your proposed change, even though it's (still) incorrect usage. I still believe it is much better for a library to not incur silently undefined behavior, but to provide a defined default value, even if it is unusable in general, but detectable. if I would have used 0 as the start iterator in the original example instead of 1 I would have seen something is wrong with my unit tests. However, the undefined behavior didn't help me detecting it. 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

1 0

[BGL] status of maximum adjacency search
by Fernando Vilas 03 Dec '12

03 Dec '12

Hi, What remains to get ticket 6780 ready to commit? -- Thanks, Fernando Vilas fvilas(a)iname.com

2 2

[functional/hash] error: more than one instance of overloaded function "fpclassify" matches the argument list:
by Vicente J. Botet Escriba 02 Dec '12

02 Dec '12

Hi, there is a compile error that making fail all the tests in this tester. Could someone take care of it? Best, Vicente Test output: lazy piranha fedora 17 64 C++11 - thread - async__async_p / intel-linux-13.0.1 Rev 81655 / Sat, 1 Dec 2012 18:49:57 +0000 *Report Time: *Sun, 2 Dec 2012 12:54:01 +0000 Compile [2012-12-02 03:35:40 UTC]: fail "/opt/intel/bin/icpc" -c -xc++ -std=c++11 -O0 -g -w2 -inline-level=0 -pthread -fPIC -wd1418 -wd193,304,383,444 -wd2415 -wd593,981 -DBOOST_ALL_NO_LIB=1 -DBOOST_CHRONO_DYN_LINK=1 -DBOOST_SYSTEM_DYN_LINK=1 -DBOOST_SYSTEM_NO_DEPRECATED -DBOOST_THREAD_BUILD_DLL=1 -DBOOST_THREAD_POSIX -DBOOST_THREAD_THROW_IF_PRECONDITION_NOT_SATISFIED -DBOOST_THREAD_USE_DLL=1 -I".." -c -o "/home/michael/boost_testing/results/boost/bin.v2/libs/thread/test/async__async_p.test/intel-linux-13.0.1/debug/threading-multi/sync/futures/async/async_pass.o" "../libs/thread/test/sync/futures/async/async_pass.cpp" ../boost/functional/hash/detail/hash_float.hpp(214): error: more than one instance of overloaded function "fpclassify" matches the argument list: function "fpclassify(double)" function "std::fpclassify(double)" argument types are: (double) switch (fpclassify(v)) { ^ detected during: instantiation of "std::size_t={unsigned long} boost::hash_detail::float_hash_value(T) [with T=double]" at line 312 of "../boost/functional/hash/hash.hpp" instantiation of "boost::hash_detail::float_numbers<T>::type boost::hash_value(T) [with T=double]" at line 413 of "../boost/functional/hash/hash.hpp" compilation aborted for ../libs/thread/test/sync/futures/async/async_pass.cpp (code 2) TinyUrl <javascript:make_tinyurl()>

1 0

Fwd: [iterator] UB when implicitly using default constructed counting_iterator<unsigned>
by Jeffrey Lee Hellrung, Jr. 01 Dec '12

01 Dec '12

[Sorry, forgot to reply-all.] ---------- Forwarded message ---------- From: Jeffrey Lee Hellrung, Jr. <jeffrey.hellrung(a)gmail.com> Date: Fri, Nov 30, 2012 at 5:53 PM Subject: Re: [boost][iterator] UB when implicitly using default constructed counting_iterator<unsigned> To: Peter Sommerlad <peter.sommerlad(a)hsr.ch> On Fri, Nov 30, 2012 at 1:14 AM, Peter Sommerlad <peter.sommerlad(a)hsr.ch>wrote: > 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. > "isn't"...what, exactly? > I suggest a one line change: > > counting_iterator() { } > > should become > > counting_iterator() : super_t(Incrementable()) { } > Well, that's one thing you can do... > 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< The thing that bothers me about this is that a default-constructed iterator frequently is an end iterator; indeed, that's the assumption that filter_iterator appears to be making if no end iterator is supplied. So if the default-constructed iterator is not an end iterator, and you're wrapping it with a filter_iterator and not explicitly supplying the end, I'd say you're automatically asking for trouble, regardless of whether you're using a counting_iterator or not. On the other hand, I'm not sure what a sensible default value is for counting_iterator< [integral type] >; 0 is almost never going to be the end value; std::numeric_limits<>::max() might be a better choice, but really the end value is context-dependent. 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... - Jeff

1 0