January 2012 - Boost-users - lists.boost.org

Re: [Boost-users] [boost] numeric_cast_traits/cstdint: request for fix in boost1.49
by John Maddock 29 Jan '12

29 Jan '12

> I've put a fix for this up on the trunk. I've run my unit tests on vc100 > and gcc-4.5.3 cygwin. Could some of you with the other platforms give it a > try? Confirmed that existing tests fail with old code (including with VC8). Tested with new code and VC8,9,10 and Intel-11.1, 12.1 all OK. On Linux gcc-4.4, 4.6 intel-11.1, 12.1 and clang all OK. Sun on Linux still fails, but appears to be a lexical_cast issue and not your problem - will report that separately. HTH, John.

1 0

boost for S60 - what's the current status?
by Igor R 29 Jan '12

29 Jan '12

Hello, I'd appreciate if anyone could sched some light on the subj. In particular, what boost libs are known to *not* compile on Symbian? Thanks!

1 0

boost with arm-none-eabi
by Artur Stępniak 28 Jan '12

28 Jan '12

Hi, I'm trying to compile a program with boost for my Cortex M3 based board. I don't run any OS in there. Is it possible to build program with boost on such board? My problem is that boost seems like to consume all the memory. The program builds without boost but after including shared_ptr.hpp I get error: section `.text' will not fit in region `rom'. I try to run configure script for boost: sh ./configure --host=arm but then I get arm-none-eabi/bin/ld: cannot find -lrt. Since this library supports POSIX, then I'm afraid it's impossible to compile programs with boost with no-OS systems. But maybe there's a switch that enables it? Thanks in advance, best regards, Artur Stepniak

1 0

numeric_cast_traits/cstdint: request for fix in boost 1.49
by Avi Bahra 28 Jan '12

28 Jan '12

Currently HPUX/acc compiler fails in boost 1.48, because boost::int8_t was being interpreted as a char, This causes duplicate class definition in the file ./boost/numeric/conversion/detail/preprocessed/numeric_cast_traits.hpp and hence many of compiled boost libs fail. See:: https://svn.boost.org/trac/boost/attachment/ticket/6158/cstdint_patch.diff The posted fix was to modify boost/cstdint.hpp: 103c103,107 2 < using ::int8_t; 3 --- 4 > #if defined(sun) || defined(__sun) 5 > typedef signed char int8_t; 6 > #else 7 > using ::int8_t; 8 > #endif Can I request a similar fix be added for the HPUX/acc compiler in the next boost version. Best regards, Ta, Avi

3 2

[1.49.0] Beta 1 available
by Beman Dawes 28 Jan '12

28 Jan '12

Boost release 1.49.0 beta 1 is now available from SourceForge See http://sourceforge.net/projects/boost/files/ This release contains a new library, Boost.Heap priority queues, and numerous enhancements and bug fixes for existing libraries. For details of what's in the release, see http://beta.boost.org/users/news/version_1_49_0. Note that the links to files on this web page are for the final release - use the SourceForge link above to get the beta files. Please download the beta, give it a try, and report any problems you encounter. Thanks, -- The Boost Release Team

1 0

status of Boost.LockFree and Boost.Atomic. Boost.Endian libraries?
by Igor Hersht 28 Jan '12

28 Jan '12

Could you tell me what is the status of Boost.LockFree and Boost.Atomic <https://svn.boost.org/trac/boost/wiki/ReviewScheduleLibraries#Boost.Atomic> . Boost.Endian libraries? Boost.LockFree and Boost.Atomic <https://svn.boost.org/trac/boost/wiki/ReviewScheduleLibraries#Boost.Atomic> accepted a while ago, but I didn't find the libraries in the latest 1.49 beta. Similar question about Boost.Endian ($(boost)\spirit\home\support\detail\endian\endian.hpp). When/if the Boost.Endian is going to be accepted as a separate library.

2 1

[interprocess] compilation errors with 1.48 on 64-bit Centos 5.5
by Daniel Herring 27 Jan '12

27 Jan '12

