- Boost - lists.boost.org

[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

[range] strings
by Domagoj Saric 09 Mar '10

09 Mar '10

Currently, the following assertion: char const test_string[] = "a test string"; assert( test_string == boost::as_literal( test_string ) ); fails while the following one: assert( test_string == boost::as_literal( test_string ).advance_end( 1 ) ); passes because the left-hand side parameter of operator== is implicitly converted to a boost::iterator_range<> object which _includes_ the trailing zero (because it is treated as any other array) while the boost::iterator_range<> returned by boost::as_literal<>() _excludes_ the trailing zero... I 'know' that there is no 'happy' solution for this because the status quo is 'consistent' across all types but it, on the other hand, creates problems (or unexpected results), like the one outlined above, when strings, char pointers and literals are used...For this reason I would prefer more the other 'less than happy' solution that would treat strings in a special way (by never including the trailing zero)... Another problem is that the conversion, implict or otherwise, from a char container/range whose iterators are not plain char pointers (e.g. std::strings in 'secure STL' implementations) does not work (does not compile). My last post in the [program_options] thread offers a 'fix'. Yet another problem is that the as_literal<>() template function does not use the fact that it was passed an array to implicitly/directly deduce the length but it still calls std::strlen(). The make_range() function it calls for that: make_range( T* const r, bool ) { return iterator_range<T*>( r, r + length(r) ); } is also duplicated by: inline const char* str_end( const char* s, const char* ) { return s + strlen( s ); } ... Yes, some will object that the 'desired' direct deduction of length would be broken for 'typical' local buffers that are not completely filled (if there is no clear way of distinguishing them from literals): void foo() { char buf[ 256 ] = "a small string"; as_literal( buf ).size() == std::strlen( buf ); // in status quo as_literal( buf ).size() == _countof( buf ) - 1; // as proposed } but that could then also be said for the current implict conversion from such a "char buf[ 256 ]" into a boost::iterator_range<char const*>... I'd vote that this be handled with a runtime assertion that if a plain char array is passed it must be 'completely filled' (i.e. strlen( buf ) == _countof( buf ) ) otherwise the range must be explicitly constructed (iterator_range<char const *>( buf, buf + actual length )... Additionaly the above mentioned implementations of make_range() and str_end() add two extra instructions (substraction and addition) because they use strlen() that works with 'indexes'/size which then have to be converted to pointers... Additionaly#2 the boost::range_detail::is_char_ptr() function in as_literal.hpp is a runtime function when it seems it could be a metafunction... -- "What Huxley teaches is that in the age of advanced technology, spiritual devastation is more likely to come from an enemy with a smiling face than from one whose countenance exudes suspicion and hate." Neil Postman

2 4

Syntax colouring for Notepad++
by Paul A. Bristow 09 Mar '10

09 Mar '10

Does anyone have or know of a user defined language plugin for Notepad++ to provide syntax colouring for Quickbook and jamfiles (makefile is reasonable but not perfect)? (or suggestions for syntax colouring other text editors?) Thanks Paul --- Paul A. Bristow Prizet Farmhouse Kendal, UK LA8 8AB +44 1539 561830, mobile +44 7714330204 pbristow(a)hetp.u-net.com

4 3