- Boost - lists.preview.boost.org

[lexical_cast] char types and UDTs
by Eric Niebler 13 Apr '12

13 Apr '12

Say I have a wide-character, user-defined, streamable type like boost::wssub_match from the regex library (or now std::wssub_match). It's basically a pair of wstring iterators. It's stream insertion operator is defined like this: template <class charT, class ST, class BiIter> basic_ostream<charT, ST>& operator<<(basic_ostream<charT, ST>& os, const sub_match<BiIter>& m) { return (os << m.str()); } If it's not obvious, it requires that the stream's character type is the same as the BiIter's value_type. If I were to try to use boost::lexical_cast to cast this to something, it won't work. That's because lexical_cast doesn't know about wssub_match, and so doesn't know that its character type should be wchar_t. Instead, it defaults to char for any unknown types, and doesn't give a way to override this. There is an internal trait, boost::detail::stream_char, that lexical_cast uses to determine what the character type of the source is (if any). It's specialized on only a fixed number of types. Since it's an implementation detail, it can't be used to extend the set of types. Also, I tried specializing it. In past versions of Boost that just worked, but it doesn't anymore. I think being able to extend lexical_cast to support types like (std|boost)::wssub_match is an essential feature. Thoughts on how to get there from here? -- Eric Niebler BoostPro Computing http://www.boostpro.com

5 14

[lockfree] tagged_ptr as a separate library
by Philipp Moeller 12 Apr '12

12 Apr '12

In the review of lockfree it has been suggested that tagged_ptr should make it into the public API of lockfree. Wouldn't it make sense to move it into a separate library entirely? It would possibly get more exposure and cross-platform ports. The technique itself also requires some extra documentation. And it might find it's way into a release earlier than lock-free itself. Philipp Moeller

5 7

Refactoring a library for header-only or linked library?
by Paul A. Bristow 12 Apr '12

12 Apr '12

I am considering refactoring a (potential Boost) library separating declarations and definitions into two sets of files with the objective of reducing compilation times and allow it to be used as header-only or linking with a pre-built library. Is there is best/Boost way of doing this? Is there a Boost library that I should use as a model? ASIO? Should I call the definition files .cpp or .ipp? Should definition files go in libs/src or in boost/? How should I control the header-only/library switch? View and suggestions? Thanks Paul --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow(a)hetp.u-net.com

2 3

[test] Ticket #6624 (Add a BOOST_<level>_NE_COLLECTIONS testing tool)
by Daniel Trebbien 12 Apr '12

12 Apr '12

Hello, I have been unable to reach the current maintainer of Boost.Test regarding Ticket #6624: https://svn.boost.org/trac/boost/ticket/6624 Would someone like to review my patch for this small enhancement and commit it? Daniel Trebbien

3 4

[svn/git/hg] Support for modularization of Boost?
by Beman Dawes 11 Apr '12

11 Apr '12

As far as I can see, scaling Boost up to a much larger number of libraries implies decentralization and decoupling, probably in the form of per-library modules or something similar. Modularization seems to have been missed in the discussions of Subversion, Git, and Mercurial. Do distributed version control systems in general and Git in particular have any important advantages/disadvantages over svn for highly modularized projects? Please, let's not waste everyone's time with a rehash of general DCVS vs CCVS pros and cons. We have beat that to death. Let's focus this thread on modularization support, particularly as it applies to Boost. Thanks, --Beman

13 20

boost::filesystem3::path::wchar_t_codecvt_facet()
by Renato Tegon Forti 11 Apr '12

11 Apr '12

Hi All, Anyone can help me to understand, and fix this error: gcc.link bin/gcc-4.6/release/threading-multi/doksafe_process_engine /usr/bin/ld: bin/gcc-4.6/release/threading-multi/main.o: undefined reference to symbol 'boost::filesystem3::path::wchar_t_codecvt_facet()' /usr/bin/ld: note: 'boost::filesystem3::path::wchar_t_codecvt_facet()' is defined in DSO /3rdparty/Boost/1.46.1/lib/libboost_filesystem.so.1.46.1 so try adding it to the linker command line /3rdparty/Boost/1.46.1/lib/libboost_filesystem.so.1.46.1: could not read symbols: Invalid operation collect2: ld returned 1 exit status Thanks

1 0

Two days left to save on BoostCon / C++Now! 2012
by Dave Abrahams 11 Apr '12

11 Apr '12

Just a quick reminder to everyone that early-bird registration closes at the end of this week. After Friday, the price goes up by $100. Spots are limited and registrations have been coming in faster than in past years. http://cppnow.org Cheers! -- Dave Abrahams BoostPro Computing http://www.boostpro.com

1 0

[range] adaptors vs. rvalue to lvalue& binding
by Arno Schödl 11 Apr '12

11 Apr '12

