March 2010 - Boost - lists.preview.boost.org

[bimap] Includes serialization headers even if BOOST_BIMAP_DISABLE_SERIALIZATION is defined
by Christian Holmquist 10 Mar '10

10 Mar '10

Hello, I noticed this issue with boost 1.42, but it might have been there for a while. Quite a few headers have #include <boost/serialization/nvp.hpp> I think the above should be guared with #ifndef BOOST_BIMAP_DISABLE_SERIALIZATION #include <boost/serialization/nvp.hpp> #endif Regards, Christian

2 2

[signals2] missing Jamfile and compile errors with VC8
by Michael Caisse 10 Mar '10

10 Mar '10

I was surprised to not find a Jamfile in the libs/signals2/example directory. Please find an example below. The reason I headed toward the examples is that I'm having trouble with this type of line and VC8: typedef boost::signals2::signal<void ()> signal_t; In fact doc_view_acm.cpp will not compile because of it. disconnect_and_block.cpp also has compilation errors. Results verified in 1.41 and 1.42 with VC8 and gcc 4.3.2 --------------------------------------------------------- # Boost.Signals2 Library project : requirements <source>/boost//headers ; exe hello_world_slot : hello_world_slot.cpp ; exe hello_world_multi_slot : hello_world_multi_slot.cpp ; exe ordering_slots : ordering_slots.cpp ; exe passing_slots : passing_slots.cpp ; exe extended_slot : extended_slot.cpp ; exe custom_combiners : custom_combiners.cpp ; exe disconnect_and_block : disconnect_and_block.cpp ; exe doc_view : doc_view.cpp ; exe doc_view_acm : doc_view_acm.cpp ; exe doc_view_acm_deconstruct : doc_view_acm_deconstruct.cpp ; exe postconstructor_ex1 : postconstructor_ex1.cpp ; exe postconstructor_ex2 : postconstructor_ex2.cpp ; exe predestructor_example : predestructor_example.cpp ; exe signal_return_value : signal_return_value.cpp ; exe slot_arguments : slot_arguments.cpp ; --------------------------------------------------------------- -- ---------------------------------- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com

2 3

[signals2] lamda placeholder collision
by Michael Caisse 10 Mar '10

10 Mar '10

I am converting some older code to use signals2. The old source uses boost.lambda which results in a collision of placeholders from bind (included by signals2) and lambda. I converted to phoenix about a year ago and I'll fix this "problem" by moving the lambdas to phoenix ... but ... what is supposed to be the correct course of action for source wanting to use both signals2 and Boost.Lambda? Regards - michael -- ---------------------------------- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com

2 2

Soc: project idea
by Michele Caini 10 Mar '10

10 Mar '10

Hi all, what about extending GIL with a watermarking framework? I'm not an expert in using GIL, however if users are able to handle images via a generic way, I think it's possible (and quite easy) to develop an infrastructure of algorithms that manage images adding watermarks. Watermarking is a know problem, today. ;-) Michele

1 0

[inspect] More changes to Inspection Report
by Beman Dawes 09 Mar '10

09 Mar '10

More changes to the Inspection Report: * Line numbers are now shown when a problem is associated with a specific line in a file. * Apple macros clashes now show the specific name causing the problem. * Spacing is optimized so that problems without line numbers don't take up so much report space. See the results at http://boost.cowic.de/rc/inspect-trunk.html Thanks to everyone who commented yesterday! --Beman

6 6

enable_shared_from_this2
by Berserker 09 Mar '10

09 Mar '10

