- Boost - lists.boost.org

[random] ranlux24_base(0) should be equal to ranlux24_base()
by Stephan T. Lavavej 30 Jan '13

30 Jan '13

Hi, After fixing a bug in VC11's <random> (see [1]), I compared VC's fixed output to Boost 1.52.0's output and I believe I found a bug in Boost. Here's a self-contained test case: C:\Temp>type meow.cpp #include <ios> #include <iostream> #ifdef USE_BOOST #include <boost/random.hpp> using std::boolalpha; using std::cout; using std::endl; using boost::random::minstd_rand0; using boost::random::mt19937; using boost::random::ranlux24_base; #else #include <random> using namespace std; #endif template <typename Engine> typename Engine::result_type run_10k(Engine engine) { for (int i = 0; i < 9999; ++i) { engine(); } return engine(); } int main() { cout << boolalpha; #ifdef USE_BOOST cout << "Using boost." << endl; #else cout << "Using std." << endl; #endif cout << "N3485 26.5.5 [rand.predef]/1 satisfied: " << (run_10k( minstd_rand0()) == 1043618065) << endl; cout << "N3485 26.5.5 [rand.predef]/3 satisfied: " << (run_10k( mt19937()) == 4123659995) << endl; cout << "N3485 26.5.5 [rand.predef]/5 satisfied: " << (run_10k(ranlux24_base()) == 7937952 ) << endl; cout << "I believe minstd_rand0(0) == minstd_rand0() should be true: " << (minstd_rand0(0) == minstd_rand0()) << endl; cout << "I believe mt19937(0) == mt19937() should be false: " << (mt19937(0) == mt19937()) << endl; cout << "I believe ranlux24_base(0) == ranlux24_base() should be true: " << (ranlux24_base(0) == ranlux24_base()) << endl; cout << "run_10k( minstd_rand0(0)): " << run_10k( minstd_rand0(0)) << endl; cout << "run_10k( mt19937(0)): " << run_10k( mt19937(0)) << endl; cout << "run_10k(ranlux24_base(0)): " << run_10k(ranlux24_base(0)) << endl; } With my fixed build of Milan/VC12, I'm getting: C:\Temp>cl /EHsc /nologo /W4 /MTd meow.cpp meow.cpp C:\Temp>meow Using std. N3485 26.5.5 [rand.predef]/1 satisfied: true N3485 26.5.5 [rand.predef]/3 satisfied: true N3485 26.5.5 [rand.predef]/5 satisfied: true I believe minstd_rand0(0) == minstd_rand0() should be true: true I believe mt19937(0) == mt19937() should be false: false I believe ranlux24_base(0) == ranlux24_base() should be true: true run_10k( minstd_rand0(0)): 1043618065 run_10k( mt19937(0)): 1543171712 run_10k(ranlux24_base(0)): 7937952 (Note that VC11 RTM/Update 1 will suffer the bug described by [1].) If I use Boost's implementation with VC11 Update 1, I get: C:\Temp>cl /EHsc /nologo /W4 /MTd /DUSE_BOOST meow.cpp /I boost-1.52.0\include meow.cpp C:\Temp>meow Using boost. N3485 26.5.5 [rand.predef]/1 satisfied: true N3485 26.5.5 [rand.predef]/3 satisfied: true N3485 26.5.5 [rand.predef]/5 satisfied: true I believe minstd_rand0(0) == minstd_rand0() should be true: true I believe mt19937(0) == mt19937() should be false: false I believe ranlux24_base(0) == ranlux24_base() should be true: false run_10k( minstd_rand0(0)): 1043618065 run_10k( mt19937(0)): 1543171712 run_10k(ranlux24_base(0)): 14007167 Here's why I believe that ranlux24_base(0) should be equal to ranlux24_base(). ranlux24_base is a subtract_with_carry_engine. 26.5.3.3 [rand.eng.sub]/7 says: "explicit subtract_with_carry_engine(result_type value = default_seed); [...] linear_congruential_engine<result_type, 40014u,0u,2147483563u> e(value == 0u ? default_seed : value);" /7 doesn't refer to "value" anywhere else. Therefore, 0 should behave identically to the default_seed 19780503u. (For comparison, VC and Boost agree that minstd_rand0(0) == minstd_rand0(). 26.5.3.1 [rand.eng.lcong]/5 says: "explicit linear_congruential_engine(result_type s = default_seed); [...] If c mod m is 0 and s mod m is 0, sets the engine’s state to 1, otherwise sets the engine’s state to s mod m." The default_seed is 1u and minstd_rand0 sets c to 0, so that's why 0 behaves identically to the default_seed.) Stephan T. Lavavej Visual C++ Libraries Developer [1] http://connect.microsoft.com/VisualStudio/feedback/details/776456

