- Boost - lists.boost.org

[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

[1.34] Regression Failure io state saver
by Thomas Witt 25 May '06

25 May '06

Daryle, the io_state_saver test fail on all platforms on RC_1_34_0. This needs to be dealt with before we can release 1.34.0 Thanks Thomas -- Thomas Witt witt(a)acm.org

1 0

[Boost.Random]Comments/Questions
by Darren O'Driscoll 25 May '06

25 May '06

Hi all, I'm a relatively recent discoveror of these libraries, and for the last few weeks I've been like a kid in a toy shop as I've worked through them, and discovered the joys of the shared_ptr,bind,lambda,function libraries, etc. I've just arrived at the Boost.Random library, an area quite close to my heart as I make a lot of use of random deviate generators in my work in Financial Mathematics. I really like the set up and design of the libraries, but I have a few suggestions for additions which might be nice to have. Apologies in advance if these have already been discussed here, I haven't quite got the hang of searching through old posts in an efficient way. I hope noone's switched off during my long pre-amble, on to the meat of my post: 1. In general I've noticed that deviates for specific distributions are generated in one of two ways - a) according to a special algorithm, which usually involves generating one or more uniforms and doing some optimised transforms, or b) by generating a (0,1) uniform, and inverting the Cumulative distribution function. Method a), which seems to have been stuck to in Boost.Random is generally the more efficient of the two methods, but there are a number of cases where b) is necessary, specifically when using low-discrepancy sequences such as SOBOL as a base for the generation, of when using the stratified sampling technique in Monte Carlo. Would it be beyond the scope of this library to provide this kind of support? 2. Following on from the last point, it would be very useful if SOBOL sequence generation was included in the library. 3. I've noticed that at least one of the generators (Normal) uses a sub-optimal generator. I've attached an alternative implementation which I knocked together this evening which in my tests is about 30% faster. Note this was heavily influenced by an algorithm described in "Numerical Recipies in C". 4. The list of distributions where deviate generators are provided is quite short. As mentioned before, I'm quite interested in this area, and would be happy to help with algorithms for some other distributions, though sadly I would estimate that my C++ skills are still quite a lot below the median here. All comments welcome, Cheers Darren

2 1

New Boost RPM spec file
by Patrick Hartling 25 May '06

25 May '06

In my company's use of Boost, we have found that the Boost RPM installed with Linux distributions such as Fedora Core and Red Hat Enterprise Linux does not quite meet our needs. This happens because that RPM does not install the multi-threaded versions of the libraries, nor does it preserve the version information on the installed libraries. I have attached an RPM spec file that addresses these issues and that allows targeting 32-bit Linux from an x86_64 installation (though it has to exclude Boost.Python and Boost.iostreams). Personally, I would like to see Boost RPMs built that follow the existing Boost conventions more closely, but that may not be a popular view. If nothing else, I thought that posting this file would be helpful to people who have run into the same issues that we have seen. -Patrick -- Patrick L. Hartling | VP Engineering, Infiscape Corp. PGP: http://tinyurl.com/2oum9 | http://www.infiscape.com/ %define tarball_name boost_1_33_1 %define python_arch %(python -c 'import os; print os.uname()[4]') %if %{python_arch} == %{_arch} %define build_python 1 %else %define build_python 0 %endif Name: boost Summary: The Boost C++ Libraries Version: 1.33.1 Release: 1 License: Boost Software License URL: http://www.boost.org/ Group: System Environment/Libraries Source: %{tarball_name}.tar.bz2 BuildRoot: %{_tmppath}/boost-%{version}-root Prereq: /sbin/ldconfig BuildRequires: libstdc++-devel python Obsoletes: boost <= 1.33.0 Obsoletes: boost-devel <= 1.33.0 Obsoletes: boost-doc <= 1.33.0 %if %{build_python} Obsoletes: boost-python <= 1.33.0 %endif %description Boost provides free peer-reviewed portable C++ source libraries. The emphasis is on libraries which work well with the C++ Standard Library. One goal is to establish "existing practice" and provide reference implementations so that the Boost libraries are suitable for eventual standardization. (Some of the libraries have already been proposed for inclusion in the C++ Standards Committee's upcoming C++ Standard Library Technical Report.) %package devel Summary: The Boost C++ Headers Group: System Environment/Libraries Requires: boost = %{version}-%{release} %if %{build_python} Obsoletes: boost-python-devel <= 1.33.0 Provides: boost-python-devel = %{version}-%{release} %endif %description devel Headers for the Boost C++ libraries %package doc Summary: The Boost C++ html docs Group: System Environment/Libraries Requires: boost = %{version}-%{release} %if %{build_python} Provides: boost-python-docs = %{version}-%{release} %endif %description doc HTML documentation files for Boost C++ libraries %prep rm -rf $RPM_BUILD_ROOT %setup -n %{tarball_name} -q %ifarch i386 i486 i586 i686 %define arch_args <cflags>-m32 <cxxflags>-m32 <linkflags>-m32 <linkflags>-L/usr/lib %else %ifarch x86_64 %define arch_args <cflags>-m64 <cxxflags>-m64 <linkflags>-m64 <linkflags>-L/usr/lib64 %endif %endif %build without_libs='' %if %{build_python} == 0 without_libs="$without_libs --without-python" %endif # This is a hack. A better way needs to be devised for determining when # the local architecture does not match the target architecture. %if %{python_arch} != %{_arch} without_libs="$without_libs --without-iostreams" %endif #build bjam (cd tools/build/jam_src && ./build.sh) #build boost with bjam BJAM=`find tools/build/jam_src/ -name bjam -a -type f` PYTHON_VERSION=`python -V 2>&1 |sed 's,.* $[0-9]\.[0-9]$$\.[0-9]$\?.*,\1,'` PYTHON_FLAGS="-sPYTHON_ROOT=/usr -sPYTHON_VERSION=$PYTHON_VERSION" $BJAM $PYTHON_FLAGS "-sTOOLS=gcc" "-sBUILD=release <threading>single/multi %{arch_args}" "--prefix=$RPM_BUILD_ROOT%{_prefix}" $without_libs stage %install mkdir -p $RPM_BUILD_ROOT%{_libdir} mkdir -p $RPM_BUILD_ROOT%{_includedir} mkdir -p $RPM_BUILD_ROOT%{_docdir} mkdir -p $RPM_BUILD_ROOT%{_docdir}/boost-%{version} tar -C stage/lib -cvf - . | tar -C $RPM_BUILD_ROOT%{_libdir} -xpf - # install include files for i in `find boost -type d`; do mkdir -p $RPM_BUILD_ROOT%{_includedir}/$i done for i in `find boost -type f`; do install -m 644 $i $RPM_BUILD_ROOT%{_includedir}/$i done #install doc files cd doc/html; for i in `find . -type d`; do mkdir -p $RPM_BUILD_ROOT%{_docdir}/boost-%{version}/$i done for i in `find . -type f`; do install -m 644 $i $RPM_BUILD_ROOT%{_docdir}/boost-%{version}/$i done cd ../..; %clean rm -rf $RPM_BUILD_ROOT %post /sbin/ldconfig %postun /sbin/ldconfig %files %defattr(-, root, root) %{_libdir}/*.so.%{version} %files devel %defattr(-, root, root) %{_includedir}/boost %{_libdir}/*.a %{_libdir}/*.so %files doc %defattr(-, root, root) %{_docdir}/boost-%{version} %changelog * Apr 14 2006 Patrick Hartling <patrick(a)infiscape.com> 1.33.1-1 - Update to 1.33.1 - Install single- and multi-threaded libraries - Install fully versioned libraries - Allow 32-bit build to be made on 64-bit architecture (currently without Boost.Python or Boost.iostreams) * Mon Nov 29 2004 Benjamin Kosnik <bkoz(a)redhat.com> 1.32.0-1 - Update to 1.32.0 - (#122817: libboost_*.so symlinks missing) * Wed Sep 22 2004 Than Ngo <than(a)redhat.com> 1.31.0-9 - cleanup specfile - fix multiarch problem * Tue Jun 15 2004 Elliot Lee <sopwith(a)redhat.com> - rebuilt * Wed May 05 2004 Warren Togami <wtogami(a)redhat.com> 1.31.0-7 - missing Obsoletes boost-python * Mon May 03 2004 Benjamin Kosnik <bkoz(a)redhat.com> - (#121630: gcc34 patch needed) * Wed Apr 21 2004 Warren Togami <wtogami(a)redhat.com> - #121415 FC2 BLOCKER: Obsoletes boost-python-devel, boost-doc - other cleanups * Tue Mar 30 2004 Benjamin Kosnik <bkoz(a)redhat.com> - Remove bjam dependency. (via Graydon). - Fix installed library names. - Fix SONAMEs in shared libraries. - Fix installed header location. - Fix installed permissions. * Fri Feb 13 2004 Elliot Lee <sopwith(a)redhat.com> - rebuilt * Mon Feb 09 2004 Benjamin Kosnik <bkoz(a)redhat.com> 1.31.0-2 - Update to boost-1.31.0 * Thu Jan 22 2004 Benjamin Kosnik <bkoz(a)redhat.com> 1.31.0-1 - Update to boost-1.31.0.rc2 - (#109307: Compile Failure with boost libraries) - (#104831: Compile errors in apps using Boost.Python...) - Unify into boost, boost-devel rpms. - Simplify installation using bjam and prefix install. * Tue Sep 09 2003 Nalin Dahyabhai <nalin(a)redhat.com> 1.30.2-2 - require boost-devel instead of devel in subpackages which require boost-devel - remove stray Prefix: tag * Mon Sep 08 2003 Benjamin Kosnik <bkoz(a)redhat.com> 1.30.2-1 - change license to Freely distributable - verify installation of libboost_thread - more boost-devel removals - deal with lack of _REENTRANT on ia64/s390 - (#99458) rpm -e fixed via explict dir additions - (#103293) update to 1.30.2 * Wed Jun 04 2003 Elliot Lee <sopwith(a)redhat.com> - rebuilt * Tue May 13 2003 Florian La Roche <Florian.LaRoche(a)redhat.de> - remove packager, change to new Group: * Tue May 06 2003 Tim Powers <timp(a)redhat.com> 1.30.0-3 - add deffattr's so we don't have unknown users owning files

8 13

Proposal for radically altered approach to releases
by Beman Dawes 25 May '06

25 May '06

The current approach to getting releases ready is completely broken in my opinion. Each release requires heroic efforts by the release manager, careful attention by many developers, and endless delays until everything is just right. This is discouraging to developers and, worse yet, important library upgrades and bug fixes are taking far too long to get into user's hands. The problems with the current release approach are not caused by release managers or developers, but rather by the release system itself. It just doesn't scale up to the number of libraries now in Boost, since every library has to be ready before a release can occur. These problems will only grow worse as more libraries are added. I propose changing to a different release model, one based on always maintaining a release-ready stable branch and merging updates for individual libraries into it asynchronously. A draft proposal is available at http://mysite.verizon.net/beman/release_overview.html. I've put a fair amount of thought into this proposal, and have run some Subversion simulations to make sure it works smoothly. What do others think? --Beman

19 55