June 2010 - Boost - lists.boost.org

Boost Bug Sprint #3 starts tomorrow!
by Marshall Clow 04 Jun '10

04 Jun '10

The bug sprint will run from tomorrow June 5th until Sunday, June 13th. As of 11:00 AM PST today, there are currently have 992 open tickets. The goal is to classify and fix bugs, and to close Trac tickets. For those just joining in, the tickets live at https://svn.boost.org The instructions (mostly repeated here) for the first bug sprint are at https://svn.boost.org/trac/boost/wiki/BugSprintJune2009 As the bug sprint progresses, I will be posting updates to the list and to https://svn.boost.org/trac/boost/wiki/BugSprintStatusJune2010 What can you do? You can fix bugs • If you are a library maintainer, you can commit your fixes. • If you are not a library maintainer, you can fix a problem on your local machine (and test it!!), and then attach your fix as a patch to the Trac ticket for the library maintainer to commit. If you do this, please provide a test case that exercises the problem; i.e, one that fails w/o your patch, and succeeds afterwards. You can characterize bugs • You can attempt to replicate the bug on your system(s), and attach information that you discover to the Trac ticket. This will make it easier for other people to solve the problem, even if you cannot. • You can write test cases demonstrating the problem, and attach them to the Trac ticket. • You can determine if the bug still exists; sometimes they get fixed, and the ticket never gets closed. In this case, try to identify a checkin that addresses the bug; it's always suspicious when bugs go away "by accident." You can test patches • Some of the tickets in the Trac system contain patches - some are quite old. You can install these patches on your system, and determine if they (a) build, and (b) work. If you do this, please provide detail. Don't just say "works for me" - say "I installed this over revision XXX on system YYY with compiler ZZZ. The patch installed and compiled successfully, and passed all the tests." • You can write test cases for the patches, and attach them to the ticket. You can help implement new features • There are a whole set of "feature requests" in the Trac system. If you have an idea about one of these, you can add comments to the Trac system. You can attempt to implement these new features, and attach the patch to the ticket. (Don't forget the test cases!!). There are several Trac reports that I find helpful for looking at the bugs: Open ticket count by owner: https://svn.boost.org/trac/boost/report/18 Open ticket count by component: https://svn.boost.org/trac/boost/report/19 Open ticket count by type https://svn.boost.org/trac/boost/report/20 (Overwhelmingly, these are 'bugs') Open ticket count by milestone: https://svn.boost.org/trac/boost/report/21 and, of course, the main report at https://svn.boost.org/trac/boost/report/1 Some things I see while looking at these reports: * There are 82 bugs with a milestone of "Boost 1.36.0", which was released 22 months ago. * There are 24 tickets with no owner, of which 15 are 'bugs'. * There are 63 tickets with no milestone attached; we have the "to be determined" milestone for cases where you're not sure when the fix will go in. -- Marshall

1 0

[system] error_code.hpp - questionable includes
by Christian Holmquist 04 Jun '10

04 Jun '10

Hi, I noticed that system/error_code.hpp caused some unexpected increase in compilation time, and looked trough its includes. The following seems not needed: #include <boost/cstdint.hpp> #include <boost/assert.hpp> #include <boost/operators.hpp> #include <boost/noncopyable.hpp> // 1) #include <stdexcept> #include <functional> // 2) 1) noncopyable is used to tell that a class (error_category) with pure virtual functions cannot be copied. This is implicit in the language, so really not needed. Unless there's a compelling reason to make sure derived classes can't be copyable either, but I didn't see any reason for this? I didn't look very close though, could've missed it. 2) inclusion of <functional> seems only needed to have the following: bool operator<( const error_category & rhs ) const { return std::less<const error_category*>()( this, &rhs ); } I can't guess the reason for using std::less instead of simply writing '<', but surely it can be expressed without std::less, no? And before getting the common Booster's answer when asking to remove #includes: Yes, I am aware of precompiled headers. I use them, too. =) Cheers, Christian P.S. Would it be too much to ask for having a separate header for the error_code's ostream operators?

2 2

[test] patch for test_fp_comparisons.cpp
by Jürgen Hunold 04 Jun '10

04 Jun '10