2 2

permission to merge docu ?
by Oliver Kowalke 29 Jan '13

29 Jan '13

The release branch is closed because of building boost-1.53. I'd like to add a comment to boost.context documentation. Would this be possible? Oliver

2 1

[log][phoenix][spirit] Cygwin compiler crashes in actor_operator_10.hpp
by Bernd Prager 29 Jan '13

29 Jan '13

All, I am trying to compile the trunk version of Andrey Semashev's great Boost.Log library in Cygwin 1.7.17 with g++ 4.5.3. The line that crashes compiling his code is: $ "g++" -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -mthreads -fno-strict-aliasing -ftemplate-depth-1024 -DBOOST_ALL_NO_LIB=1 -DBOOST_CHRONO_STATIC_LINK=1 -DBOOST_FILESYSTEM_STATIC_LINK=1 -DBOOST_LOG_SETUP_BUILDING_THE_LIB=1 -DBOOST_LOG_USE_NATIVE_SYSLOG=1 -DBOOST_SPIRIT_USE_PHOENIX_V3=1 -DBOOST_SYSTEM_NO_DEPRECATED -DBOOST_SYSTEM_STATIC_LINK=1 -DBOOST_THREAD_BUILD_LIB=1 -DBOOST_THREAD_DONT_USE_CHRONO=1 -DBOOST_THREAD_POSIX -DBOOST_THREAD_USE_LIB=1 -DDATE_TIME_INLINE -DNDEBUG -I"." -c -o "bin.v2\libs\log\build\gcc-4.5.3\release\link-static\threading-multi\formatt er_parser.o" ./libs/log/src/formatter_parser.cpp The result is: ... >> ./libs/log/src/formatter_parser.cpp:447:95: instantiated from here >> ./boost/phoenix/core/detail/preprocessed/actor_operator_10.hpp:31:2307: >> internal compiler error: Segmentation fault Andrey suggests it might be related to the Boost.Spirit parser rather then Boost.Phoenix. Could somebody please have a look at this? Thank you so much, -- Bernd

4 10

boost::filesystem::path frustration
by Dave Abrahams 29 Jan '13

29 Jan '13

