- Boost - lists.boost.org

[statechart] gcc-patches
by Juergen Hunold 14 Mar '06

14 Mar '06

Hi Andreas ! I've tried to run the statechart examples and tests with gcc 4.0 using Boost.Build V2. The attached patch corrects some minor glitches: The examples don't run from the "run" directory because gcc's -rpath option is not used when using shared libraries. This is enabled by <hardcode-dll-paths>true The test Jamfile produces *tons* of warnings because -Wno--non-virtual-dtor is not set and detail/rtti_policy has an (empty) virtual function named "dummy" but no virtual destructor. I simply disabled this warning, but I'm not happy about it. It has been helpful in my own code in the past. Is there any chance to make the destructor virtual when a vtable is needed ? Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * hunold(a)ive-mbh.de ! www.ive-mbh.de

3 2

[test] gcc-warnings patch
by Juergen Hunold 14 Mar '06

14 Mar '06

Hi ! The attached patch fixes the following annoying gcc-Warnings: --- snip ------- boost/test/test_observer.hpp:38: warning: unused parameter 'test_cases_amount' /boost/test/test_observer.hpp:43: warning: unused parameter 'elapsed' boost/test/test_observer.hpp:47: warning: unused parameter 'passed' --- snap ------- And "boost/test/included/unit_test_framework.hpp" is missing a newline at EOF. I found those glitches because I compile with Boost.Build V2 which has -W -Wall as default for the gcc toolset. Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * hunold(a)ive-mbh.de ! www.ive-mbh.de

3 2

lambda and typeof, finally an effective in-place arithmetic metafunction generator.
by pongba 14 Mar '06

14 Mar '06

Okay, just image some sort of code like this: typedef mpl::vector_c<int,1,2,3> v; typedef mpl::accumulate<v,int_<0>,MPL_METAFUNC(_1*CONS(10)+_2)>::type::value result_value; // =123 Imaginably, the implementation of MPL_METAFUNC would involve BOOST_TYPEOF to deduce the type of "_1*CONS(10)+_2" so as to construct a corresponding metafunction, that is, "mpl::plus<_2,mpl::times<_1,int_<10> > >" (CONS here is used to work around the embarrassment that 10 becomes sort of variable when passed directly to operator*, so we use CONS(10) which expands into something like "int_<10>()" which entirely preserve "10" at compile-time). Arguably this is feasible, but I lack the time to implement it fully. (although it would be pretty simple, e.g. #define DEFINE_BINARY_OP(op,mpl_binray_op) \ template <typename T, typename U> \ mpl_binary_op<T,U> operator op (T t, U u) \ { \ return mpl_binary_op<T,U>(); \ } \ DEFINE_OP(+,mpl::plus) DEFINE_OP(-,mpl::minus) DEFINE_OP(*,mpl::times) DEFINE_OP(/,mpl::divide) ... Admittedly, there exists a name confliction between mpl::_1 and lambda::_1 due to the inherent difference between type and variable in the language, so we couldn't use the same _1 and _2 in both "plus<_1,_2>" and "_1+_2". Any good remedies for that?(of course we could always turn to "_1()+_2()" in which _1/2 means mpl::_1/2) My question is: Is this valuable?(IMO,it'll make arithmetic operation in metaprogramming much easier and clearer, just watch "_1*10+_2" v.s. "mpl::plus<_2,mpl::times<_1,int_<10> > >" you'll see that). And if it is, would Dave consider adding it to MPL? Thanks in advance! -- Regards!

1 0

[inspect] Bug report: Terminates with std::out_of_range exception
by Andreas Huber 13 Mar '06

13 Mar '06

Hi there When I run the inspect tool in boost/libs/statechart (current CVS) I always get a std::out_of_range exception: **** exception(205): std::out_of_range: basic_string::substr ******** errors detected; see standard output for details ******** I tried with vc-7_1 and mingw builds, both with the same result. Does this ring a bell or should I investigate further? Regards, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.

1 0

[boost.thread] ReadWrite Locks
by george 13 Mar '06

13 Mar '06

