- Boost - lists.boost.org

[thread] Could mutex and condition_variable be movable?
by vicente.botet 04 May '08

04 May '08

Hi, I'm defining a class that is non copiable but movable. The class contains a boost::mutex and boost::condition_variable fields which are non copiable neither movable. I'd prefere not been forced to allocate all the class data in a pointer to make possible the move operation. Has a sens to make these classes movable? Thanks in advance --------------------------- Vicente Juan Botet Escriba

2 2

Re: [boost] throw_exception rev. 44954 -> g++ warnings
by Ralf W. Grosse-Kunstleve 04 May '08

04 May '08

Hi Emil, > I don't want to turn this into an argument; I only asked if there is > an official Boost policy on the subject. Is there a requirement that > boost compiles with -Wall without warnings on all compilers? I don't know if there is a formal policy, but I know a couple of years ago boost wasn't clean for compiling with -Wall. In the meantime, someone must have worked pretty hard to eliminate all the warnings. It would be nice if that investment could be preserved. When developing new code, -Wall catches many problems that would otherwise go undetected until much later, when it is usually much more effort to figure out what's wrong since the mind has moved on to other things. I see, in the meantime you've checked in destructors, but without the virtual keyword. Therefore the warnings didn't go away. Is this an oversight? I'm currently testing with the "virtual" added (below). This seems to eliminate all warnings. Ralf Index: boost/exception/detail/counted_base.hpp =================================================================== --- boost/exception/detail/counted_base.hpp (revision 45057) +++ boost/exception/detail/counted_base.hpp (working copy) @@ -34,6 +34,7 @@ protected: + virtual ~counted_base() throw() { } Index: boost/exception/detail/cloning_base.hpp =================================================================== --- boost/exception/detail/cloning_base.hpp (revision 45057) +++ boost/exception/detail/cloning_base.hpp (working copy) @@ -23,6 +23,7 @@ protected: + virtual ~cloning_base() throw() { }

9 12

sp_atomic_mt2_test: a test for mutex/shared_mutex/atomic access performance
by Peter Dimov 03 May '08

03 May '08

I've added sp_atomic_mt2_test.cpp: http://svn.boost.org/trac/boost/browser/trunk/libs/smart_ptr/test/sp_atomic… to the SVN; this is a reader/writer performance test that can be used to compare the performance of a detail::lightweight_mutex, boost::shared_mutex and the new atomic access operations for shared_ptr. It accepts command line options that can be used to achieve a variety of scenarios. I'm currently seeing a plain mutex (maps to a CRITICAL_SECTION) outperforming shared_mutex for the default configuration of read/write ratio 100:1, vector size (operation cost) 10000, no matter how many threads I use on a dual CPU box on Windows. This seems somewhat suspicious and may indicate a bug in the test. Any comments are welcome. :-)

1 0

Re: [boost] throw_exception rev. 44954 -> g++ warnings
by Ralf W. Grosse-Kunstleve 03 May '08

03 May '08

> Right, warning free code is a good idea. > > Nevertheless one should specify Boost include path via -isystem > path/to/boost and not via -I path/to/boost if one doesn't want to see > the warnings in system libraries with gcc. That's a bit like putting black tape over a "check-engine" light. My primary question still is: What is the disadvantage of adding the virtual destructors? The Stroustrup book has a very clear recommendation (below). Why not follow this advice? I'm keen to learn the facts. Ralf Stroustrup 2000 Section 12.4.2 (page 319 in my edition): Many classes require some form of cleanup for an object before it goes away. Since the abstract class lval_box cannot know if a derived class requires such cleanup, it must assume that it does require some. We ensure proper cleanup by defining a virtual destructor lval_box::~lval_box() in the base and overriding it suitably in derived classes. ... ... We have no way of knowing exactly to which class the object pointed to by p belongs, but thanks to lval_box's virtual destructor, proper cleanup as (optionally) defined by that class' destructor will be called.

7 9

Some bjam questions
by Peter Dimov 03 May '08

03 May '08

1. Why doesn't --build-type=complete work when invoked from a library build directory? I needed to build libboost_serialization-vc71-mt-sgd.lib yesterday and went through quite a few attempts to get the options right (from within the serialization build directory). I see now that it would've been easier to use --with-serialization from the top level, but why doesn't the "intuitive" way work as expected? 2. Why doesn't runtime-link=static work for a test? I'm getting: Skipping build of: libs/smart_ptr/test/shared_ptr_test <build>no in common properties when invoking for example C:\boost\trunk>bjam runtime-link=static libs/smart_ptr/test//shared_ptr_test

2 3

Geometry Template Library from Intel
by Simonson, Lucanus J 03 May '08

03 May '08

