- Boost - lists.preview.boost.org

[Math/nextafter] A question of naming functions...
by John Maddock 06 May '08

06 May '08

Folks I'm looking for some good names for some functions I'm on the brink of adding to Boost.Math (all in namespace boost::math::): T nextafter(T val, T dir) Returns the next representable floating point value to "val" in the direction of "dir". This name is basically fixed, since it's the one that C99 uses. T next_greater(T val) Returns the next representable value greater than "val". T next_less(T val) Returns the next representable value less than "val". T edit_distance(T a, T b) Returns the number of floating point representations between values a and b. So the questions are: can you think of any better names, or are these OK? And should edit_distance return a signed or absolute value? Thanks in advance, John.

12 41

Attn: BoostCon Attendees interested in C++0x
by Douglas Gregor 06 May '08

06 May '08

For those interested in attending the "Implementing a mini Boost.Fusion using C++0x" workshop, we suggest that you install a compiler capable of handling some of the C++0x features discussed today, especially decltype, variadic templates, and rvalue references. GCC 4.3 is one such option. For Windows users: MINGW is the fastest way to get GCC 4.3. Here are the steps: 1) Download the automated installer for MINGW, here: http://sourceforge.net/project/showfiles.php? group_id=2435&package_id=240780 When running the installer, you only need to install the "minimal" set of files. 2) Download the "core" and "g++" GCC 4.3.0 binaries from here: http://www.tdragon.net/recentgcc/ 3) Unzip the two files over top of your MINGW distribution, which replaces the default (ancient) compiler with GCC 4.3. 4) Try to compile a simple problem, e.g., "static_assert(false, "It works!");" with c:\mingw\bin\g++ -std=c++0x foo.cpp For Mac users: MacPorts has a version of GCC 4.3, which should be installable with: sudo port install gcc43 Fink also has a version of GCC 4.3 in the unstable distribution. Once you've configured for the unstable distribution, use: fink install gcc43 For Linux users: You can build GCC 4.3 on your own (get the source at gcc.gnu.org) or perhaps be lucky enough to find a binary for your particular distribution. - Doug

3 2

C++ Memory Management Innovation: GC Allocator
by shiwei xu 06 May '08

06 May '08

Most of the C++ programmers do not benefit from "Garbage Collection" technique (GC). They are sick of deleting objects but have to do this. There are some C/C++ memory GC implementations, but they are complex and are not widely used. I am going to introduce a new memory management technique named "GC Allocator". "GC Allocator" isn't an implementation, but a concept. Now, we have two "GC Allocator" implementations, named "AutoFreeAlloc" and "ScopeAlloc". This article consists of three parts: 1. What is GC Allocator? 2. GC Allocator implementations: ScopeAlloc and AutoFreeAlloc 3. Applications based on GC Allocator For more information, see http://www.codeproject.com/KB/cpp/gc-allocator.aspx To obtain a copy of this paper in pdf format click here<http://xushiwei.com/local--files/gc-allocator/GCAllocator.pdf>(or from google code <http://code.google.com/p/stdext/downloads/list>).

9 42

Trunk Boost Jam version users need to recompile.
by Jurko Gospodnetić 05 May '08

05 May '08

Hi all. Just a heads up that anyone using the trunk version of Boost Build newer than revision 45158 and the trunk version of Boost Jam (version 3.1.17) older than that revision needs to recompile their Boost Jam. Note that this does not affect people using the current release version (3.1.16) as the new Boost Build code preserves old behavior for older versions. This includes testers since they use the release version of Boost Jam. Without this recompile the thing that can happen is that some paths get parsed incorrectly. Best regards, Jurko Gospodnetić

1 0

Re: [boost] [Boost-build] BJam-Plugin for Eclipse
by Darren Garvey 05 May '08

05 May '08

On 05/05/2008, Frank Birbacher <bloodymir.crap(a)gmx.net> wrote: > > > > So, did you figure if you have trunk access? > > I did now: > > $ svn mv > http://svn.boost.org/svn/boost/sandbox-branches/birbacher/eclipse_contrib > > http://svn.boost.org/svn/boost/trunk/tools/build/v2/contrib/eclipse_plugins > -m "moved Eclipse plugins into trunk" Just a guess: try the same with https:// (note the 's'). -- Darren