Hello, ideally I would like to use range-adapted lvalue ranges like any other lvalue ranges. Writing it down naively, as below, does not compile because LoadRefRange takes (and should take?) the range it modifies by lvalue&, while adaptor expressions are rvalues. template<typename Range> void modifies_range( Range& rng ); A a[5]; main() { // modifies all elements of a modifies_range ( a ); // modifies all elements (except for one) of a // adaptor is rvalue, does not compile: modifies_range ( boost::range::join( boost::adaptors::slice( a, 0, 1 ), boost::adaptors::slice( a, 2, countof(a) ) ) ); // compiles, but ugly: auto rng=boost::range::join( boost::adaptors::slice( a, 0, 1 ), boost::adaptors::slice( a, 2, countof(a) ) ); modifies_range(rng); } Any thoughts? Should adaptors receiving lvalues offer an operator adaptor&() &&; // overload on rvalue-ness so they are passing through the lvalue or their argument? A suitable baseclass a la boost::additive could do that. Regards, Arno -- Dr. Arno Schödl | aschoedl(a)think-cell.com Technical Director think-cell Software GmbH | Chausseestr. 8/E | 10115 Berlin | Germany http://www.think-cell.com | phone +49 30 666473-10 | US phone +1 800 891 8091 Amtsgericht Berlin-Charlottenburg, HRB 85229 | European Union VAT Id DE813474306 Directors: Dr. Markus Hannebauer, Dr. Arno Schoedl

8 21

[function] why do I function1 for type-of emulation?
by lcaminiti 10 Apr '12

10 Apr '12

Hello all, I was trying to use Boost.Function together with Boost.Typeof. It seems that if I run in type-of emulation mode I have to register boost::functionN instead of boost::function even if I only use boost::function... do you know why? For example: #include <boost/function.hpp> #include <boost/typeof/typeof.hpp> #include BOOST_TYPEOF_INCREMENT_REGISTRATION_GROUP() //BOOST_TYPEOF_REGISTER_TEMPLATE(boost::function, 1) // (1) BOOST_TYPEOF_REGISTER_TEMPLATE(boost::function1, 2) // (2) int main() { typedef BOOST_TYPEOF(&boost::function<int (int)>::operator()) f; return 0; } In order to compile this (on MSVC 8.0 and GCC 4.5.3) with BOOST_TYPEOF_EMULATION #defined, I have to register boost::function1 as in line (2) but I'd expect it to work with the registration of boost::function of line (1) instead. Why do I have to register boost::function1 (2) instead of boost::function (1) for type-of emulation? Thanks a lot. --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/boost-function-why-do-I-function1-for-ty… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 2

[Review Request] Multiprecision Arithmetic Library
by John Maddock 10 Apr '12

10 Apr '12

Folks, I'd like to ask for a formal review of the Multiprecision Arithmetic Library, currently in the sandbox. Features: * Expression template enabled front end. * Support for Integer, Rational and Floating Point types. Supported Integer backends: * GMP. * Libtommath. * cpp_int. cpp_int is an all C++ Boost licensed backend, supports both arbitrary precision types (with Allocator support), and signed and unsigned fixed precision types (with no memory allocation). There are also some integer specific functions - for Miller Rabin testing, bit fiddling, random numbers. Plus interoperability with Boost.Rational (though that loses the expression template frontend). Supported Rational Backends: * GMP * libtommath * cpp_int (as above) Supported Floating point backends: * GMP * MPFR * cpp_dec_float cpp_dec_float is an all C++ Boost licensed type, adapted from Christopher Kormanyos' e_float code (published in TOMS last year). All the floating point types, have full std lib support (cos sin exp, pow etc), as well as full interoperability with Boost.Math. There's nothing in principal to prevent extension to complex numbers and interval arithmetic types (plus any other number types I've forgotten!), but I've run out of energy for now ;-) Code is in the sandbox under /big_number/. Docs can be viewed online here: http://svn.boost.org/svn/boost/sandbox/big_number/libs/multiprecision/doc/h… And of course, I'm looking for a review manager ;-) Many thanks, John.

14 76

[config] unexpected explicit operators conversion on some compilers.
by Vicente J. Botet Escriba 10 Apr '12

10 Apr '12