Some of you may remember discussion related to a potential submission of a computational geometry library from Intel last year. Interest in the library was expressed, and some interesting conversation about technical specifics of the library ensued. The most common feedback was "show us the code". At that time, I said that it would take several months to get approval to release the code outside of Intel. Eventually I decided to put the further discussion of my library in boost on hold until I could release the code to you. Now I have gotten approval to release the code to boost, licensed it under the boost license and uploaded it to the vault under Math Geometry. Please feel free to take a look and discuss the library on the list or directly with me. See the README file for some more specific information about the submission. I realize that there has been a recent submission of a GIS data processing library targeting cartography applications mostly, from Barend Gehrels. I agree with him that the overlap between his library and mine is minimal. He is using floating point arithmetic and works with arbitrary angle polygons. My library is integer based and works with polygons that are restricted to right angles and 45-degree angles. Since last year I have added support for resizing of sets of polygons that may have 45-degree edges. While there is some minimal numerical adjustments that need to be made to ensure integer coordinates on the output of such resize operations, that is still a far cry from what CGAL or a good GIS data crunching library is doing. The two capabilities are more complementary than competing. I expect that many changes to my library will be recommended (or required) by the boost community before it might be considered for acceptance into boost. Also, I recognize that some synthesis between multiple related geometry submissions (and ideas) is likely to take place. I'm fine with that. That is what I want to happen and I why I came to boost. Now that I am able to share the original source code with you it is possible for fruitful discussion in that vein to resume. Luke

9 33

Boost version bump?
by Peter Dimov 03 May '08

03 May '08

The trunk still has version 1.35.0 (as does the release branch). Shouldn't the trunk version be increased to 1.36.0 (and the release branch version to 1.35.1)? Wasn't this part of the release checklist?

1 0

Re: [boost] throw_exception rev. 44954 -> g++ warnings
by Ralf W. Grosse-Kunstleve 03 May '08

03 May '08

Thanks for the explanation! How about this? Index: counted_base.hpp =================================================================== --- counted_base.hpp (revision 45067) +++ counted_base.hpp (working copy) @@ -34,6 +34,10 @@ protected: +// avoid warning: has virtual functions but non-virtual destructor +#if defined(__GNUC__) + virtual +#endif ~counted_base() throw() { } Index: cloning_base.hpp =================================================================== --- cloning_base.hpp (revision 45067) +++ cloning_base.hpp (working copy) @@ -23,6 +23,10 @@ protected: +// avoid warning: has virtual functions but non-virtual destructor +#if defined(__GNUC__) + virtual +#endif ~cloning_base() throw() { } ----- Original Message ---- From: Peter Dimov <pdimov(a)pdimov.com> To: boost(a)lists.boost.org Sent: Saturday, May 3, 2008 7:08:06 AM Subject: Re: [boost] throw_exception rev. 44954 -> g++ warnings Ralf W. Grosse-Kunstleve: > My primary question still is: > What is the disadvantage of adding the virtual destructors? > The Stroustrup book has a very clear recommendation (below). > Why not follow this advice? I'm keen to learn the facts. A destructor that is never supposed to be called (except by the destructor of the derived class) doesn't need to be virtual. There's not much point in trying to avoid the undefined behavior in "delete sp.get()". sp is now a time bomb. A protected destructor, on the other hand, yields a compile-time error. You can still make it virtual if you like. It's a bit contradictory for the reader as you appear unable to make up your mind as to whether the destructor is supposed to be part of the base class interface or not, but most of them are familiar with g++ by now, so they won't be confused for long. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

2 1

[range_ex] proposal
by Neil Groves 03 May '08

03 May '08

Dear Reviewers, May I kindly request a review to be scheduled at your convenience for the Boost RangeEx library proposal. The code and documentation have been uploaded to the root of the vault ain the form of the range_ex.zip file: http://www.boost-consulting.com/vault/index.php?action=downloadfile&filenam… Thank you for your consideration. Best Wishes, Neil Groves

2 1

Re: [boost] throw_exception rev. 44954 -> g++ warnings
by Ralf W. Grosse-Kunstleve 03 May '08

03 May '08

I think it is OK to disregard the warning below. I just played around a bit trying to resolve the warning. I kept adding throw(), but eventually got compilation errors because apparently there are derived destructors that throw. Therefore I simply silenced the warning (which is easy with this compiler). ----- Original Message ---- From: Ralf W. Grosse-Kunstleve <rwgk(a)yahoo.com> To: boost(a)lists.boost.org Sent: Friday, May 2, 2008 10:40:31 PM Subject: Re: [boost] throw_exception rev. 44954 -> g++ warnings There is another warning, this time from a compiler based on EDG 245 (Tru64 cxx): cxx: Warning: /net/taipan/scratch1/rwgk/auto_build/sources/boost/boost/exception/enable_current_exception.hpp, line 57: #768-D exception specification for implicitly declared virtual function "boost::exception_detail::clone_impl<T>::~clone_impl" is incompatible with that of overridden function "boost::exception_detail::cloning_base::~cloning_base" clone_impl: --------^ Just a throw() missing somewhere? Ralf _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0