Hi ! According to http://www.boost.org/development/tests/trunk/developer/test.html nearly all compilers fail compiling test_fp_comparisons.cpp. With gcc-4.4 I get: test_fp_comparisons.cpp: In member function ‘void test_close_at_tolerance::test_method()’: test_fp_comparisons.cpp:165: error: reference to ‘fpc’ is ambiguous test_fp_comparisons.cpp:157: error: candidates are: namespace fpc = boost::math::boost::math::fpc; /home/hunold/src/devel/boost/boost/test/floating_point_comparison.hpp:280: error: namespace boost::test_tools::fpc = boost::math::boost::math::fpc; The attached patch removes the offending namespace alias in the test file. Okay to commit ? 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 * juergen.hunold(a)ivembh.de ! www.ivembh.de * * Geschäftsführer: ! Sitz des Unternehmens: Hannover * Prof. Dr.-Ing. Thomas Siefer ! Amtsgericht Hannover, HRB 56965 * PD Dr.-Ing. Alfons Radtke !

1 0

[test] patch to enable gcc visibility support
by Jürgen Hunold 04 Jun '10

04 Jun '10

Hi ! I've attached a patch which uses the new Boost.Config logic introduced in revision 62140 to enable gcc visibility support. This fixes #2114 for Boost.Test. It is based on the already working patches to Boost.System and testet on gcc-4.4, 4.5 and msvc-9.0 and 10. Okay to commit ? 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 * juergen.hunold(a)ivembh.de ! www.ivembh.de * * Geschäftsführer: ! Sitz des Unternehmens: Hannover * Prof. Dr.-Ing. Thomas Siefer ! Amtsgericht Hannover, HRB 56965 * PD Dr.-Ing. Alfons Radtke !

2 2

Re: [boost] [endian] swap_in_place use case
by Dave Handley 04 Jun '10

04 Jun '10

Vicente Botet wrote: > I'm looking for a use case where the use of swap_in_place > (or whatever is renamed) is not followed/preceded by a copy. I'm not sure you got an answer to this question. Here is a simple use case. Memory map a network endian file. Swap_in_place. Use. You definitely don't want a copy in this case since your file could easily be very big. Think of the case where your file is huge (say 10Gb), you really don't want to perform a copy and swap since that puts your memory need at 20Gb instead of 10Gb. Dave Handley

2 1

Re: [boost] Review of a safer memory management approach for C++?
by Bartlett, Roscoe A 04 Jun '10

04 Jun '10

