- Boost - lists.boost.org

[Report] 6 regressions on RC_1_34_0 (2007-05-10)
by Douglas Gregor 10 May '07

10 May '07

Boost Regression test failures Report time: 2007-05-10T03:34:25Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-RC_1_34_0/developer/i… 6 failures in 1 libraries python (6) |python| bases: gcc-4.1.1_sunos_i86pc exec: gcc-4.1.1_sunos_i86pc exec-dynamic: gcc-4.1.1_sunos_i86pc pointee: gcc-4.1.1_sunos_i86pc pointer_type_id_test: gcc-4.1.1_sunos_i86pc upcast: gcc-4.1.1_sunos_i86pc

1 0

Re: [boost] [threads] singletons
by james.jones＠firstinvestors.com 10 May '07

10 May '07

From: Roman Morokutti <roman_vbg(a)web.de> > I don?t understand the DLCP-hype at all. Correct me if > I am wrong, but how would it be to just instantiate the > Singleton before spawning any thread? Sometimes that isn't an option. Suppose your Singleton encapsulates a heavyweight resource (say a database connection) which may be unnecessary, and the decision cannot be made until after threads are spawned. - James Jones Administrative Data Mgmt. Webmaster 375 Raritan Center Pkwy, Suite A Data Architect Edison, NJ 08837

1 0

[1.34.0] Release Candidate 2
by Thomas Witt 10 May '07

10 May '07

Hi, 1.34.0 release candidate 2 is now available from http://www.boost.org/ release/. It contains the following changes from RC1: - configure update from Doug Gregor - doc updates from John Maddock - read_write_mutex sources removed by Anthony Williams Please give it a try and report any problems to the developer list or directly to me. Unless it's broken in a major way it'll be released unchanged on Friday May 11. Thanks Thomas -- Thomas Witt witt(a)acm.org

4 4

[bind][tr1] patch for more compliant placeholders
by Daniel Walker 10 May '07

10 May '07

Hello, TR1 section 3.6.4 says that placeholders should be default and copy constructible. However, on gcc and borland boost::bind placeholders are not copy constructible. I tried the following C++0x test. #include <boost/tr1/functional.hpp> #include <boost/concept_check.hpp> int main() { boost::function_requires< boost::DefaultConstructible< typeof(std::tr1::placeholders::_1) > >(); boost::function_requires< boost::CopyConstructible< typeof(std::tr1::placeholders::_1) > >(); } This works on gcc 4.1 with GNU's TR1 implementation, but when using Boost.TR1 the second concept check fails to compile. On gcc and borland the placeholders are defined as inline functions. On all other compilers they are objects with internal linkage. From reading the cvs logs for placeholders.hpp, inline function placeholders are useful in order to avoid having data in headers. (Also, apparently gcc may require placeholders to be inline functions to workaround limitations in precompiled headers.) TR1 gets around the data-in-headers issue by specifying that the placeholder declarations in <functional> are extern. So, should Boost.Bind deviate from TR1 bind in terms of the linkage of placeholders or in terms of the set of valid, TR1-compliant programs it can support based on concept requirements? I don't like the idea of requiring Boost.Bind users to link to a library, so neither of these options are particularly attractive. As a compromise, why not allow the user to choose whether placeholders are internal objects or inline functions depending on their needs? The attached patch does this by introducing a macro BOOST_BIND_ENABLE_INLINE_PLACEHOLDERS. When it is defined placeholders are not objects with internal linkage, and their types do not meet the TR1 concept requirements; i.e. they're inline functions. When the macro is not defined placeholders are objects with internal linkage, and their types are both default and copy constructible. The macro is undefined by default. If a user needs inline placeholders for precompiled headers or whatever reason, they can make the trade off and define the macro. The patch also includes user documentation. The patch allows the code above to compile on gcc 4.1 with Boost.TR1, and there are no errors detected when I run the bind test suite under gcc 3.3/4.1 or msvc 7.1/8.0 with and without inline placeholders enabled. Apply with 'patch -p0 < djw_bind_placeholders.patch' from the boost root directory. I hope this is acceptable. Let me know if I'm over looking something. Thanks, Daniel Walker

5 44

boost python testing, doc errata
by Harri Pasanen 10 May '07

10 May '07

