May 2006 - Boost - lists.preview.boost.org

Re: [boost] Infinite precision integer draft
by Martin Bonner 26 May '06

26 May '06

Gerhard Wesp Sent: > On Thu, May 25, 2006 at 04:41:32PM +0200, Maarten Kronenburg wrote: >> Users can implement an unsigned_integer by deriving from >> integer, but this will not give any performance gain. > > This would violate Item 32 in Effective C++, 3rd ed. by Scott Meyers: > Make sure public inheritance models "is-a". I agree it's not a good idea. > I suggest deriving from integer be disallowed in the TR2 proposal. ... however I don't think that is. If C++ had "final", then it could be compile time checked. As it is, I don't think TR2 could do more than make it undefined behaviour. We really don't want more undefined behaviour in C++ if we can avoid it. What is more, deriving from integer would actually work on all implementations (as far as public inheritance which doesn't model "is-a" works). -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 203894

2 1

[review][pimpl_ptr] Pimpl Pointer review begins
by Rene Rivera 26 May '06

26 May '06

The review of the pimpl_ptr library by Asger Mangaard starts today, Monday May 15th, 2006, and runs through May 25th, 2006. (Boost Reviews RSS feed <http://tinyurl.com/ogpj6>) Pimpl Pointer ------------- :Author: Asger Mangaard :Download: Boost Sandbox (http://boost-consulting.com/vault/) as "pimpl_ptr.zip". Direct download at <http://tinyurl.com/m66ox>. :Description: The pimpl idiom is widely used to reduce compile times and disable code coupling. It does so by moving private parts of a class from the .hpp file to the .cpp file. However, it's implementation can be tricky, and with many pitfalls (especially regarding memory management). The pimpl_ptr library is a single header file, implementing a special policy based smart pointer to greatly ease the implementation of the pimpl idiom. Review questions ---------------- Please always explicitly state in your review, whether you think the library should be accepted into Boost. You might want to comment on the following questions: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? Enjoy, Rene. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo

12 28

Anyone Using TortoiseCVS with anonymous to Checkout/update Boost from Sourceforge?
by Paul A Bristow 25 May '06

25 May '06

I am failing to get TortoiseCVS to checkout or update Boost files at Sourceforge. Since I don't have an account, I am trying to use Username: anonymous (This works OK at present using comandline CVS, using same connection - Firewall etc). I get :-((( "In H:\: "C:\Program Files\TortoiseCVS\cvs.exe" "-z3" "checkout" "-P" "boost/libs/math/test" CVSROOT=:pserver:anonymous@boost-sandbox.cvs.sourceforge.net:/cvsroot/boost- sandbox connect to boost-sandbox.cvs.sourceforge.net:2401 failed: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond. Success, CVS operation completed" Is anyone using this sucessfully like this (anonymous) Or can anyone suggest what I am doing wrong. Thanks Paul --- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539561830 & SMS, Mobile +44 7714 330204 & SMS pbristow(a)hetp.u-net.com

2 1

Additions to optional<>
by Fernando Cacciola 25 May '06

25 May '06

Hello I have a couple of pending additions to the Optional library. These are _new_ functions, so they shouldn't disrupt the release. Specifically: from_optional(o,default_value) and make_optional(condition,value) Given that the release is still ahead, is it OK to merge these additions to RC_1_34_0 or should I keep them in the trunk? TIA -- Fernando Cacciola SciSoft http://fcacciola.50webs.com/

3 2

[review][pimpl_ptr] Review ends today.
by Rene Rivera 25 May '06

25 May '06

This is a reminder that the review period for the pimpl_ptr library by Asger Mangaard ends today. If you have a few minutes to do a review please do so ASAP ;-) <http://lists.boost.org/Archives/boost/2006/05/104757.php> -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo

1 0

Re: [boost] [array] optional constructors in Boost.Array
by Martin Bonner 25 May '06

25 May '06

----Original Message---- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Thorsten Ottosen Sent: 25 May 2006 15:20 To: boost(a)lists.boost.org Subject: Re: [boost] [array] optional constructors in Boost.Array > Martin Bonner wrote: >> Thorsten Ottosen wrote: >> >>> Maybe you should just wrap boost::array: >>> >>> template< class T, unsigned N > >>> struct my_array : boost::array<T,N> >>> { >>> // provide constructors here >> >> >> How? >> >> >>> }; >> >> >> >> You can't construct the base boost_array in the base class >> initialization list of the constructor (because boost_array doesn't >> have a constructor that takes arguments), and by the time you get >> into the body of the my_array constructor it is too late - the >> boost_array is already default constructed. > > What do tou mean by "it's too late"? What I mean is, you can't construct the elements of the boost_array at that point. > > Since the "construction" of boost::array is a no-op, you can just > initialize it in the body my_array's contructors. I guess it depends what you want to use my_array for. If you are trying to hold primitive types, then that wrapping works fine. If you are trying to hold objects of a class type that doesn't even /have/ a default constructor, then it just won't work! (and yes, you can put such objects in a boost_array on a compliant compiler). -- Martin Bonner Martin.Bonner(a)Pitechnology.com Pi Technology, Milton Hall, Ely Road, Milton, Cambridge, CB4 6WZ, ENGLAND Tel: +44 (0)1223 203894

3 2

[Serialization] Things that should be qualified.
by David Abrahams 25 May '06

25 May '06

Aside from boost/pfto.hpp, there are several other examples of Boost.Serialization-specific functionality that was inappropriately pushed up into the top-level namespace. These headers are all in that category: boost/smart_cast.hpp, boost/state_saver.hpp, boost/static_warning.hpp, boost/strong_typedef.hpp. There is also at least one macro in that category: BOOST_EXPORT. That in particular seems likely to cause problems, because after all "export" is a keyword that's supported only on a few compilers and a natural stand-in, for those who want to support export, would be BOOST_EXPORT. This should've been BOOST_SERIALIZATION_EXPORT. This is clearly a broad issue across the serialization library design, and I request that Robert examine these and any other instances of the problem and take whatever steps are practical to correct it. Because some of these names are in the library's public interface, that may require a plan that spans several Boost releases. -- Dave Abrahams Boost Consulting www.boost-consulting.com

2 3

[smart_ptr] operator ->*
by Matt Calabrese 25 May '06

25 May '06

Is there any reason as to why the boost smart pointers don't have overloaded ->* operators? With just a few template function overloads they could account for any member function type given that it has a low number of parameters (you'd need a separate template for each different number of parameters). Right now, users have to explicitly dereference the smart pointers and then use .* which is fairly unintuitive. Granted, using member function pointers on smart pointers isn't horrbily common, but it's not too out of the ordinary. I suppose the forwarding of arguments could be an issue as it could imply extra copies, but is that really a reason not to support the operation at all? Forgive me if this has been brought up before. -- -Matt Calabrese

6 9

Problem with MSVC8.0, Shared_Ptr and SmartDevice SDK
by Vince 25 May '06

25 May '06

Hi, I am trying to port some .NET classes into moder C++ and I am using shared_ptr. I am trying to compile with Visual Studio 2005 and Pocket PC 2003 SDK to target some mobile devices and when I compile I got the following : error unknown CE compiler I have modified visualc.hpp to pass this test by adding : elif _MSC_VER < 2500 //Visual 8 Pocket PC 2003 and WM5 comes with 2048 # define BOOST_COMPILER_VERSION evc4.0 but it's not enough since after I get a problem with Interlocked I think, I had to comment the following : //#elif (defined( BOOST_MSVC ) || defined( BOOST_INTEL_WIN )) // //extern "C" long __cdecl _InterlockedIncrement( long volatile * ); //extern "C" long __cdecl _InterlockedDecrement( long volatile * ); //extern "C" long __cdecl _InterlockedCompareExchange( long volatile *, long, long ); // //# pragma intrinsic( _InterlockedIncrement ) //# pragma intrinsic( _InterlockedDecrement ) //# pragma intrinsic( _InterlockedCompareExchange ) // //# define BOOST_INTERLOCKED_INCREMENT _InterlockedIncrement //# define BOOST_INTERLOCKED_DECREMENT _InterlockedDecrement //# define BOOST_INTERLOCKED_COMPARE_EXCHANGE _InterlockedCompareExchange Now it compiles fine under Pocket PC but it's a bad workaround, if someone could provide a real fix... First thing to do is to check which version is used with Visual Studio 8 and smart devices SDK. If I look at afxver.h it seems to be 0x0800 but not sure that it's the right place to look at. Hope it helps

3 2

[1.34] Regression Failure MPL
by Thomas Witt 25 May '06

25 May '06

Aleksey, Dave, MPL has a test failure across all platforms on RC_1_34_0 could you please look into that. Thanks Thomas -- Thomas Witt witt(a)acm.org

1 0