Hi, I started updating an application from Boost 1.35. It had a few compiler errors with 1.44, and things got worse with 1.48. While tracing down the new issues, problems were found with the distributed examples. For example, the following commands pass with 1.44 and 1.47 but fail with 1.48 (see attached logs). $ cd libs/interprocess/example $ ../../../bjam doc_managed_allocation_command > doc_managed_allocation_command.log $ ../../../bjam doc_managed_raw_allocation > doc_managed_raw_allocation.log All 1.44, 1.47, and 1.48 were built locally from the release source tarballs using a simple `./bootstrap.sh; ./bjam`. The example sources haven't changed during this period; so this may be a portability issue with the interprocess library itself. Here's some more info on the system. $ cat /etc/redhat-release CentOS release 5.5 (Final) $ g++ --version g++ (GCC) 4.1.2 20080704 (Red Hat 4.1.2-48) Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ rpm -qi gcc-c++ Name : gcc-c++ Relocations: (not relocatable) Version : 4.1.2 Vendor: CentOS Release : 48.el5 Build Date: Wed 31 Mar 2010 12:09:02 PM EDT Install Date: Mon 20 Sep 2010 06:02:55 AM EDT Build Host: builder17.centos.org Group : Development/Languages Source RPM: gcc-4.1.2-48.el5.src.rpm Size : 7824005 License: GPL Signature : DSA/SHA1, Mon 26 Apr 2010 07:41:02 PM EDT, Key ID a8a447dce8562897 URL : http://gcc.gnu.org Summary : C++ support for GCC Description : This package adds C++ support to the GNU Compiler Collection. It includes support for most of the current C++ specification, including templates and exception handling. The above commands do pass on release 1.48 when compiled using g++44 from the gcc44-c++-4.4.0-6.el5 package. However, that might not be an option for some of my users. Please let me know if more information is needed to debug the problem, if this is a known problem with gcc, etc. Thanks, Daniel

2 3

Re: [Boost-users] mpi::allocator::construct function in gcc 4.6.2
by MM 27 Jan '12

27 Jan '12

> -----Original Message----- > From: MM [mailto:finjulhich@gmail.com] > Sent: 27 January 2012 18:54 > To: 'boost-users(a)lists.boost.org' > Subject: mpi::allocator::construct function in gcc 4.6.2 > > Hello, > > I get the following error: > > In file included from /usr/lib/gcc/x86_64-redhat- > linux/4.6.2/../../../../include/c++/4.6.2/vector:64:0, > from /usr/lib/gcc/x86_64-redhat- > linux/4.6.2/../../../../include/c++/4.6.2/bits/random.h:34, > from /usr/lib/gcc/x86_64-redhat- > linux/4.6.2/../../../../include/c++/4.6.2/random:50, > from /usr/lib/gcc/x86_64-redhat- > linux/4.6.2/../../../../include/c++/4.6.2/bits/stl_algo.h:67, > from /usr/lib/gcc/x86_64-redhat- > linux/4.6.2/../../../../include/c++/4.6.2/algorithm:63, > from /usr/include/boost/utility/swap.hpp:24, > from /usr/include/boost/swap.hpp:10, > from /usr/include/boost/array.hpp:44, > from /usr/include/boost/serialization/array.hpp:26, > from > /usr/include/boost/archive/detail/oserializer.hpp:58, > from > /usr/include/boost/mpi/detail/mpi_datatype_oarchive.hpp:14, > from > /usr/include/boost/mpi/detail/mpi_datatype_cache.hpp:13, > from /usr/include/boost/mpi/datatype.hpp:27, > from /usr/include/boost/mpi/packed_iarchive.hpp:21, > from /home/hich/trunk/serialization/contract.cpp:3: > /usr/lib/gcc/x86_64-redhat- > linux/4.6.2/../../../../include/c++/4.6.2/bits/stl_uninitialized.h: In > function 'void std::__uninitialized_default_n_a(_ForwardIterator, > _Size, _Allocator&) [with _ForwardIterator = char*, _Size = long > unsigned int, _Allocator = boost::mpi::allocator<char>]': > /usr/lib/gcc/x86_64-redhat- > linux/4.6.2/../../../../include/c++/4.6.2/bits/vector.tcc:477:8: > instantiated from 'void std::vector<_Tp, > _Alloc>::_M_default_append(std::vector<_Tp, _Alloc>::size_type) [with > _Tp = char, _Alloc = boost::mpi::allocator<char>, std::vector<_Tp, > _Alloc>::size_type = long unsigned int]' > /usr/lib/gcc/x86_64-redhat- > linux/4.6.2/../../../../include/c++/4.6.2/bits/stl_vector.h:592:4: > instantiated from 'void std::vector<_Tp, > _Alloc>::resize(std::vector<_Tp, _Alloc>::size_type) [with _Tp = char, > _Alloc = boost::mpi::allocator<char>, std::vector<_Tp, > _Alloc>::size_type = long unsigned int]' > /usr/include/boost/mpi/detail/packed_iprimitive.hpp:57:23: > instantiated from here > /usr/lib/gcc/x86_64-redhat- > linux/4.6.2/../../../../include/c++/4.6.2/bits/stl_uninitialized.h:576: > 6: error: no matching function for call to > 'boost::mpi::allocator<char>::construct(char*)' > /usr/lib/gcc/x86_64-redhat- > linux/4.6.2/../../../../include/c++/4.6.2/bits/stl_uninitialized.h:576: > 6: note: candidate is: > /usr/include/boost/mpi/allocator.hpp:168:8: note: void > boost::mpi::allocator<T>::construct(boost::mpi::allocator<T>::pointer, > const T&) [with T = char, boost::mpi::allocator<T>::pointer = char*] > /usr/include/boost/mpi/allocator.hpp:168:8: note: candidate expects 2 > arguments, 1 provided > > I am using c++0x. > > Should mpi::allocator::construct() be different? Is it required to > provide a 1-arg construct()? > > > > Regards, > > MM I have added a 1-arg construct() that constructs default T()to mpi::allocator and that seems to compile correctly ,