The http://www.boost.org/libs/python/doc/building.html states: """ To build and test Boost.Python, start from the libs/python/test directory and invoke bjam -sTOOLS=toolset test """ However, when doing that it complains notice: could not find main target test notice: assuming it's a name of file to create don't know how to make <e>test ...found 1 target... ...can't find 1 target... without the 'test' target it seems to work. -Harri Privileged or confidential information may be contained in this message. If you are not the addressee of this message please notify the sender by return and thereafter delete the message, and you may not use, copy, disclose or rely on the information contained in it. Internet e-mail may be susceptible to data corruption, interception and unauthorised amendment for which Wall Street Systems does not accept liability. Whilst we have taken reasonable precautions to ensure that this e-mail and any attachments have been swept for viruses, Wall Street Systems does not accept liability for any damage sustained as a result of viruses. Statements in this message or attachments that do not relate to the business of Wall Street Systems are neither given nor endorsed by the company or its Directors.

1 0

boost::test question
by Jorge Lodos 10 May '07

10 May '07

Hi The code below reports 2 failed assertions of 3. If you comment out one of the BOOST_CHECK macros, it reports 1 failed assertion of 1. Is the extra assertion expected behaviour? Thanks Jorge #include <boost/test/unit_test.hpp> using boost::unit_test::test_suite; void free_test_function() { // reports 'error in "free_test_function": test 2 == 1 failed' BOOST_CHECK(5 == 1); // non-critical test => continue after failure BOOST_CHECK(6 == 1); // non-critical test => continue after failure } test_suite* init_unit_test_suite( int, char* [] ) { test_suite* test= BOOST_TEST_SUITE( "Unit test example 1" ); // this example will pass cause we know ahead of time number of expected failures test->add( BOOST_TEST_CASE( &free_test_function ), 2 /* expected one error */ ); return test; }

3 2

Moving SourceForge tickets to Trac
by Douglas Gregor 10 May '07

10 May '07

We're planning to move all of the SourceForge bug reports, enhancement requests, and patches over to the Trac ticket system. Trac provides better integration with Subversion, making development significantly easier. It's also yet another step in moving away from SourceForge. We would like to move the SourceForge tickets over at 3pm EDT. We will start by disabling the SourceForge ticket system, exporting those tickets, and importing them into Trac. I'll send another announcement when the Trac is back online. If there are any objections to the timing of this move, please speak quickly :) - Doug

3 4

Bug in serialization/weak_ptr.hpp in Boost 1.34.0 RC2
by Mikko Vainio 10 May '07

10 May '07

Is it too late to get this fixed before 1.34.0 ships? /Mikko Mikko Vainio wrote: > Could someone fix line 31 in serialization/weak_ptr.hpp to say > const boost::shared_ptr<T> sp = t.lock(); > as it does in the HEAD version. > > The line is now > const boost::shared_ptr<T> sp(t); > which will cause assertion failure with empty weak_ptr. Being empty is a > perfectly valid state for a weak_ptr, and should be serializable. > > Cheers, > Mikko

1 0

[threads] singletons
by james.jones＠firstinvestors.com 10 May '07

10 May '07

Interesting Dr. Dobbs article this month about threadsafe singletons... http://www.ddj.com/dept/cpp/199203083?pgno=1 Boost.Threads is mentioned as having an inefficient solution to the problem of once-called routines in Windows. Is it possible that the technique describe in this article could replace this implementation? - James Jones Administrative Data Mgmt. Webmaster 375 Raritan Center Pkwy, Suite A Data Architect Edison, NJ 08837

3 2

[pool] future directions
by Michael Gopshtein 10 May '07

10 May '07

According to documentation to "Pool" library, it is intended to be used "when there is a lot of allocation and deallocation of small objects". In our product we also use such pool for allocation of "normal" - heavier objects. In such case we can't benefit from significant improvement in memory consumption per object (overhead of malloc's internal structure relative to used size of the object), but the allocations themselves are much more efficient. Additional advantage is memory fragmentation - all objects in the pool reside in continuous memory blocks. The main problem with such usage is, in our case, that the pool never "returns" memory to the system, unless it's released. For example, if I use the pool for allocation of Event objects, and at some point of time I had 10000 concurrent events, the pool will occupy all that memory while the process is alive, even if for most of the time I use a small portion of it. As a solution I was thinking about adding a "defragment" function to memory pool, which will compact it by moving live objects to free cells at the "beginning" of the pool. Such feature can be implemented with help of additional "index" table of pointers. Of cause, instead of returning pointer to allocated object, the pool will return a wrapper object, actually pointing to that index table (for which separate "classical" pool can be used). So, the first question is: do you think such feature will be helpful? If yes - please share your thoughts regarding suggested and/or other implementations? Michael

5 9