Hi, Given the following explicit bool conversion template<typename Mutex> class unique_lock { public: explicit operator bool() const BOOST_NOEXCEPT I was expecting the following code to compile fail (note the int cast) boost::unique_lock<boost::mutex> lk0; int i = int(lk0); It fails with gcc-4.7.0, but compile with gcc-4.6.2 and clang-3.0 (I have not tested yet with msvc). When BOOST_NO_EXPLICIT_CONVERSION_OPERATORS is defined I use the bool safe idiom to emulate the conversion #if defined(BOOST_NO_EXPLICIT_CONVERSION_OPERATORS) typedef void (unique_lock::*bool_type)(); operator bool_type() const BOOST_NOEXCEPT; bool operator!() const BOOST_NOEXCEPT; #else explicit operator bool() const BOOST_NOEXCEPT; #endif and in this case the compile fail as desired. Do we need a new macro to state that even if explicit operators are provide, there are some unexpected conversions that could be introduced? Best, Vicente

1 1

Release branch open for new libraries?
by Marshall Clow 10 Apr '12

10 Apr '12

When will the release branch be open for new libraries (for 1.50)? The calendar on Boost.org shows no dates for 1.50 at all. Thanks! -- 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 8

[test] SIGSEGV on simple test when -ansi is set with gcc-4.7.0 on Darwin
by Vicente J. Botet Escriba 10 Apr '12

10 Apr '12

Hi, The following simple test signals SIGSEGV when line ***1 is uncommented. When I recompile Boost.Test and the tests with same project requirements (see below) everything is OK. Is this the correct behavior? Should -ansi be set in a coherent way? Note. I have no issue mixing -ansi with clang-3.0. Thanks, Vicente P.S. I could attach the complete logs if needed (not so big) ============================= #include <boost/test/unit_test.hpp> void test_1() { BOOST_CHECK(true); } boost::unit_test::test_suite* init_unit_test_suite(int, char*[]) { boost::unit_test::test_suite* test = BOOST_TEST_SUITE("test suite"); test->add(BOOST_TEST_CASE(test_1)); test->add(BOOST_TEST_CASE(test_1)); test->add(BOOST_TEST_CASE(test_1)); test->add(BOOST_TEST_CASE(test_1)); test->add(BOOST_TEST_CASE(test_1)); //test->add(BOOST_TEST_CASE(test_1)); // *** 1 return test; } ============================= Here it is the log ============================= darwin.link ../../../bin.v2/libs/thread/test/test_ansi.test/darwin-4.7.0x/debug/test_ansi "/usr/local/gcc-4-7-svn/bin/g++" -o "../../../bin.v2/libs/thread/test/test_ansi.test/darwin-4.7.0x/debug/test_ansi" "../../../bin.v2/libs/thread/test/test_ansi.test/darwin-4.7.0x/debug/test_ansi.o" "../../../bin.v2/libs/test/build/darwin-4.7.0x/debug/link-static/libboost_unit_test_framework.a" -g testing.capture-output ../../../bin.v2/libs/thread/test/test_ansi.test/darwin-4.7.0x/debug/test_ansi.run "../../../bin.v2/libs/thread/test/test_ansi.test/darwin-4.7.0x/debug/test_ansi" > "../../../bin.v2/libs/thread/test/test_ansi.test/darwin-4.7.0x/debug/test_ansi.output" 2>&1 status=$? echo >> "../../../bin.v2/libs/thread/test/test_ansi.test/darwin-4.7.0x/debug/test_ansi.output" echo EXIT STATUS: $status >> "../../../bin.v2/libs/thread/test/test_ansi.test/darwin-4.7.0x/debug/test_ansi.output" if test $status -eq 0 ; then cp "../../../bin.v2/libs/thread/test/test_ansi.test/darwin-4.7.0x/debug/test_ansi.output" "../../../bin.v2/libs/thread/test/test_ansi.test/darwin-4.7.0x/debug/test_ansi.run" fi verbose=0 if test $status -ne 0 ; then verbose=1 fi if test $verbose -eq 1 ; then echo ====== BEGIN OUTPUT ====== cat "../../../bin.v2/libs/thread/test/test_ansi.test/darwin-4.7.0x/debug/test_ansi.output" echo ====== END OUTPUT ====== fi exit $status ====== BEGIN OUTPUT ====== Running 6 test cases... unknown location:0: fatal error in "test_1": signal: SIGSEGV, si_code: 0 (memory access violation at address: 0x00000000) test_ansi.cpp:5: last checkpoint *** 1 failure detected in test suite "Master Test Suite" ============================= Here there are the client project requirements ============================= project : requirements <warnings>all <toolset>darwin:<cxxflags>-ansi ;

1 0

forgot svn password
by Jeffrey Lee Hellrung, Jr. 10 Apr '12

10 Apr '12

Okay, given that my boost SVN account is relatively new, and I hadn't logged in for a while, hopefully it's not too unbelievable that I've forgotten my password. Embarrassing, yes. What to do? I could not find any password recovery or reset options from svn.boost.org. username = jeffrey.hellrung Thanks, and sorry for the noise, - Jeff

2 1

[scope_exit] trunk tests fail on sun compiler
by lcaminiti 09 Apr '12

09 Apr '12

Hello all, I'm trying to get ScopeExit to work on Sun. 1) First it looked like all tests fail on this compiler: http://www.boost.org/development/tests/trunk/developer/scope_exit.html 2) However, I installed Solaris Studio 12.3 on my Ubuntu 10 and it seems that I can compile ScopeExit just fine with the following" $ CC -I /usr/include/i386-linux-gnu/ -I ../../.. -DBOOST_TYPEOF_EMULATION world_seq.cpp Note that: a) Sun does not support variadic macros so only ScopeExit sequence syntax will work. b) Sun does not support native type-of so BOOST_TYPEOF_EMULATION needs to be defined. Therefore, all original ScopeExit type-of emulation tests named `emulation_...` should compile (because they use the sequence syntax and define BOOST_TYPEOF_EMULATION). However, they fail... why? 3) Why when I click on the "fail" link for these tests I get no information on the Sun compiler's output? For example: http://www.boost.org/development/tests/trunk/developer/output/Sandia-sun-bo… If I follow this link I get "Error extracting file: No matching files were found.". What does this mean? Thanks a lot! --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/boost-scope-exit-trunk-tests-fail-on-sun… Sent from the Boost - Dev mailing list archive at Nabble.com.

6 34

Metaprogram benchmarks
by Dave Abrahams 09 Apr '12

09 Apr '12

In order to measure the compile-time efficiency of various C++11 metaprogramming techniques, I'd like to put together a set of benchmarks, and I wanted to discuss here what kinds of tests might be appropriate. Aleksey and I came up with some benchmarks for an appendix to http://boostpro.com/mplbook/, but some of those are lost and they're all getting a bit crusty. Certainly, I have no confidence that they are realistic or useful. If anyone has ideas about this, I'd be very glad to hear them. Thanks in advance, -- Dave Abrahams BoostPro Computing http://www.boostpro.com

7 9

[string_algo] ilexicographical_compare()/is_iless() bug?
by Dmitry Vinogradov 08 Apr '12

08 Apr '12

I want to share a problem using ilexicographical_compare(). I think that ilexicographical_compare() must compare two strings in "alphabetical" order, the order letters appear in alphabet. But ilexicographical_compare() uses is_iless() to compare letters. And such comparison looks like: std::toupper<T1>(Arg1,m_Loc)<std::toupper<T2>(Arg2,m_Loc); So, in fact, letters are compared depending on their position in a charset. It's not always match the alphabet order. Examples are Cyrillic letters "Io" and "i" (Unicode 0451 and 0456). I think the right solution is to compare like this: T1 Ch1 = std::toupper<T1>(Arg1,m_Loc); T2 Ch2 = std::toupper<T2>(Arg2,m_Loc); return std::use_facet< std::collate<typename CharType> > (m_Loc).compare(&Ch1, &Ch1 + 1, &Ch2, &Ch2 + 1);

3 2

[SVN] Spurious changes to lots of files....
by John Maddock 08 Apr '12

08 Apr '12

I'm not picking on anyone in particular here, just noticing that some stuff that really shouldn't have changed is quite often getting "touched" due to changes to svn:mergeinfo. For example, if I look at the revision log for boost/config.hpp in the release branch I see: Revision: 77591 Author: eric_niebler Date: 27 March 2012 20:28:30 Message: merge [77416] from trunk, fixes #6131, fixes #6455 Revision: 77589 Author: eric_niebler Date: 27 March 2012 19:53:50 Message: merge [77417],[77437],[77422],[77587] from trunk ---- Revision: 77447 Author: eric_niebler Date: 21 March 2012 04:22:38 Message: merge [77446] from trunk ---- Revision: 77420 Author: eric_niebler Date: 19 March 2012 21:33:14 Message: merge [77419] from trunk ---- Revision: 77413 Author: eric_niebler Date: 19 March 2012 20:26:44 Message: merge [77412] from trunk, fixes #6702 ---- Revision: 77411 Author: eric_niebler Date: 19 March 2012 20:07:11 Message: merge [77320] from trunk ---- Revision: 76784 Author: eric_niebler Date: 29 January 2012 21:58:13 Message: merge [76637] from trunk ---- Revision: 76536 Author: jewillco Date: 15 January 2012 23:52:45 Message: Merged r75066, r75067, r75124, r75140, r75165, r75861, r75862, r75863, r75878, r75906, r75970, r75973, r75974, and r76394 from trunk ---- Revision: 76535 Author: jewillco Date: 15 January 2012 23:32:09 Message: Merged r76050, r75547, r75891, r76049, r76083, and r76439 from trunk (reverse_graph bug fixes and fix for #6293); refs #6293 ---- Revision: 76480 Author: eric_niebler Date: 14 January 2012 05:21:11 Message: merge [76479] from trunk ---- Before finally we get to a "real" change: Revision: 76339 Author: johnmaddock Date: 07 January 2012 17:29:04 Message: Merge config changes from Trunk. ---- If we pick out the latest of the changes above we see that a huge number of files have been "touched" in this way: Revision: 77591 Author: eric_niebler Date: 27 March 2012 20:28:30 Message: merge [77416] from trunk, fixes #6131, fixes #6455 ---- Modified : /branches/release Modified : /branches/release/INSTALL Modified : /branches/release/Jamroot Modified : /branches/release/LICENSE_1_0.txt Modified : /branches/release/boost Modified : /branches/release/boost/algorithm/string Modified : /branches/release/boost/algorithm/string/detail/case_conv.hpp Modified : /branches/release/boost/algorithm/string/detail/classification.hpp Modified : /branches/release/boost/array.hpp Modified : /branches/release/boost/bimap Modified : /branches/release/boost/concept_check.hpp Modified : /branches/release/boost/config Modified : /branches/release/boost/config.hpp Modified : /branches/release/boost/cregex.hpp Modified : /branches/release/boost/cstdint.hpp Modified : /branches/release/boost/current_function.hpp Modified : /branches/release/boost/date_time/c_time.hpp Modified : /branches/release/boost/date_time/date_formatting.hpp Modified : /branches/release/boost/date_time/filetime_functions.hpp Modified : /branches/release/boost/date_time/gregorian_calendar.ipp Modified : /branches/release/boost/date_time/posix_time/time_serialize.hpp Modified : /branches/release/boost/date_time/strings_from_facet.hpp Modified : /branches/release/boost/date_time/time_facet.hpp Modified : /branches/release/boost/date_time/tz_db_base.hpp Modified : /branches/release/boost/detail Modified : /branches/release/boost/detail/fenv.hpp Modified : /branches/release/boost/detail/interlocked.hpp Modified : /branches/release/boost/dynamic_bitset/dynamic_bitset.hpp Modified : /branches/release/boost/filesystem Modified : /branches/release/boost/filesystem.hpp Modified : /branches/release/boost/foreach.hpp Modified : /branches/release/boost/foreach_fwd.hpp Modified : /branches/release/boost/function Modified : /branches/release/boost/function/function_template.hpp Modified : /branches/release/boost/functional Modified : /branches/release/boost/fusion Modified : /branches/release/boost/geometry Modified : /branches/release/boost/geometry/algorithms Modified : /branches/release/boost/geometry/arithmetic Modified : /branches/release/boost/geometry/core Modified : /branches/release/boost/geometry/domains Modified : /branches/release/boost/geometry/geometries Modified : /branches/release/boost/geometry/geometry.hpp Modified : /branches/release/boost/geometry/io Modified : /branches/release/boost/geometry/io/dsv Modified : /branches/release/boost/geometry/iterators Modified : /branches/release/boost/geometry/multi Modified : /branches/release/boost/geometry/policies Modified : /branches/release/boost/geometry/strategies Modified : /branches/release/boost/geometry/util Modified : /branches/release/boost/geometry/views Modified : /branches/release/boost/gil Modified : /branches/release/boost/graph Modified : /branches/release/boost/heap Modified : /branches/release/boost/icl Modified : /branches/release/boost/integer Modified : /branches/release/boost/integer.hpp Modified : /branches/release/boost/integer_fwd.hpp Modified : /branches/release/boost/integer_traits.hpp Modified : /branches/release/boost/interprocess Modified : /branches/release/boost/intrusive Modified : /branches/release/boost/io Modified : /branches/release/boost/iostreams Modified : /branches/release/boost/iterator Modified : /branches/release/boost/iterator/iterator_facade.hpp Modified : /branches/release/boost/locale Modified : /branches/release/boost/locale.hpp Modified : /branches/release/boost/math Modified : /branches/release/boost/math_fwd.hpp Modified : /branches/release/boost/msm Modified : /branches/release/boost/msm/active_state_switching_policies.hpp Modified : /branches/release/boost/msm/back Modified : /branches/release/boost/msm/back/args.hpp Modified : /branches/release/boost/msm/back/bind_helpers.hpp Modified : /branches/release/boost/msm/back/common_types.hpp Modified : /branches/release/boost/msm/back/copy_policies.hpp Modified : /branches/release/boost/msm/back/default_compile_policy.hpp Modified : /branches/release/boost/msm/back/dispatch_table.hpp Modified : /branches/release/boost/msm/back/favor_compile_time.hpp Modified : /branches/release/boost/msm/back/fold_to_list.hpp Modified : /branches/release/boost/msm/back/history_policies.hpp Modified : /branches/release/boost/msm/back/metafunctions.hpp Modified : /branches/release/boost/msm/back/mpl_graph_fsm_check.hpp Modified : /branches/release/boost/msm/back/no_fsm_check.hpp Modified : /branches/release/boost/msm/back/queue_container_circular.hpp Modified : /branches/release/boost/msm/back/queue_container_deque.hpp Modified : /branches/release/boost/msm/back/state_machine.hpp Modified : /branches/release/boost/msm/back/tools.hpp Modified : /branches/release/boost/msm/common.hpp Modified : /branches/release/boost/msm/front Modified : /branches/release/boost/msm/front/common_states.hpp Modified : /branches/release/boost/msm/front/completion_event.hpp Modified : /branches/release/boost/msm/front/detail Modified : /branches/release/boost/msm/front/detail/common_states.hpp Modified : /branches/release/boost/msm/front/detail/row2_helper.hpp Modified : /branches/release/boost/msm/front/euml Modified : /branches/release/boost/msm/front/euml/algorithm.hpp Modified : /branches/release/boost/msm/front/euml/common.hpp Modified : /branches/release/boost/msm/front/euml/container.hpp Modified : /branches/release/boost/msm/front/euml/euml.hpp Modified : /branches/release/boost/msm/front/euml/euml_typeof.hpp Modified : /branches/release/boost/msm/front/euml/guard_grammar.hpp Modified : /branches/release/boost/msm/front/euml/iteration.hpp Modified : /branches/release/boost/msm/front/euml/operator.hpp Modified : /branches/release/boost/msm/front/euml/phoenix_placeholders.hpp Modified : /branches/release/boost/msm/front/euml/querying.hpp Modified : /branches/release/boost/msm/front/euml/state_grammar.hpp Modified : /branches/release/boost/msm/front/euml/stl.hpp Modified : /branches/release/boost/msm/front/euml/stt_grammar.hpp Modified : /branches/release/boost/msm/front/euml/transformation.hpp Modified : /branches/release/boost/msm/front/functor_row.hpp Modified : /branches/release/boost/msm/front/internal_row.hpp Modified : /branches/release/boost/msm/front/row2.hpp Modified : /branches/release/boost/msm/front/state_machine_def.hpp Modified : /branches/release/boost/msm/front/states.hpp Modified : /branches/release/boost/msm/mpl_graph Modified : /branches/release/boost/msm/msm_grammar.hpp Modified : /branches/release/boost/msm/proto_config.hpp Modified : /branches/release/boost/msm/row_tags.hpp Modified : /branches/release/boost/numeric/ublas Modified : /branches/release/boost/numeric/ublas/functional.hpp Modified : /branches/release/boost/pool Modified : /branches/release/boost/preprocessor Modified : /branches/release/boost/program_options Modified : /branches/release/boost/program_options/detail/parsers.hpp Modified : /branches/release/boost/program_options/parsers.hpp Modified : /branches/release/boost/property_tree Modified : /branches/release/boost/python Modified : /branches/release/boost/range Modified : /branches/release/boost/regex Modified : /branches/release/boost/regex.h Modified : /branches/release/boost/regex.hpp Modified : /branches/release/boost/regex_fwd.hpp Modified : /branches/release/boost/signals Modified : /branches/release/boost/signals2 Modified : /branches/release/boost/signals2.hpp Modified : /branches/release/boost/spirit Modified : /branches/release/boost/spirit/home Modified : /branches/release/boost/spirit/home/karma Modified : /branches/release/boost/spirit/home/support/attributes.hpp Modified : /branches/release/boost/statechart Modified : /branches/release/boost/static_assert.hpp Modified : /branches/release/boost/system Modified : /branches/release/boost/thread Modified : /branches/release/boost/thread.hpp Modified : /branches/release/boost/timer.hpp Modified : /branches/release/boost/token_functions.hpp Modified : /branches/release/boost/tr1 Modified : /branches/release/boost/type_traits Modified : /branches/release/boost/type_traits.hpp Modified : /branches/release/boost/typeof/message.hpp Modified : /branches/release/boost/typeof/register_functions.hpp Modified : /branches/release/boost/typeof/register_functions_iterate.hpp Modified : /branches/release/boost/typeof/typeof.hpp Modified : /branches/release/boost/typeof/unsupported.hpp Modified : /branches/release/boost/unordered Modified : /branches/release/boost/utility Modified : /branches/release/boost/utility/value_init.hpp Modified : /branches/release/boost/uuid Modified : /branches/release/boost/variant Modified : /branches/release/boost/version.hpp Modified : /branches/release/boost/wave Modified : /branches/release/boost/xpressive Modified : /branches/release/boost-build.jam Modified : /branches/release/boost.css Modified : /branches/release/boost.png Modified : /branches/release/boostcpp.jam Modified : /branches/release/bootstrap.bat Modified : /branches/release/bootstrap.sh Modified : /branches/release/doc Modified : /branches/release/index.htm Modified : /branches/release/index.html Modified : /branches/release/libs Modified : /branches/release/libs/algorithm/minmax/index.html Modified : /branches/release/libs/algorithm/string Modified : /branches/release/libs/algorithm/string/doc/Jamfile.v2 Modified : /branches/release/libs/array Modified : /branches/release/libs/array/test/array0.cpp Modified : /branches/release/libs/array/test/array2.cpp Modified : /branches/release/libs/array/test/array6.cpp Modified : /branches/release/libs/bimap Modified : /branches/release/libs/config Modified : /branches/release/libs/date_time Modified : /branches/release/libs/date_time/data/date_time_zonespec.csv Modified : /branches/release/libs/date_time/example/gregorian/days_between_new_years.cpp Modified : /branches/release/libs/date_time/example/gregorian/days_since_year_start.cpp Modified : /branches/release/libs/date_time/example/gregorian/days_till_new_year.cpp Modified : /branches/release/libs/date_time/example/gregorian/month_add.cpp Modified : /branches/release/libs/date_time/example/local_time/flight.cpp Modified : /branches/release/libs/date_time/example/local_time/local_date_time.cpp Modified : /branches/release/libs/date_time/example/posix_time/print_hours.cpp Modified : /branches/release/libs/date_time/example/posix_time/time_math.cpp Modified : /branches/release/libs/date_time/example/tutorial/io_tutorial.cpp Modified : /branches/release/libs/date_time/test/posix_time/testtime_facet.cpp Modified : /branches/release/libs/date_time/test/posix_time/testtime_input_facet.cpp Modified : /branches/release/libs/date_time/xmldoc/date_class.xml Modified : /branches/release/libs/date_time/xmldoc/usage_examples.xml Modified : /branches/release/libs/detail Modified : /branches/release/libs/filesystem Modified : /branches/release/libs/function Modified : /branches/release/libs/functional Modified : /branches/release/libs/fusion Modified : /branches/release/libs/geometry Modified : /branches/release/libs/geometry/doc Modified : /branches/release/libs/geometry/doc/Jamfile.v2 Modified : /branches/release/libs/geometry/doc/about_documentation.qbk Modified : /branches/release/libs/geometry/doc/acknowledgments.qbk Modified : /branches/release/libs/geometry/doc/compiling.qbk Modified : /branches/release/libs/geometry/doc/concept Modified : /branches/release/libs/geometry/doc/copyright_note_policy.txt Modified : /branches/release/libs/geometry/doc/design_rationale.qbk Modified : /branches/release/libs/geometry/doc/doxy Modified : /branches/release/libs/geometry/doc/generated Modified : /branches/release/libs/geometry/doc/geometry.qbk Modified : /branches/release/libs/geometry/doc/html Modified : /branches/release/libs/geometry/doc/imports.qbk Modified : /branches/release/libs/geometry/doc/introduction.qbk Modified : /branches/release/libs/geometry/doc/make_qbk.py Modified : /branches/release/libs/geometry/doc/matrix.qbk Modified : /branches/release/libs/geometry/doc/quickref.xml Modified : /branches/release/libs/geometry/doc/quickstart.qbk Modified : /branches/release/libs/geometry/doc/readme.txt Modified : /branches/release/libs/geometry/doc/reference Modified : /branches/release/libs/geometry/doc/reference.qbk Modified : /branches/release/libs/geometry/doc/release_notes.qbk Modified : /branches/release/libs/geometry/doc/src Modified : /branches/release/libs/geometry/example Modified : /branches/release/libs/geometry/index.html Modified : /branches/release/libs/geometry/test Modified : /branches/release/libs/graph/doc Modified : /branches/release/libs/graph_parallel Modified : /branches/release/libs/heap Modified : /branches/release/libs/icl Modified : /branches/release/libs/icl/doc Modified : /branches/release/libs/icl/doc/html Modified : /branches/release/libs/icl/doc/html/header/boost/icl Modified : /branches/release/libs/icl/test Modified : /branches/release/libs/icl/test/test_doc_code_ Modified : /branches/release/libs/integer Modified : /branches/release/libs/interprocess Modified : /branches/release/libs/intrusive Modified : /branches/release/libs/io Modified : /branches/release/libs/io/doc Modified : /branches/release/libs/iostreams Modified : /branches/release/libs/iterator Modified : /branches/release/libs/libraries.htm Modified : /branches/release/libs/locale Modified : /branches/release/libs/locale/src Modified : /branches/release/libs/maintainers.txt Modified : /branches/release/libs/math Modified : /branches/release/libs/math/doc/sf_and_dist/faq.qbk Modified : /branches/release/libs/math/doc/sf_and_dist/html/math_toolkit/main_overview/faq.html Modified : /branches/release/libs/math/test/s_.ipp Modified : /branches/release/libs/mpi/build Modified : /branches/release/libs/mpl/doc/refmanual/broken-compiler-workarounds.html Modified : /branches/release/libs/mpl/doc/refmanual/categorized-index-concepts.html Modified : /branches/release/libs/mpl/doc/refmanual/cfg-no-preprocessed-headers.html Modified : /branches/release/libs/mpl/doc/refmanual/composition-and-argument-binding.html Modified : /branches/release/libs/mpl/doc/refmanual/data-types-concepts.html Modified : /branches/release/libs/mpl/doc/refmanual/data-types-miscellaneous.html Modified : /branches/release/libs/mpl/doc/refmanual/extensible-associative-sequence.html Modified : /branches/release/libs/mpl/doc/refmanual/inserter-class.html Modified : /branches/release/libs/mpl/doc/refmanual/tag-dispatched-metafunction.html Modified : /branches/release/libs/mpl/doc/refmanual/trivial-metafunctions-summary.html Modified : /branches/release/libs/mpl/doc/src/refmanual/Iterators-Iterator.rst Modified : /branches/release/libs/msm Modified : /branches/release/libs/numeric/ublas Modified : /branches/release/libs/numeric/ublas/doc Modified : /branches/release/libs/parameter/doc/html/index.html Modified : /branches/release/libs/phoenix/doc/basics.qbk Modified : /branches/release/libs/phoenix/doc/examples/extending_actors.qbk Modified : /branches/release/libs/phoenix/doc/organisation.qbk Modified : /branches/release/libs/pool Modified : /branches/release/libs/preprocessor Modified : /branches/release/libs/program_options Modified : /branches/release/libs/program_options/test/parsers_test.cpp Modified : /branches/release/libs/property_tree Modified : /branches/release/libs/python Modified : /branches/release/libs/range Modified : /branches/release/libs/regex Modified : /branches/release/libs/signals Modified : /branches/release/libs/signals2 Modified : /branches/release/libs/signals2/doc Modified : /branches/release/libs/spirit Modified : /branches/release/libs/spirit/classic/example Modified : /branches/release/libs/spirit/doc Modified : /branches/release/libs/spirit/example Modified : /branches/release/libs/spirit/phoenix Modified : /branches/release/libs/spirit/test Modified : /branches/release/libs/spirit/test/qi/optional.cpp Modified : /branches/release/libs/statechart Modified : /branches/release/libs/static_assert Modified : /branches/release/libs/system Modified : /branches/release/libs/thread Modified : /branches/release/libs/thread/test Modified : /branches/release/libs/timer Modified : /branches/release/libs/tr1 Modified : /branches/release/libs/type_traits Modified : /branches/release/libs/typeof/doc/typeof.qbk Modified : /branches/release/libs/unordered Modified : /branches/release/libs/utility Modified : /branches/release/libs/utility/assert.html Modified : /branches/release/libs/utility/assert_test.cpp Modified : /branches/release/libs/utility/swap/test/std_bitset.cpp Modified : /branches/release/libs/utility/swap.html Modified : /branches/release/libs/utility/value_init.htm Modified : /branches/release/libs/utility/value_init_test.cpp Modified : /branches/release/libs/uuid Modified : /branches/release/libs/wave Modified : /branches/release/more Modified : /branches/release/rst.css Modified : /branches/release/status Modified : /branches/release/status/Jamfile.v2 Modified : /branches/release/status/expected_results.xml Modified : /branches/release/status/explicit-failures-markup.xml Modified : /branches/release/status/explicit-failures.xsd Modified : /branches/release/tools Modified : /branches/release/tools/bcp Modified : /branches/release/tools/boostbook Modified : /branches/release/tools/build/v2 Modified : /branches/release/tools/build/v2/tools/mpi.jam Modified : /branches/release/tools/inspect Modified : /branches/release/tools/quickbook Modified : /branches/release/tools/regression Modified : /branches/release/tools/regression/src/library_status.cpp Modified : /branches/release/tools/release Modified : /branches/release/tools/wave As well as cluttering up the revision logs, this often leads to property and/or tree conflicts when merging your own stuff, and I can't tell you how annoying that is to figure out! :-( BTW, my sincere apologies to Eric here - he just happened to be the latest culprit - can some SVN guru suggest how to prevent this sort of spurious changing going on? BTW2, lest this turn into "my extra advanced version control system doesn't do messy stuff like this" conversation - I'm sure you're correct - some other version control system probably doesn't have this trap - but I sure bet it has other traps just as annoying for the unwary. Just saying.... Thanks, John.

4 6

C++ Now! Early Bird Registration Ending Soon
by Jon Kalb 08 Apr '12

08 Apr '12

The fifteenth of this month is the end of Early Bird registration. Register by the end of next week to reserve your place and save on registration. Featuring 3 keynote speakers headlining 3 tracks of 50+ session brought to by 35+ presenters, this year¹s conference is our largest and most ambitious. What isn¹t bigger is the registration fee. If you beat the April 15th deadline you can enjoy the conference offering the most complete C++11 tutorial coverage of the year and save money too. See you in Aspen! Registration: http://cppnow.eventbrite.com/?ref=ecount Jon

1 0

Nightly testing broken due to missing file
by Belcourt, K. Noel 07 Apr '12

07 Apr '12

error: Unable to find file or target named error: './sync/mutual_exclusion/locks/upgrade_lock/cons/ move_ctor_shared_lock_until_pass.cpp' error: referred from project at error: '../libs/thread/test'

3 2

C++11 Metaprogramming
by Dave Abrahams 07 Apr '12

07 Apr '12

Hi All, I am on the C++Now 2012 schedule giving a talk on metaprogramming in C++11, which is really just supposed to be an overview of the state of the art. I am just at the beginnings of my research for this presentation, having learned a few things and done a few experiments, and it seemed to me foolish not to ask the Boost community for its insights. I'm sure y'all have come up with many neat tricks and techniques. If you'd care to share them here, that would be much appreciated. TIA, -- Dave Abrahams BoostPro Computing http://www.boostpro.com

13 38

Re: [boost] C++11 Metaprogramming
by Andrzej Krzemienski 07 Apr '12

07 Apr '12

> On 06/04/12 09:04, Andrzej Krzemienski wrote: >>> And this is the worst part: I forgot the >> "typename". Having to type this "typename" is really terrible and just >> scares off many people. If you do not mind it, it only means that you got >> used to it; but people should not be forced to get used to too many >> gotchas. > > The language requires to specify whenever dependent names in template > contexts are anything else than values (i.e. types or templates). > > There is no substitute for learning the basics of the language. This is > not a gotcha, just normal usage of templates. Clearly, if you do not find requiring of the programmers to type this "typename" in these places even slightly wrong, you will not appreciate alias templates as a useful addition to meta-programming. Also, if you did a lot of advanced meta-programming, you have probably mastered the rules of template syntax, and find it difficult to sympathize with those that did not master the subject. But looking at it from the fresh programmer's perspective, the fact that the language requires "to specify whenever dependent names in template contexts are anything else than values" means that the language is not friendly to the fresh programmers (I understand that there are good reasons for requiring this, but still...). Based on the Wkipedia's definition of "gotcha" I interpret this typename as one. "In programming, a gotcha is a feature of a system, a program or a programming language that works in the way it is documented but is counter-intuitive and almost invites mistakes because it is both enticingly easy to invoke and completely unexpected and/or unreasonable in its outcome." It (the usage of typename) only appears as "normal usage" after you are past the stage of surprise. The context of your reply seems to imply that whoever finds this behavior surprising is guilty of not having acquired the basics of the language. Unless I misunderstood you, I think this position is a bit unfair. Regards, &rzej

6 5

boost.asio and boost.bind question
by Philip Bennefall 07 Apr '12

07 Apr '12

Hi all, I have been using Asio and Bind for a server with great success, however I just thought of something that I wanted to clarify. If I have a class method and construct a string within this method, and then call post on the IO service with a bind generated function object that takes this local std::string as one of its arguments, is the string then copied? Naturally it will be destroyed after the asynchronous invokation when the method returns, so is it just by chance that this has worked so far? Is it undefined behavior? Example: void dummy() { string final_message="some_data"; the_client->partner_sync.post( boost::bind( &deliver_message, the_client, the_client->partner, final_message) ); } deliver_message is a global function. the_client and the_client->partner are both smart pointers to instances of the client class, and partner_sync is a strand that belongs to the client class. Is this legal usage, or am I messing things up? Do I need to keep the string around until the completion handler is invoked? Or does bind take care of this? I keep the buffer around whenever I use the asynchronous sending methods in Boost Asio as this is explicitly stated in the documentation, but is this case the same? Thanks in advance for any clarifications. Kind regards, Philip Bennefall

3 2

[config] BOOST_STL_SUPPORTS_NEW_UNICODE_LOCALES macro?
by Antony Polukhin 07 Apr '12

07 Apr '12

Hi, I'm interested in preprocessor macro, that provides info about std::locale() usability with char16_t and char32_t character types. Currently, some compilers provide new Unicode character types, but calls to std::locale() generate runtime error. I'd like to use that macro to: * provide compile time errors instead of runtime errors * enable/disable some Boost.Lexical_cast tests. Another useful macro would be BOOST_UNICODE_FULL_SUPPORT. It can be defined like this: #if !defined(BOOST_NO_CHAR32_T) \ && !defined(BOOST_NO_CHAR16_T) \ && !defined(BOOST_NO_UNICODE_LITERALS) \ && defined(BOOST_STL_SUPPORTS_NEW_UNICODE_LOCALES) #define BOOST_UNICODE_FULL_SUPPORT #endif -- Best regards, Antony Polukhin

1 0

Re: [boost] C++11 Metaprogramming
by Andrzej Krzemienski 06 Apr '12

06 Apr '12

> on Thu Apr 05 2012, Andrzej Krzemienski <akrzemi1-AT-gmail.com> wrote: > >> For the end users of meta-programming library (at least those interested in >> type transformations), I believe that alias templates offer a significant >> improvement to the interface: >> http://akrzemi1.wordpress.com/2012/03/19/meta-functions-in-c11/ > > Yeah... I started doing a bunch of that, but I am not yet convinced it's > an overall improvement. One thing you emphatically *don't* get with > that formulation is lazy evaluation. remove_pointer<int> is valid until > you instantiate it but RemovePointer<int> is not, and the former is > often quite useful. Also, you can't use metafunction forwarding—which > also eliminates vast amounts of typing—with RemovePointer. Also, you > end up needing to define more names than you otherwise would (e.g. both > remove_pointer and RemovePointer). My standard approach when doing this > has been to name them remove_pointer_ and remove_pointer, so at least > they have an obvious and mechanical relationship. I guess my understanding of the name "meta-programming" might be a bit different, and term "end user" might have been too much a mental shortcut, but let me share my view of someone that doesn't want to go to deep into the meta-programming but still needs to use the simple forms thereof (like type traits). This is a somewhat simplified version of what I was facing recently. I need a function that perfect-forwards the argument but returns by value: template <class T> T fun(T&& v); The above is incorrect, because T may be deduced to be an lvalue reference. But be sympathetic, perfect-forwarding is already hard enough to acquire. I need type trait std::decay: template <class T> std::decay<T> fun(T&& v); But this does not work! I forgot "::type". Let's try again: template <class T> std::decay<T>::type fun(T&& v); No. It still doesn't work. And this is the worst part: I forgot the "typename". Having to type this "typename" is really terrible and just scares off many people. If you do not mind it, it only means that you got used to it; but people should not be forced to get used to too many gotchas. Alias templates offer a simplification that can improve the "teachability" of type traits. You may not consider type traits a proper meta-programming, and all I say might be a bit off topic. But if we had these alias templates for type traits, it looks to me, it would make a soft introduction to meta-programming for the newbies. Regards, &rzej

3 2