I'm finding that boost::filesystem::path seems to be a strange mix of different beasts, unlike any entity we have in the STL. For example, when you construct it from a pair of iterators, they're expected to be iterators over characters, but when you iterate over the path itself, you are iterating over strings of some kind (**). Even though, once constructed, this thing acts sort of like a container, it supports none of the usual container mutators (e.g. push_back, pop_back, erase) or even queries (e.g. size()), making it incompatible with generic algorithms and adaptors. In particular, this comes up because I'm trying to find the greatest common prefix of two paths. I thought this would be easy; I'd just use std::mismatch. But even once I've found the mismatch I don't see any obvious way to chop off the non-matching parts of one of the paths. I end up having to resort to some really ugly code (or I just haven't figured out how to use this thing correctly). Why should paths be so different from everything else? I think, if the design is actually right, some rationale is sorely needed. Also, * (**) the docs don't say what the value_type of path::iterator is. A string value? A range that becomes invalid when the path is destroyed? Ah!?! How surprising; inspecting the code shows it iterates over paths! A container whose element type is itself is very unusual! * the docs claim you can construct a path from a "A C-array. The value type is required to be char, wchar_t, char16_t, or char32_t", but doesn't say how that array will be interpreted. From the wording I might have assumed it accepts a CharT(&)[N] and the length of the input is taken as N, but inspecting the code shows it expects a CharT* and interprets the source as null-terminated. Thanks, -- Dave Abrahams BoostPro Computing Software Development Training http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost

15 32

[1.53.0] Beta release candidates 2 now available for testing
by Marshall Clow 28 Jan '13

28 Jan '13

Updated release candidate files for 1.53.0 beta 1 are available at http://boost.cowic.de/rc/ As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. This helps ensure the candidates build OK before we push them out to SourceForge. The files (and associated md5s) are: 579b680bf55f53cd6d50adc391cb6c23 *boost_1_53_0_beta1_rc2.tar.gz 02098bb6da0e9c10712ae63c16e6aeea *boost_1_53_0_beta1_rc2.tar.bz2 998e2616a66c50e5693f563afb899002 *boost_1_53_0_beta1_rc2.zip e4fde6a869a3e21f8751ba8b7fd471a8 *boost_1_53_0_beta1_rc2.7z There were three changes between rc1 and rc2: * Fixes for compilation errors in Boost.Serialization * Documentation updates for Boost.SmartPtr * Updates to Boost.Threads Thanks, --The release managers

9 16

[release] permission to merge
by Vicente J. Botet Escriba 28 Jan '13

28 Jan '13

Hi, could I merge https://svn.boost.org/trac/boost/changeset/82659 (ticket https://svn.boost.org/trac/boost/ticket/7940) svn diff rel/boost/chrono/config.hpp Index: rel/boost/chrono/config.hpp =================================================================== --- rel/boost/chrono/config.hpp (revision 82662) +++ rel/boost/chrono/config.hpp (working copy) @@ -96,6 +96,9 @@ # undef BOOST_CHRONO_HAS_THREAD_CLOCK # undef BOOST_CHRONO_THREAD_CLOCK_IS_STEADY # endif +# if defined(__VXWORKS__) +# undef BOOST_CHRONO_HAS_PROCESS_CLOCKS +# endif # endif Best, Vicente

2 1

[filesystem] thread safety on msvc 2010
by Jacob Schloss 28 Jan '13

28 Jan '13

Hi, I've been having some crashes in my code due to concurrent creation of boost::filesystem::path objects on several threads. The issue in short looks like function member static variable initialization is not thread safe in msvc 2010, but is in GCC. The main issue is with the construction of the std::locale and codecvt objects, I get crashes when some threads try to use a partially constructed instance of std::locale. I posted some details of my issue and possible fix at the end of bug 6320 https://svn.boost.org/trac/boost/ticket/6320, and would like to clean it up into a patch for consideration. Right now, I was looking at using boost::thread call_once to synchronize the std::locale and codecvt initialization code. I'm running locally with a boost::thread::call_once patch, and it seems to work for some simple test cases. I'd appreciate any thoughts, or pointers if anyone has worked on this issue, I saw some discussion at http://lists.boost.org/Archives/boost/2011/12/189183.php but it did not seem to move forwards. Thanks, Jacob Schloss

3 2

[1.53.0 beta] [type_traits] is_POD
by Cromwell Enage 28 Jan '13

28 Jan '13

Hi, all! I found out that Boost.TypeTraits defines a metafunction called is_POD that is essentially a template alias of is_pod, but it isn't documented. In particular, the documentation needs to mention that is_POD must be overridden in the same cases that is_pod must be overridden. Cromwell D. Enage

4 4

[accumulator] any news on serialization?
by Neal Becker 27 Jan '13

27 Jan '13

Last I heard was this: http://lists.boost.org/boost-users/2008/06/37586.php

2 1

[interprocess] [bimap] Using raw pointers
by Matias Capeletto 27 Jan '13

27 Jan '13

Hello, Currently Boost.Bimap does not work with interprocess allocators because it uses references to connect the views and the core. I want to change this but avoid any performance hit and I am wondering what is the best way to do it. It will be easy if Bimap interface will use .left() and .right() functions to access the map views (then I could just init the views at each call like Boost.MultiIndex get() index function does) but I am stuck with the left and right members (and I actually like them). So, what I want to be able to do is the following: template<class Bimap> class left_type { Bimap* core; public: left_type(Bimap* c) : core(c) {}; ... }; template<class Bimap> class right_type {...}; template<class LeftKey,class RightKey> class bimap { public: left_type<bimap> left; right_type<bimap> right; bimap() : left(this), right(this) {} }; This will not work because I am not using the proper offset_pointer abstraction, but I would love to be able to avoid it. In the case of Bimap, these pointers are very easy to maintain. Will it be possible to add an extension point to Boost.Interprocess to allow this idiom? Something like adding a call to the end of priv_find_impl of segment_manager so user classes can rewire themselves when they are loaded from shared memory. For example: template<class T> void rewire_after_loading_from_shared_memory(T* t) { } ... template <class T> std::pair<T*, size_type> priv_find_impl (const CharType* name, bool lock) { // find ret pointer T* t_ret = static_cast<T*>(ret) ; if( t_ret ) rewire_after_loading_from_shared_memory( t_ret ); return std::pair<T*, size_type>(t_ret ,sz); } ... Or maybe a better place. Then I will be able to rewire the map views pointers to the core if they are different from it: template<class L, class R> void rewire_after_loading_from_shared_memory(bimap<L,R>* t) { t->rewire(); } If this is not possible because inherent limitations of the interprocess mechanisms, do you know a good way to make Boost.Bimap compatible with its allocators? Thanks, Best regards Matias

3 12