- Boost - lists.boost.org

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

[smart_ptr] cosmetic enhancement in intrusive_ptr
by Carlo Medas 03 May '08

03 May '08

Dear all, I'm kind of newbie here in this mlist although I've been using boost for a while now. I've been using and loving smart pointers in complex production environments with amazing results. Very trivial suggestion for cosmetic enh in intrusive_ptr: why isn't there a method like shared_ptr::reset()? I mean the one with no arguments. It's good in some code sections (e.g. to control release ordering) to reset pointers, but intrusive_ptr is missing the reset with no arguments, thus I have to do 'reset(0)'; this is not nice to read and not symmetric with shared_ptr where you can do sptr.reset() Thanks and best regards, Carlo Medas http://www.linkedin.com/in/carlomedas

1 0

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

03 May '08

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

1 0

GTL compile time and concepts redesign
by Simonson, Lucanus J 03 May '08

03 May '08

I have modified my example code to move the accessors out of the templated traits class and into a non-templated concept struct as Fernando suggested. I also added compile time accessors that are parameterized by enum values, which I decided would give me the benefits of type safety and readability I was getting with my isotropic types as runtime parameters, while allowing the much desired compile-time parameter for people who prefer it. The runtime accessors are still there and call the compile-time accessors by default. The user can specialize the accessors to adapt them to their type, but now it is significantly harder to do so, because previously the accessors were members of a template class, and it was the class that was specialized, allowing the functions to retain their template parameter list. Now I am unable to partially specialize the accessor functions, which means that I cannot make their arguments template parameters of the function (because the user can't be expected to specialize for every conceivable type.) The user also has to explicitly specialize each version of the compile-time accessor, such as: template <> inline rectangle_traits<LayoutObject>::interval_type rectangle_concept::get<HORIZONTAL>(const LayoutObject& rectangle) { return rectangle_traits<LayoutObject>::interval_type(rectangle.xl, rectangle.xh); } template <> inline rectangle_traits<LayoutObject>::interval_type rectangle_concept::get<VERTICAL>(const LayoutObject& rectangle) { return rectangle_traits<LayoutObject>::interval_type(rectangle.yl, rectangle.yh); } and can't do the following: template <orientation_2d_enum orient> inline rectangle_traits<LayoutObject>::interval_type rectangle_concept::get(const LayoutObject& rectangle) { if(orient == HORIZONTAL) return rectangle_traits<LayoutObject>::interval_type(rectangle.xl, rectangle.xh); return rectangle_traits<LayoutObject>::interval_type(rectangle.yl, rectangle.yh); } as might be their first inclination. I'm not sure to what extent that makes specializing the accessors harder. User feedback I get is that specialization (all kinds) is hard, and in practice I usually help them out by providing the specializations they need for the types they have to get them over that first hurdle and running with library. I feel that there is still some more progress to be made here, please have a look. Thanks, Luke

1 0