- Boost - lists.boost.org

[dynamic_bitset] proposed fix for ticket #2842
by Juan Antonio Zaratiegui Vallecillo, a.k.a. Zara 11 May '09

11 May '09

Dear all, I have suffered the effects described on ticket #2842: "dynamic_bitset.hpp fails to compile with g++ (Ubuntu 4.3.3-5ubuntu2) 4.3.3" after upgrading from Ubuntu 8.10 to 9.04. After some testing, I have found a possible fix, but I would like to know how may I test thoroughly over as many compiler/versions as possible before I may suggest its inclusion in trunk. Fix data: -- tested under gcc versión 4.3.3 (Ubuntu 4.3.3-5ubuntu4) -- tested under gcc versión 4.1.2 20080704 (Red Hat 4.1.2-44) -- Patch data: <PATCH> Index: boost/dynamic_bitset/dynamic_bitset.hpp =================================================================== --- boost/dynamic_bitset/dynamic_bitset.hpp (revision 52752) +++ boost/dynamic_bitset/dynamic_bitset.hpp (working copy) @@ -999,11 +999,17 @@ using detail::dynamic_bitset_impl::access_by_blocks; using detail::dynamic_bitset_impl::value_to_type; +#if BOOST_WORKAROUND(__GNUC__, == 4) && (__GNUC_MINOR__ >= 3) + // NOTE: Explicitly qualificationf of "bits_per_block" + // breaks compilation on gcc 4.3.3 + const bool no_padding = bits_per_block == CHAR_BIT * sizeof(Block); +#else // NOTE: Explicitly qualifying "bits_per_block" to workaround // regressions of gcc 3.4.x const bool no_padding = dynamic_bitset<Block, Allocator>::bits_per_block == CHAR_BIT * sizeof(Block); +#endif const bool enough_table_width = table_width >= CHAR_BIT; </PATCH> TIA Zara

2 2

[scope_exit] Boost.ScopeExit capturing 'this'
by adam.butcher＠selex-comms.com 11 May '09

11 May '09