Ingo, Mathias, and David, Sorry I missed your responses. It was not sent to me personally and I am only signed up for boost summaries. Is there some forum where I can present the approach described in: http://www.cs.sandia.gov/~rabartl/TeuchosMemoryManagementSAND.pdf and have an opportunity to discuss the various issues with interested parties and leaders in the C++ community? I am not sure the discussions on this mail list have adequately addressed the issues. My responses are below: > 6. Re: Review of a safer memory management approach for C++? > (Ingo Loehken) > 8. Re: Review of a safer memory management approach for C++? > (Mathias Gaunard) > 10. Re: Review of a safer memory management approach for C++? > (David Abrahams) > Message: 6 > Date: Thu, 27 May 2010 20:02:45 +0200 > From: Ingo Loehken <Ingo.Loehken(a)boc-eu.com> > To: boost(a)lists.boost.org > Subject: Re: [boost] Review of a safer memory management approach for > C++? > Message-ID: > <OF6B67C15A.1605A772-ONC1257730.00627F93-C1257730.00631B78@boc- > eu.com> > Content-Type: text/plain; charset="US-ASCII" > > if I understand "hard to reason about" in the right why : like there is > no > need for shared ownership at all, > this also means that there is no use for COM Programming - and of > course > there is. Raw resp. opaque > pointers have one huge advantage in productive environments : They work > as > perfect isolators, removing > any compile time dependencies. And from my point of view, compile time > is > what matters most, if you go > productive, otherwise you end up waiting for recompiles. Ingo, These are exactly the right points to be made. Many complex programs are going to involve sharing objects. We see this in many programming environments. Trying to "design" our way out of the sharing problem entirely will create more problems that it tries to solve. We need to separate the issues of sharing. One set of issues relates to change prorogation that will happen in any programming language (e.g. if objects A and B share object C and if A changes C what happens to B?). This is where we should be focusing our design attention. The other issue is silly memory management problems in C++ that other more modern languages like C#, Python, and Java don't suffer from so much. Objects stay around as long as they are needed. The goal of the approach described in: http://www.cs.sandia.gov/~rabartl/TeuchosMemoryManagementSAND.pdf is to as much as possible make the presence of sharing explicit so that we highlight the first type of "essential complexity" in programs but to minimize as much as possible the "accidental complexity" in trying to figure out when we need to actually delete an object and who's responsibility it is to delete the object. This is a very important issues and is discussed some in Section 6.1 in: http://www.cs.sandia.gov/~rabartl/TeuchosMemoryManagementSAND.pdf Cheers, - Ross > From: Mathias Gaunard <mathias.gaunard(a)ens-lyon.org> > To: boost(a)lists.boost.org > Date: 27.05.2010 14:59 > Subject: Re: [boost] Review of a safer memory management > approach > for C++? > Sent by: boost-bounces(a)lists.boost.org > > > Bartlett, Roscoe A wrote: > > Hello Boost developers, > > > > I am interested in finding one or more individuals who are > knowledgeable > about memory management in C++ (and especially of the reference- > counting > approach taken by boost::shared_ptr and boost::weak_ptr) to review an > idea > for a comprehensive approach to safer memory management in C++ that > encapsulates all raw C++ pointers in high-level code. > > Never use owning naked pointers and only use RAII (as is required for > exception-safe programming anyway) with exclusive ownership and no > aliasing, and you have no problems. [Bartlett, Roscoe A] Mathias, I agree but using raw pointers in any ubiquitous way is a problem. You can't detect dangling references and there are all of the other loosely typed problems described in Sections 2.1 and 2.2 in: http://www.cs.sandia.gov/~rabartl/TeuchosMemoryManagementSAND.pdf The issue is that it is easy to make mistakes with raw pointers related to ownership issues and if you use raw pointers, it is very difficult to detect them, even for tools like Valgrind and Purify. If no-one made mistakes, then we would all do well just to use void* and program in C. I want to eliminate undefined behavior in C++ programs in such a way that a properly configured static analysis tool could help to enforce. I believe that the approach described in http://www.cs.sandia.gov/~rabartl/TeuchosMemoryManagementSAND.pdf could be used with some static analysis tool to largely eliminate undefined behavior related to the usage of memory. There are lots of other areas of undefined behavior in C++ that this approach can't address (like bad type conversions of built-in types) but there are other idioms for addressing that. > Usage of shared_ptr should be an exception, not a widely deployed > solution to memory management issues. > Shared ownership is hard to reason about, and even if you use a similar > cycle-aware solution, cycles remain a real problem (they prevent > deterministic ordered destruction of objects, meaning they're only > applicable to certain classes of objects). [Bartlett, Roscoe A] No, if you share an object, you use a shared_ptr (or Teuchos::RCP), period. If sharing is the exception, then fine. Otherwise, don't play games with "I need shared_ptr here but I don't need it there because X, Y, and Z." We are never going to be able to produce programs that eliminate all sharing of objects, and we don't want to. Some types of programs are actually much simpler and more robust if you share some objects. For performance critical applications (e.g. the CSE domains I come from) you can't just willy nilly copy large objects and expect to achieve good performance. This is just not reality. > Message: 10 > Date: Thu, 27 May 2010 14:41:09 -0400 > From: David Abrahams <dave(a)boostpro.com> > To: boost(a)lists.boost.org > Subject: Re: [boost] Review of a safer memory management approach for > C++? > Message-ID: <m24ohtgpbu.wl%dave(a)boostpro.com> > Content-Type: text/plain; charset=US-ASCII > > At Thu, 27 May 2010 20:02:45 +0200, > Ingo Loehken wrote: > > > > if I understand "hard to reason about" in the right why : like there > > is no need for shared ownership at all, this also means that there > > is no use for COM Programming - and of course there is. > > I think you don't understand it the right way. Shared ownership (at > least in the presence of mutation) is hard to reason about because > seemingly-local modifications can have non-local effects. [Bartlett, Roscoe A] Yes, but let's focus on the "essential complexity" of object sharing and not get bogged down in the "accidental complexity" of memory management. The approaches described in http://www.cs.sandia.gov/~rabartl/TeuchosMemoryManagementSAND.pdf make explicit the "essential complexity" of object sharing while trying to eliminate the "accidental complexity" of memory management (see Section 6.1 in http://www.cs.sandia.gov/~rabartl/TeuchosMemoryManagementSAND.pdf) Trying to over design a program to avoid all shared ownership is what make C++ programming so unproductive and has all the negative consequences described in Section 1 in: http://www.cs.sandia.gov/~rabartl/TeuchosMemoryManagementSAND.pdf Designs with object sharing can be much less complex overall than designs with sharing. You just need decent tools to detect circular reference problems (and that is what the Teuchos::RCP class has). We have found that circular reference problems are fairly rare but when they occur they are a bear to track down. That is why I created all of the RCPNode tracing support in the Teuchos::RCP classes. Actually, we have found that non-deleted RCPNode objects are far more likely to occur due to other types of problems (e.g. calling abort(..), typical memory leaks, etc.) and in this role the RCPNode tracing machinery is a very cheap but effective version of memory checking that is automatically built into every debug-mode program and runs order of magnitude faster than tools like Valgrind and Purify. [Bartlett, Roscoe A] Cheers, - Ross Sorry again for not responding sooner.