After experiencing some troubles with boost::python and enable_shared_from_this (as already reported in the past by someone to Peter Dimov), I started looking at the new (not documented) class enable_shared_from_this2. I made two changes in init_weak_once and now it seems to support shared_from_this in constructors and shared pointers "reinitialization". The original code (from boost 1.40): void init_weak_once() const { if( weak_this_._empty() ) { shared_this_.reset(static_cast< T* >( 0 ), detail::esft2_deleter_wrapper()); weak_this_ = shared_this_; } } The "patched" code: void init_weak_once() const { // Reinitialization support if( weak_this_.expired() ) { // shared_from_this in costructors support shared_this_.reset(static_cast <T*>(const_cast<enable_shared_from_this2>(this)), detail::esft2_deleter_wrapper()); weak_this_ = shared_this_; } } I know that the static_cast/const_cast is "problematic" on VC6 (and maybe other compilers) but it could be solved using an offset from enable_shared_from_this2 * to T *. I've attached a testcase that shows the problems with the current enable_shared_from_this2 implementation (with the proposed patch it works). Any feedback about this? struct null_deleter { template <typename T> inline void operator()(T *p) const { } }; class EnableThisPtrTester : public boost::enable_shared_from_this2<EnableThisPtrTester> { public: EnableThisPtrTester() { } EnableThisPtrTester(shared_ptr<EnableThisPtrTester> &ptr) { ptr = shared_from_this(); BOOST_CHECK(ptr); } }; BOOST_AUTO_TEST_CASE(test_enable_this_ptr) { { shared_ptr<EnableThisPtrTester> ptr1; shared_ptr<EnableThisPtrTester> ptr2(new EnableThisPtrTester(ptr1)); BOOST_CHECK(ptr1 == ptr2); BOOST_CHECK(ptr1.use_count() == ptr2.use_count()); BOOST_CHECK(ptr1->shared_from_this() == ptr1); BOOST_CHECK(ptr1->shared_from_this().use_count() == ptr1.use_count()); shared_ptr<EnableThisPtrTester> ptr3 = ptr2->shared_from_this(); BOOST_CHECK(ptr2 == ptr3); BOOST_CHECK(ptr2.use_count() == ptr3.use_count()); BOOST_CHECK(ptr1->shared_from_this().use_count() == ptr1.use_count()); } { shared_ptr<EnableThisPtrTester> ptr1; EnableThisPtrTester tester(ptr1); shared_ptr<EnableThisPtrTester> ptr2 = tester.shared_from_this(); BOOST_CHECK(ptr1 == ptr2); BOOST_CHECK(ptr1.use_count() == ptr2.use_count()); ptr1.reset(); ptr2.reset(); } { EnableThisPtrTester tester; { shared_ptr<EnableThisPtrTester> ptr1 = tester.shared_from_this(); shared_ptr<EnableThisPtrTester> ptr2 = tester.shared_from_this(); BOOST_CHECK(ptr1 == ptr2); BOOST_CHECK(ptr1.use_count() == ptr2.use_count()); shared_ptr<EnableThisPtrTester> ptr3(&tester, null_deleter()); BOOST_CHECK(ptr1 == ptr3); BOOST_CHECK(ptr1.use_count() == ptr3.use_count()); shared_ptr<EnableThisPtrTester> ptr4 = tester.shared_from_this(); BOOST_CHECK(ptr4 == ptr1); BOOST_CHECK(ptr4 == ptr3); BOOST_CHECK(ptr1.use_count() == ptr4.use_count()); BOOST_CHECK(ptr3.use_count() == ptr4.use_count()); } BOOST_CHECK(tester.shared_from_this()); } }

7 22

[SoC] C++0x Project Ideas
by Andrew Sutton 09 Mar '10

09 Mar '10

Previous years' SoC project ideas suggested porting some or all of a library to C++0x. I wanted to get a read on whether or not Boost developers think that there is value in these kinds of projects. I think there are some interesting pros and cons. One aspect of these projects that worries me about these kinds of projects is that they can force programmers to work in the netherworld between two major versions of the language. They may end up porting the libraries to a CPP abstraction layer rather than actually writing C++0x, which may artificially constrain the ported implementations. I would personally see students write native C++0x than trying to write something in between. Maybe not "porting" as much as "migrating". The obvious downside is that native C++0x ports may not be easily integrated into Boost. Thoughts? Andrew Sutton andrew.n.sutton(a)gmail.com

2 2

[la] [static size matrix/vector linear algebra library] More feedback
by Agustín K-ballo Bergé 09 Mar '10

09 Mar '10

A few more things I've noticed while using Boost.LA · boost/la/all.hpp conflicts with boost/assign/list_of.hpp if Boost.Assign is included first. I think this has to do with missing includes in a few headers. · Expressions like rotx_matrix() * roty_matrix() don't work. The temporaries have to be stored in proper matrix variables first. Apparently its result type does not model a valid matrix? (just guessing). · Could we have translation_matrix and scale_matrix, just as we have rot*_matrix ? · There is no (vector) normalize function. The implementation is straightforward. · During RangeEx review, the use of views and algorithms was widely discussed. It would be good for Boost.LA to follow the same conventions decided back then. IIRC, `m | transposed` was a lazy view and `transpose(m)` returned a new (eagerly) modified value. I should go back to the archives to confirm this was indeed the conclusion. · I would like to have X, Y, Z and W placeholders be convertible to the axis versor. However I don't think this can be actually implemented. Maybe something like versor<float,3>( X ) or unit_vector<float,3>( X ) would be better. Agustín K-ballo Bergé.- http://talesofcpp.blogspot.com

2 3

[program_options] validation_error in 1.42
by Alexander Fokin 09 Mar '10

09 Mar '10

It seems the way program_options deals with validation errors was changed in 1.42. Constructor of validation_error now takes kind_t and option name and value. Before 1.42 it was possible to specify what exactly was wrong with the option value in the constructor of validation_error. Now I see no options but to subclass validation_error. Was this change intentional? Also, documentation need to be fixed to reflect these changes. More precisely, the following line in "Custom Validators" section will lead to compilation error: > throw validation_error("invalid value"); -- Best regards, Alexander Fokin, ru.elric(a)gmail.com.

3 2

[utility/swap] MSVC 10 test failure, unsigned long to std::bitset conversion invalid?
by Niels Dekker - address until 2010-10-10 09 Mar '10

09 Mar '10

There's a regression failure of Microsoft Visual C++ 10 on a unit test of the boost::swap utility: > > ..\libs\utility\swap\test\std_bitset.cpp(20) : error C2440: > 'initializing' : cannot convert from 'unsigned long' to > 'std::bitset<_Bits>' > No constructor could take the source type, or constructor > overload resolution was ambiguous > > ..\libs\utility\swap\test\std_bitset.cpp(21) : error C2440 See http://www.boost.org/development/tests/trunk/developer/output/RWVC10-boost-… Do I understand correctly that MSVC 10 does not support implicit conversion from unsigned long to std::bitset<N>? The program "std_bitset.cpp" is at http://svn.boost.org/svn/boost/trunk/libs/utility/swap/test/std_bitset.cpp It does: #include <bitset> int test_main(int, char*[]) { typedef std::bitset<8> bitset_type; const bitset_type initial_value1 = 1ul; // Line 20. const bitset_type initial_value2 = 2ul; // Line 21. // [...] return 0; } Can anyone here reproduce the compile error? If so, would it be helpful to replace line 20 and 21 by using parentheses? As follows: const bitset_type initial_value1(1ul); const bitset_type initial_value2(2ul); Kind regards, Niels -- Niels Dekker http://www.xs4all.nl/~nd/dekkerware Scientific programmer at LKEB, Leiden University Medical Center

6 22