I wasn't sure whether I had the correct address for Boost.ScopeExit's author Alexander Nasonov, so I've submitted to this list just in case and to get feedback from other users. I have been playing with BOOST_SCOPE_EXIT -- it it very convenient. One thing I would have liked would be to capture 'this' inside member functions. I have created a patch which adds BOOST_SCOPE_EXIT_THIS to do just that. It provides an operator->() in the generated struct which can be used to access the enclosing class's members. The syntax is: BOOST_SCOPE_EXIT_THIS( (&a) (&b) ) { a; b; // local captures (*this)->member; // member access } BOOST_SCOPE_EXIT_END; and can be BOOST_SCOPE_EXIT_THIS() { (*this)->member; } BOOST_SCOPE_EXIT_END; providing the preprocessor allows for empty parameter lists (which gcc does and vc does albeit after disabling a warning to remove noise). The type pointed to by the result of operator->() is correctly cv qualified. It has been tested on gcc 4.3, gcc 4.2, msvc 7.1 and msvc 9.0. I don't have access to other compilers. Boost.Typeof worked fine on gcc for typeof(this) -- mostly because gcc has a native typeof I guess. On visual studio (vc71 and vc90) it was not so good -- a compiler bug ( http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?Feedba… , http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?Feedba… ) that has been marked as 'Won't fix' means that 'this' cannot be used in expressions within template argument lists -- even if those expressions are innocuous typeid()s or sizeof()s for type-inference. The common workaround (capturing a compile-time integer with an enumerator and using the enumerator in the template parameter list) doesn't work with the vc71-specific implementation of Boost.Typeof since it is based on typeid() -- this cannot be captured in a compile-time expression (or I know of no way to that doesn't involve the expression existing in a template argument list). All is not lost though -- the general-purpose sizeof() based approach for the other VC versions works fine for VC71 for determining the typeof 'this'. As such my patch includes a VC>=1300 specific workaround for typeof 'this' determination. This is unfortunate but I couldn't think of any other non-intrusive way of doing it. Please find the attached patch and let me know what you think -- I'm sure this feature would be useful to users -- it saves having to do: TypeOfMyClassWhichCouldBeTedious* self = this BOOST_SCOPE_EXIT( (&self) ) { self->member; } BOOST_SCOPE_EXIT_END; which removes the convenience of BOOST_SCOPE_EXIT in these contexts since something like: struct at_end { TypeOfMyClassWhichCouldBeTedious* self; ~at_end() { self->member; } } at_end = {this}; can be done without any dependencies to achieve the same result. Regards, Adam. ------------------------------------------------------------ This email and any attached files contains company confidential information which may be legally privileged. It is intended only for the person(s) or entity to which it is addressed and solely for the purposes set forth therein. If you are not the intended recipient or have received this email in error please notify the sender by return, delete it from your system and destroy any local copies. It is strictly forbidden to use the information in this email including any attachment or part thereof including copying, disclosing, distributing, amending or using for any other purpose. In addition the sender excludes all liabilities (whether tortious or common law) for damage or breach arising or related to this email including but not limited to viruses and libel. SELEX Communications Limited is a Private Limited Company registered in England and Wales under Company Number 964533 and whose Registered Office is Lambda House, Christopher Martin Rd, Basildon, SS14 3EL. England.

4 8

[1.40.0] Release branch open
by Beman Dawes 11 May '09

11 May '09

The release branch (https://svn.boost.org/svn/boost/branches/release) is open for merging all stable changes from trunk, including bug fixes and major upgrades to existing libraries. Breaking changes should be coordinated via the mailing list with the developers of the other libraries affected. New libraries may be added, but require permission of a release manager. In other words, except for new libraries, merging changes *does not* need permission from a release manager. I.e. just do it! The release schedule: * June 15, 2009: branches/release closed for new libraries and breaking changes to existing libraries. Still open for bug fixes and other routine changes to all libraries. * June 22, 2009: Release managers start QA checks. * July 6, 2009: branches/release closed for major code changes. Still open for serious problem fixes and docs changes. * July 13, 2009: branches/release closed for all library changes except when specific permission given by release manager(s). * July 20, 2009: Beta release target date. Further betas and/or release candidates as feedback dictates. * August 1, 2009: Release ship date. Links relating to this release: * Google Calendar with the release schedule: <http://www.boost.org/development/index.html>. * Release schedule explanation: <http://svn.boost.org/trac/boost/wiki/ReleaseSchedule>. * Release practices for developers: <http://svn.boost.org/trac/boost/wiki/ImprovingPractices>. --The release management team

1 0

[signals2] Compile errors when using signals2
by Carlos Rafael Giani 11 May '09

11 May '09

Hi, I had some compiling errors when I wanted to try out signals2. In predestructible.hpp line 33 there is an extra semicolon (the empty {} scope has a an extra ;). Also, in tracked_objects_visitor.hpp line 85, the "trackable" parameter is unused, which causes a warning. The warning is not critical, but the error is. It basically forces one to either manually fix the predestructible.hpp header, or to stop using the -pedantic flag. My flags: -Wextra -Wall -std=c++98 -pedantic

2 1

Boost Asio in Windows
by Kenny Stone 10 May '09

10 May '09

I'm trying to use asio in linux and windows, and I have to use a very specific way of starting my IO Service to get it to work in windows xp: void start() { tcp::endpoint endpoint = *iterator_; socket_.async_connect(endpoint, boost::bind(&MessageHandler::handle_connect, this, boost::asio::placeholders::error, ++iterator_ ) ); boost::thread t( boost::bind( &boost::asio::io_service::run, &(socket_.get_io_service() ))); t.detach(); //threadPool_.schedule(boost::bind( &boost::asio::io_service::run, &(socket_.get_io_service()) ) ); } The commented out line is what I wanted to use (threadpool), as thread detach is far from an ideal situation. To work in windows, I have to call io_service.run() in this function and thread detach; it doesn't seem to work any other way. Everything pretty much works in linux. Is there a pattern that I should be using here for cross platform usage of the library? Any ideas why the threadpool solution doesn't work in windows? ( http://threadpool.sourceforge.net/) Thanks, -- Kenny Stone Connamara Systems, LLC

2 1

Re: [boost] [test] Automatic registration of tests created with BOOST_PARAM_TEST_CASE
by Jan Stolarek 10 May '09

10 May '09

> Boost.Test do not support this setup out of the box It seems to me that there's no unit testing framework for C++ that would support that (please correct me if I'm wrong). > Which particular part? For example this : "Sub test case names are deduced from the macro argument test_case_name. If you prefer to assign different test case names, you need to use the underlying make_test_case interface instead." More details on that would be nice. It would also be great to add more complex examples. Examples for each section are clear, however problems arise when one tries to combine concepts from many sections. > This is not a good idea. I found it in documentation for Boost 1.34 : http://www.boost.org/doc/libs/1_34_1/libs/test/doc/tests/parameterized_test… > Your best shot probably is to try ot do this in global fixture. Would this be a good solution if I had many tests with lots of data sets? > You can implement your own generator. Could you point me to example on how to do that? >Also you probably should register your test units directly under >framework::master_test_suite() As mentioned in my fisrt mail I have tried that but with no result. It seems that I got something wrong with what I can add to master test suite. Jan

2 1

Re: [boost] [test] Automatic registration of tests created with BOOST_PARAM_TEST_CASE
by Jan Stolarek 10 May '09

10 May '09

Ok, I figured out a solution that seems to be quite elegant, not so verbose and easy to achieve : using namespace boost::unit_test; class DataSet { public : DataSet( /* params */ ) { /* setup single data set */ } ~DataSet( ) { /* teardown single data set */ } /* some fields */ } void testMethod( DataSet* data ) { /* do something with method that's being tested. Use data somehow */ BOOST_CHECK( /* assertion */ ); } BOOST_AUTO_TEST_CASE( TestNameFirstDataSet ) { DataSet dataSet( /* params for first data set */ ); testMethod( dataSet ); } BOOST_AUTO_TEST_CASE( TestNameSecondDataSet ) { DataSet dataSet( /* params for second data set */ ); testMethod( dataSet ); } It's so simple that I wonder why didn't I figure it out right away. It doesn't require extra lines of code (dataSet has to be created somewhere anyway), it even allows to get rid of DataProvider class. Also there is no problem of spliting the tests into many files (I think this could be problematic if I had used global fixture, since all the data sets would have to be defined in one file). Any bad sides of this approach? Jan

1 0

[iostreams] regression - Missing include guard in boost/iostreams/device/mapped_file.hpp
by Bjørn Roald 10 May '09

10 May '09

Hi, Seems like the trunk@46692 commit, 25 june 2008, removed the include guard in boost/iostreams/device/mapped_file.hpp This breaks gcc43 compilation of sources directly including this header. Eg. http://www.mapnik.org/ trunk code. -- Bjørn

2 4

[Review Request] Boost.Convert
by Vladimir Batov 08 May '09

08 May '09

The proposed Boost.Convert has seen some lively discussions and considerable changes. Since then its interface and major implementation details have been unchanged and are being used/tested in an actual development of a system of a moderate size. Therefore, I would like to request a formal review and the component placed into the review queue. The zipped source and documentation are in the Vault: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=boost-… Thanks, Vladimir.

1 0

[utility][foreach][1.39.0] warning C4512
by Michael Mathews 08 May '09

08 May '09

HI folks, Just upgraded to 1.39.0 and everything works well except I started getting these warnings. >C:\Boost\include\boost-1_39\boost/utility/addressof.hpp(30) : warning C4512: 'boost::detail::addr_impl_ref<T>' : assignment operator could not be generated 1> with 1> [ 1> T=std::vector<double> 1> ] 1> C:\Boost\include\boost-1_39\boost/utility/addressof.hpp(56) : see reference to class template instantiation 'boost::detail::addr_impl_ref<T>' being compiled 1> with 1> [ 1> T=std::vector<double> 1> ] 1> C:\Boost\include\boost-1_39\boost/foreach.hpp(627) : see reference to function template instantiation 'T *boost::addressof<T>(T &)' being compiled 1> with 1> [ 1> T=std::vector<double> 1> ] 1> .\main.cpp(102) : see reference to function template instantiation 'boost::foreach_detail_::auto_any<T> boost::foreach_detail_::contain<std::vector<_Ty>>(std::vector<_Ty> &,boost::mpl::false_ *)' being compiled 1> with 1> [ 1> T=std::vector<double> *, 1> _Ty=double 1> ] msvc9 sp1 warning level 4. I didn't get these warnings in 1.38 enjoy michael

2 1