3 2

Status of Boost.Atomic?
by Sean Chittenden 03 Jun '10

03 Jun '10

What's the status of Boost.Atomic? http://www.chaoticmind.net/~hcb/projects/boost.atomic/ This looks like some very interesting code that would be of interest to a number of boost users (besides, it would be nice to stop abusing boost/interprocess/detail/atomic.hpp). Thanks in advance for any light that can be shed on this. -sc -- Sean Chittenden sean(a)chittenden.org

1 0

Re: [boost] [msm] Passing constructor arguments to submachine
by Christophe Henry 03 Jun '10

03 Jun '10

>> I didn't think about Parameter and I like the idea (I also see >> somewhere else where it could be useful) but I : >> >> (a) don't have any parameter name to give to BOOST_PARAMETER_NAME >> (parameters being simply forwarded with BOOST_PP_ENUM_PARAMS) >> (b) don't know at preprocessor time in BOOST_PARAMETER_CONSTRUCTOR how >> many parameters the user will pass through the back-end to the >> front-end constructor or how many submachines/substates will be >> default-constructed by user's choice. >> >> Concretely, the user can now do something like: >> player p(/* for the front-end*/ 3, "a"); >> >> And adding states for copy-construction could look like: >> player p(/* for the front-end*/ 3, "a", >> /* some states copy-constructed*/ Paused("something") , >> Playing("more data") ); >> >> Of course I could provide some default names and create more >> constructor overloads with BOOST_PP_ENUM_PARAMS. >> >> I was actually thinking of using a proto expression like: >> player p( (/* data for front-end*/params_ << 3 << "a" ), >> (/* some states copy-constructed*/ states_ << >> Paused("something") << Playing("more data") )); >> >> But I admit having not spent enough thinking time yet so I will look >> into it again. >> >> Thanks for the idea, Dave. It will in any case be pretty cool to use >> Parameter to make back-end policies nicer. > > Please take a close look at Boost.Accumulator; it has to solve > essentially the same problem IIUC, and it does so quite nicely. You > can't use the high-level macros like BOOST_PARAMETER_CONSTRUCTOR in > the template that has to do the forwarding, though. I think it might > even improve readability to do make your life easy and accept a single > argument pack (backend_args in the example below) for forwarding to > submachines > > player p(/* for the front-end*/ 3, "a", > backend_args = ( > init1=Paused("something"), > init2=Playing("more data")) > ); > > or something like that. I like this syntax too. Ok then I will give it a try and have a closer look at Accumulator. Thanks!

1 0

Re: [boost] [boost::endian] Request for comments/interest
by Dave Handley 03 Jun '10

03 Jun '10