2 1

throw_exception: gcc 3.2 errors
by Ralf W. Grosse-Kunstleve 05 May '08

05 May '08

Thanks a lot for the gcc warning workarounds! It is highly appreciated. Unfortunately, now g++ 3.2 doesn't work anymore. See below. I think gcc 3.3 and higher are fine. Ralf g++ (GCC) 3.2.3 20030502 (Red Hat Linux 3.2.3-20) boost svn rev. 45087 % cat te.cpp #include <boost/throw_exception.hpp> % g++ -Wall -Iboost -c te.cpp In file included from boost/boost/exception/enable_error_info.hpp:9, from boost/boost/throw_exception.hpp:39, from te.cpp:1: boost/boost/exception/exception.hpp: In instantiation of `boost::detail::sp_convertible<boost::exception_detail::error_info_container, boost::exception_detail::error_info_container>': boost/boost/exception/exception.hpp:75: instantiated from `boost::detail::sp_enable_if_convertible<boost::exception_detail::error_info_container, boost::exception_detail::error_info_container>' boost/boost/exception/exception.hpp:75: instantiated from here boost/boost/exception/exception.hpp:75: invalid use of undefined type `struct boost::detail::sp_convertible<boost::exception_detail::error_info_container, boost::exception_detail::error_info_container>' boost/boost/detail/sp_convertible.hpp:27: declaration of `struct boost::detail::sp_convertible<boost::exception_detail::error_info_container, boost::exception_detail::error_info_container>' boost/boost/exception/exception.hpp:75: enumerator value for `value' not integer constant

2 1

[smart_ptr] enable_shared_from_this / sp_accept_owner / virtual dtor
by Daniel Frey 05 May '08

05 May '08

In case someone is interested: The attached enable_shared_from_this proves that it is possible to add sp_accept_owner without forcing a virtual dtor. It's compatible with the 1.35.0 features and overhead. Regards, Daniel

2 3

[smart_ptr] future shared_from_this
by Frank Mori Hess 05 May '08

05 May '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Another idea would be to make a future<shared_ptr<T> > available in the constructor, the future would become ready with a shared_ptr from this when the object gets owned. - -- Frank -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIH0d65vihyNWuA4URAoUeAKDIBtVOn2S9sdOiHvPXNNRHBIJu6gCfZN4X 69bJ4nlhOHSf6dfLaEKpQ5Q= =74HG -----END PGP SIGNATURE-----

1 0

[1.35][lexical_cast][concept check][range] Build error and warnings with MSVC8 on Warning Level 4
by Stephan Diederich 05 May '08

05 May '08

As we tried to update to 1.35 today, we found some warnings with MSVC on Warning Level 4 in: lexical_cast: There was a return statement after a call to throw_exception which causes a unreachable code warning. I can see no problem by just removing that return. see http://svn.boost.org/trac/boost/ticket/1791 concept_check: BOOST_concept(SGIAssignable,(TT)) causes two warnings: C4510: default constructor could not be generated C4610: object 'class' can never be instantiated - user-defined constructor required solved thorugh pragmas see http://svn.boost.org/trac/boost/ticket/1792 and an error in range/iterator_range: see http://svn.boost.org/trac/boost/ticket/1793 for details. The patch is attached, as I was not able to discuss with Akismet that it's no spam ;) "Submission rejected as potential spam (Akismet says content is spam)" cheers, stephan

4 7

1.35 + gcc4.3?
by Neal Becker 05 May '08

05 May '08

Will patches to build on gcc-4.3 make it into boost-1.35 release? Would be desirable. Fedora F9 is out soon and has gcc-4.3 - I think other distributions will follow soon.

2 1

Header only pro's and con's?
by Roland Schwarz 04 May '08

04 May '08

Please don't misunderstand this mail. I do not want to start a header contra lib war. I just want to learn about the pro's and the contras of header only. The issue has popped up in this list quite some times, but I was not able to find any document which tries to do a serious in-depth discussion of when to header only and when not. If anyone knows about such a document I would be pleased if he could point me at it. Thank you. -- _________________________________________ _ _ | Roland Schwarz |_)(_ | aka. speedsnail | \__) | mailto:roland.schwarz@chello.at ________| http://www.blackspace.at

4 3

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

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

04 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 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

[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