hello! until boost 1.33.0 there was in the lib(boost thread) the RW locks, now in 1.33.1 is off for deadlock reasons as I know... what about the next version of boost(1.33.2(??)),it would have it again? in the sandbox there is something... does somebody know when the next version will be ready?? I am working on a project and I wanna use RW locks,I dont want to use 1.33.0 RW locks not becouse I am afraid of deadlock,the use of them will be simple,but becouse I want to use the latest stable vesrion. thanks!

1 0

Performance TR project uploaded to Vault
by Pedro Lamarão 13 Mar '06

13 Mar '06

I've put together the five benchmarks from Appendix D of the Performance TR as a Boost.Build v2 project. The URL is: http://www.boost-consulting.com/vault/index.php?&direction=0&order=&directo… ("Performance TR" directory in the Vault.) * performance_tr.zip: Boost.Build v2 project with a batch runner for NT * msvc.zip: test results as output by run.bat for these versions: 6.0, 7.0, 7.1, 8.0express The project archive doesn't contain Boost.Build; just a Jamroot and five Jamfiles. You must set BOOST_BUILD_PATH and have bjam in your PATH. For information on how to configure Boost.Build v2 refer to this link: http://www.boost.org/doc/html/bbv2.html I'll soon post some results for some versions of g++. -- Pedro Lamarão Desenvolvimento Intersix Technologies S.A. SP: (55 11 3803-9300) RJ: (55 21 3852-3240) www.intersix.com.br Your Security is our Business

1 0

Adding numpy support to boost::python
by Neal Becker 13 Mar '06

13 Mar '06

Has anyone tried yet adding numpy support to boost::python? Is the only requirement to add "numpy" to load function, or are there more extensive API changes from numarray to numpy?

3 3

[hash] hash_float_test failure
by Vladimir Prus 13 Mar '06

13 Mar '06

Hello! The functional/hash/has_float_test test fails in CalebEpstein-V2 test results. I suspect that's some Sun-specific floating point accuracy issue. Caleb, can you check if that test works with V1? If so, can you get command lines for both V1 and V2 via: 1. Going to libs/functional/hast/test 2. Running "bjam -a -n -sTOOLS=gcc-3-4-3" and then "bjam -n -a --v2 gcc-3.4.3" and then send the command lines to me. If the test fails with V1, then maybe we need some Sun expert to tell the right command line option. Thanks, Volodya

3 3

[shared_array] Initialisation - could this subtle user bug be avoided?
by Paul Giaccone 13 Mar '06

13 Mar '06

I had some code in my program that created and initialised a shared_array. When the shared_array was deleted, the program crashed with an exception that suggested I had written beyond the end of the array. I realised that the problem was I had written: boost::shared_array<double> foo(new double(num)); instead of: boost::shared_array<double> foo(new double[num]); (For those without sharp eyes, that's parentheses instead of square brackets.) The compiler was perfectly happy with this, of course, because new double(num) is perfectly good syntax. Is there any way that this bug could be caught at compile time? Perhaps the solution might be to provide a separate constructor (a convenience function) that took only a "size" parameter and did the "new" for you: boost::shared_array<double> foo(num); Paul

1 0

[type_traits]: is_movable
by Vaclav Vesely 13 Mar '06

13 Mar '06

This is a duplicate. I sent this to the wrong thread by mistake. I'm sorry. Hi, draft of the is_movable trait is attached. Notes: - Implicit implementation is based on the has_trivial_copy trait. - For STL configurations, which defines BOOST_HAS_MOVABLE_STL, is_movable.hpp declares STL containers (and their const versions) as movable. Partial template specialization is required (!defined(BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION)). Open issues: - I'm not sure with volatiles. has_trivial_copy declares volatile types explicitly as not has_trivial_copy. I don't know why but is_movable should probably follow this. - I have tested with MSVC (6, 7.1 and 8) and GCC (3.2.3 - MinGW) compilers. MSVC is fine but GCC complains with specializations for STL types. It seems to be related to a different macro expansion strategy of preprocessor. I'm not able to use BOOST_PP_COMMA macro correctly. I will appreciate any help. Regards, Vaclav

1 0