I wanted to throw a few things into the discussion: 1) Typed vs untyped. We have had various discussions about whether the network endian object should be a different type to the machine endian. I have a pretty strong opinion on this, and I think you should work with the same type. There are 2 core reasons for this: a. Performance when network endian is the same as machine endian - I'll discuss more on this later. b. When you are reading a complex packet of data off the network, a common use case would be to reinterpret_cast a block of data into a struct. When you are using different types for network and machine endian you end up having 2 structs - one to read the data off the network, and one to copy the data into. This could turn into a pretty severe maintenance burden. c. Given that you tend to convert to machine endian at the boundaries, you can treat the untyped interface in a very similar way to a boost::shared_ptr style interface. You call swap_in_place on the return value from the function that creates the initial struct - and therefore you never have access to the network endian version in anything except your most basic read function. As such, I think the type safety of network endian data is a bit of a red herring. It is no different from creating a raw pointer, then half a dozen lines of code later constructing a boost::shared_ptr from it. It is against the principle of the interface, and would create some evil bugs, but hasn't been formally prohibited by the interface. d. Finally, I would definitely want an endian interface that operated at a high level of abstraction - ie at the struct or container level, not at the built-in type level. 2) To copy or not to copy. I have a very big issue with any interface that enforces a copy. If I'm writing something to live on a memory limited embedded device, I absolutely want to be able to endian swap in place. Secondly, we should definitely not accept an interface that copies just on the grounds that the most common operation is from a big endian network to a little endian machine that does always require mutation. The platforms that boost runs on includes plenty of big-endian machine types; and I have come across numerous cases where (for performance reasons on a largely little endian machine environment) data has been left little-endian on the network. Having a do nothing (not even copy) case for when machine and network endianness match is very important. If you are reading a big stream of data from the network, not copying anything is a very important case, and key for writing high performance production code. 3) A final thought is that I am much more keen to use template arguments to decide on which endian swap to use than explicitly coding them in function template names. It makes endian swapping code in a big code base easier to spot, and makes the interface of the endian swapper itself more logical. When I change from big to little endian, I am tweaking a parameter of the endian swapper, not calling a wholly different function. I think from a design perspective, a template parameter makes most sense. Overall, I like Tom's interface, but I have been using it for quite a while (as a disclaimer). Dave

10 57

Mutexes claim a Windows event handle
by Peters, Richard 03 Jun '10

03 Jun '10

Hi! I have a problem with boost::recursive_mutex "sometimes" keeping a handle to a Windows Event. My application uses a lot of objects, each containing a recursive_mutex. The objects are accessed from different threads using a scoped_lock (see code below). In Boost 1.34 there was no problem, but after we switched to 1.39 it seems that the process collects more and more handles to Windows Events. Only when the objects that contain the recursive_mutex are destroyed, the handles are released again. The problem is that I must support 100,000 objects containg multiple mutexes, so if each mutex can cost one handle the total number of handles in use may become huge. I tried the latest Boost version (1.43) but that makes no difference. The strange thing is that not every object keeps a handle, i.e.: the number of handles collected is less than the number of objects created. When increasing the nrActions the number of handles collected comes closer to the number of objects. I could understand if a recursive_mutex costs a handle, except that in boost 1.34 they didn't so I wonder if this was an accident or a deliberate change. And most important: Is there a way to get the same behavior as in 1.34 where a mutex did not cost me one handle each? Thanks for your advice! Code example: #include <list> #include <boost/bind.hpp> #include <boost/thread.hpp> #include <boost/thread/recursive_mutex.hpp> #include <boost/enable_shared_from_this.hpp> class ActiveObject : public boost::enable_shared_from_this<ActiveObject> { private: boost::recursive_mutex mActionLock; void action() { boost::recursive_mutex::scoped_lock asyncLock(mActionLock); } public: void startAction() { boost::recursive_mutex::scoped_lock syncLock(mActionLock); boost::thread th(boost::bind(&ActiveObject::action, shared_from_this())); } }; int main() { { std::list< boost::shared_ptr<ActiveObject> > jobList; for (int nrObjects = 0; nrObjects < 1000; ++nrObjects) { boost::shared_ptr<ActiveObject> pActiveObject( new ActiveObject() ); jobList.push_back(pActiveObject); for (int nrActions = 0; nrActions < 3; ++nrActions) { pActiveObject->startAction(); } } // At this point, a lot of handles are in use. } // Here, the handles are released again. exit(0); } This message and attachment(s) are intended solely for use by the addressee and may contain information that is privileged, confidential or otherwise exempt from disclosure under applicable law. If you are not the intended recipient or agent thereof responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender immediately by telephone and with a 'reply' message. Thank you for your co-operation.

5 9