May 2008 - Boost - lists.boost.org

[random] Rician and Weibull distributions
by Matthias Schabel 05 May '08

05 May '08

If there's any interest, I've implemented these two distributions (attached). They have only been lightly tested at this point, but might be of interest to some users of Boost.Random. Cheers, Matthias

4 3

Macro which can determine size of tuple passed as argument
by 6orkup 05 May '08

05 May '08

Hi, I am trying to implement a macro which can determine size of tuple passed as argument. My first idea was to 1) remove parentheses from tuple using variadic macro (which I can afford for) 2) complement tuple elements list with "filler and marker" sequence 3) scan resulting arguments list right-to-left. Straightforward 1-3-arguments version using variadic macros and boost.preprocessor looks like: #include <boost/preprocessor/control/if.hpp> #define M4(a1,a2,a3,a4,...) BOOST_PP_IF(a4,3,M3(a1,a2,a3)) #define M3(a1,a2,a3) BOOST_PP_IF(a3,2,M2(a1,a2)) #define M2(a1,a2) BOOST_PP_IF(a2,1,M1(a1)) #define M1(a1) 0 #define M(...) M4(__VA_ARGS__,1,0,0,0) #define T(t) M t After preprocessing these invocations T((a,b,c)) T((a,b)) T((a)) expand to: 3 2 1 Unfortunately these macros do not allow to discriminate between 1 and 0 -element tuples: both T((a)) and T(()) invocations expand to 1 instead of 1 and 0 correspondingly. It seems that chosen approach might work if I had any way to append different filler to non-empty and empty tuple: with and without leading comma separator. Could you please advise me if it is possible to implement a macro which can determine size of tuple passed as argument ? Does boost.preprocessor allow this ? Can variadic macros be of any help ? Cheers, Yuri

1 0

[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 04 May '08

04 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 04 May '08

04 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