1 0

Mersenne Twister 19937 suffers from "lattice effect"?
by Matthias Nagel 27 Jan '12

27 Jan '12

Hello, I tried to implement a two-dimensional multi-modal gaussian mixture and used the "mt19937" as the underlying generator. After I drew some samples (from the gaussian mixture) the outcome was not as I expected. After some bug tracking I suppose that the reason is something that is called "lattice effect" in German math literature. A pseudo-random generator suffers from a lattice effect, if one draws a sequence of samples, groups them together into N-dimensional vectors and these N-dimensional vectors are not uniformly distributed in the N-dimensional euclidean space. Does anybody know if the boost implementation has this problem? In the following, I will present my problem (and my algorithm) more elaborately, especially how I implemented my multi-model gaussian that is the origin of my problem: Lets assume we want a 2-dimensial gaussian mixture with M gaussian. 1) Create three lists (stl vector objects in my case), each with M entries. The first list stores the weight of each gaussian. The weights sum up to 1. The second list stores the mean value of each gaussian, i.e. a two-dimensional vector (in the mathematical sense, not the stl vector). The third list stores a 2-by-2 covariance matrix for each gaussian 2) Create a "mt19937" object, a "discrete_distribution" object and a "normal_distribution" object The "mt19937" is the common source of randomness for "discrete_distribution" and "normal_distribution". The "discrete_distribution" produces integers between 0 and M (number of gaussians) according the the given weights The "normal_distribution" is parameteized with mean = 0 and variance = 1, i.e. it is the standard normal distribtion. 3) Drawing one sample from the gaussian mixture - Draw one sample from the mt19937 and feed it into the discrete_distribution object. Denote the result by "index". - Draw a second sample from the mt19937 and feed it into the normal_distribution object. Denote the result by "u". - Draw a third sample from the mt19937 and feed it into the normal_distribution object. Denote the result by "v". - Pick up the mean vector and covariance matrix from the lists with respect to "index" - Transform the vector (u,v) according to the selected mean vector and covariance matrix. Denote the result "(x,y)". - Return (x,y) Lets remark that three samples are drawn from mt19937 to obtain one sample from the gaussian mixture. The result of this algorithm depends on the numbers of gaussians that build the mixture. 1) If M equals 1, the result looks fine. The (x,y) samples form an ellipsoid in the 2-dimensional euclidean space 2) If M equals 2, one gaussian looks like an ellipsoid, but it is too small. The second "gaussian" looks like a torus. Obviously all samples (u,v) with large coordinates are assigned to one gaussian, all (u,v) near zero are assigned to the other gaussian 3) If M equals 3, the "gaussians" look like segments of an ellipsoid. In each ellipsoid one third is missing. 4) For higher M the result is not correct either, but not as vivid and easily to explain as the "small" cases. As soon as I switch to random_device instead of mt19937 the phenomena disappears. ---------------------------------------------------------------------- Matthias Nagel Willy-Andreas-Allee 1, Zimmer 506 76131 Karlsruhe Telefon: +49 721 8695-1506 Telefax: +49 721 8695-4506 Mobil: +49 151 15998774 e-Mail: matthias.nagel(a)student.kit.edu ICQ: 499797758 Skype: nagmat84

3 3

BOOST_RESULT_OF_USE_DECLTYPE not default on C++11 compilers
by Jeremiah Willcock 27 Jan '12

27 Jan '12

At least on GCC 4.6 in C++0x (C++11) mode, BOOST_RESULT_OF_USE_DECLTYPE is not set by default, preventing classes such as boost::transform_iterator from working on built-in lambda expressions. Is there a reason that the use of decltype is not on by default for compilers that support it, perhaps with a flag to force emulation mode (like Boost.Move supports)? -- Jeremiah Willcock

4 7