January 2013 - Boost - lists.boost.org

Query of interest for a container output library
by meta221 31 Jan '13

31 Jan '13

Hello, lately I've been working on a library that can output different kinds of containers to standard output streams. The library is currently completely generic and can output any object that models the input range concept or Boost.Fusion's sequence concept. It doesn't restrict itself to std containers. If an object looks like a sequence, then it is a sequence in the eyes of the library. The library uses different open and close characters for different kinds of containers. For example the output of the following: std::cout << std::vector<int> {1,2,3} << '\n'; std::cout << std::set<int> {1,2,3} << '\n'; std::cout << std::map<int,int> { {1,2}, {2,3}, {3,1} } << '\n'; is: [1,2,3] {1,2,3} {(1,2), (2,3), (3,1)} In the example std::vector is interpreted as an ordered_dynamic container and std::set and std::map are interpreted as associative_dynamic containers by the library. The library recursively outputs the contents of each container, so because std::map::value_type is a std::pair (which models Boost.Fusion's sequence concept) it can also output that. std::pair is interpreted as an ordered_fixed container by the library. The library picks the appropriate category for each type being outputted by using Boost.MPL to introspect the type of the object being outputted. In the future I would like to extend the library to offer facilities to help users implement a operator<< (std::ostream&, T) function for arbitrary types but I haven't really given that a lot of thought yet. The library's name is currently Boost.Stringize but I don't really like that name and I'm really open for suggestions. Overall I think this library would make a good addition to Boost as it simplifies things for the end user. If a user wants to output a vector, he/she shouldn't have to iterate over it. It should be as simple as outputting an int. In Python a user can just "print [1,2,3]". Why can't we have something similar in C++? Is there any interest for this library in Boost? Thanks, Tal Zion -- View this message in context: http://boost.2283326.n4.nabble.com/Query-of-interest-for-a-container-output… Sent from the Boost - Dev mailing list archive at Nabble.com.

7 10

[string_ref] type erasure to support arbitrary strings
by Andreas Pokorny 31 Jan '13

31 Jan '13

Hi, When I made a first glance of the proposal I expected that string_ref is some kind of type erasing non owning holder of a reference to an arbitrary string class. The imperfect silver bullet for the diversity of string types. Take a project that uses c++ libraries using std::string, Qt GUI and maybe a module that works with chunked strings (string composed out of a list of usually equally sized blocks of memory). At the boundaries of the software modules copies have to occur. Frequently the interface expects some kind of constant references to a certain string type. Most of the time the callee just wants to process the complete string or just a part of the string. So there might not even be the necessity to have random access hence no need for a contiguous copy of the string contents. Thats why I would prefer a facility that only requires that the source string is a forward range of characters in an arbitrary encoding. I do not think that it makes sense to only address contiguous sequences of characters. regards Andreas Pokorny

5 8

[rfc] loop utility
by Tim Blechmann 31 Jan '13

31 Jan '13

hi all, since c++11 has lambda functions, writing functors is easier than never before ... so, i wonder, what do people think about a small utility function, that calls a functor N times? ruby: 10.times { puts 'hello world' } supercollider: 10.do { "hello world".postln } c++11/boost proposal: boost::loop(10, [] { printf("hello world\n"); }); boost::loop(10, [](int index) { printf("hello %d\n, index); }); personally, i find this coding style more elegant than for loops, as it avoids the visual noise of explicitly counting a loop variable ... not sure, if it is worth a separate library, maybe it could just be added to boost/utility ... thoughts? prototype available at github: https://github.com/timblechmann/boost_loop tim

4 6

[release] some Boost.Build fixes
by Jürgen Hunold 30 Jan '13

30 Jan '13

Hi, I would like to merge 82654 and 82655 to the release branch. The first is the fix for issue #7920 and the latter a fix for a broken test case. Both only touch the qt5 toolset and tests. Bothe checked in yesterday and have cycled. Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! * voice: ++49 4257 300 ! Fährstraße 1 * fax : ++49 4257 300 ! 31609 Balge/Sebbenhausen * jhunold(a)gmx.eu ! Germany

3 5

[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