January 2008 - Boost - lists.boost.org

64-bit Boost.Integer
by Phil Endecott 20 Jan '08

20 Jan '08

Dear All, Back in April 2007 I posted a patch to add 64-bit ints to Boost.Integer: http://lists.boost.org/Archives/boost/2007/04/119895.php Scott McMurray replied to say that a patch for this was already waiting and hopefully "will get applied once 1.34 is dealt with". As far as I can see, the Boost.Integer in the release branch still doesn't have this: http://svn.boost.org/svn/boost/branches/release/boost/integer.hpp What needs to be done so that this functionality is included in 1.36? Phil.

4 4

accumulators + std::complex
by Neal Becker 20 Jan '08

20 Jan '08

typedef std::complex<double> complex_t; accumulator_set<complex_t,stats<tag::mean,tag::moment<2> > > results in what may be the longest error messages ever. Should this work?

2 2

[filesystem] POSIX compliant readdir_r to fix ticket #1578
by Beman Dawes 20 Jan '08

20 Jan '08

Sun supplies both POSIX and non-POSIX versions of readdir_r, according to http://docs.sun.com/app/docs/doc/819-2243/readdir-3c?a=view. The compliant version is selected by defining _POSIX_PTHREAD_SEMANTICS. So it looks to me that the fix for ticket #1578 (which is reporting the bug that results when the non-POSIX version is used) is to define _POSIX_PTHREAD_SEMANTICS at the beginning of boost-root/libs/filesystem/src/operations.cpp. This will cause the POSIX version to be used. I don't have access to a Sun system so can't test that. There is also a small chance that the same macro is used on some other platform in a conflicting way. I'd appreciate it if someone with access to a Sun system could test this (using the program given in the #1578). If I don't hear anything in a day or so, I'll go ahead and make the change to the trunk. Thanks, --Beman

1 0

Custom deleter for ptr_vector?
by Robert Dailey 20 Jan '08

20 Jan '08

Hi, I was wondering it is currently possible to give ptr_vector a custom deleter? This could simply be in the form of a functor. If this feature does not exist, would it be hard to add? For example, you could do this: namespace boost { namespace detail { template< typename t_type > struct default_deleter { void operator() ( t_type* ptr ) { delete ptr; } }; } template< typename t_type, typename t_deleter = detail::default_deleter<t_type> > class ptr_vector { private: std::vector<t_type*> m_pointers; public: ~ptr_vector() { std::for_each( m_pointers.begin(), m_pointers.end(), t_deleter() ); } }; }

3 4

Re: [boost] Boost Serialization of shared_ptr'boost@lists.boost.org'
by Kesseli Pascal 20 Jan '08

20 Jan '08

> Glad to hear that. Please tell my what your compiler environment was. Well, that would be a GCC 3.3.2 Cross-Compiler Toolchain, compiling from WinXP SP2 for Linux Moxa 2.4.18_mvl30-ixdp425 Montavista Embedded Operating System, using Eclipse CDT. > I also appreciate if you could run the whole serialization library test suite > using "library_test". (this is in the trunk/tools ...). I would recommend this > before using this code in production. I would be very interested in the results > and perhaps might find a way to included in the library status table. Uhm, I didn't find any test source or other useful files there. Do I have to download those files seperately or can I get a test code somewhere from? Greeetz Kessi No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.516 / Virus Database: 269.19.7/1232 - Release Date: 18.01.2008 19:32

1 0

[review] General comment on boost::singleton
by Marcus Lindblom 19 Jan '08

19 Jan '08

Hi, I haven't looked into it at detail, but I've followed the discussion on the singleton's to be or no to be. I think the singleton lib is good as a boost addition, because having many different singleton implementations suck. I also think that boost should encourage good code style. Therefore, I vote for an implementation that both separates the concepts provided (i.e. safe construction, uniqueness, global access & locking). The lib should also provide some kind of unifying scheme, so that the "classic-singleton" can be achieved by applying everything. Also, I think some good motivational documentation on why the classic singleton is not a scalable idea would be appropriate, so that we could get users to think about the orthogonal concepts and whether they really do need all concepts in one go. (Many of us have found out that we only need a subset, after much pain....) Cheers, /Marcus

4 3

[Intrusive] any online docs?
by Thorsten Ottosen 19 Jan '08

19 Jan '08

Hi Ion, I couldn't compile the quick-book docs manually (got wierd error below), but perhaps they are online somewhere? Thanks -Thorsten

3 4

[review request] Boost.Egg, function builders and adaptors
by shunsuke 19 Jan '08

19 Jan '08

Hi, I request my Boost.Egg library be enqueued into the formal review queue. The online document: http://p-stade.sourceforge.net/boost/libs/egg/ The brief description is found at: http://lists.boost.org/Archives/boost/2008/01/132301.php Regards, -- Shunsuke Sogame

1 0

[flyweight] Remainder: Flyweight review will start January 21
by Ion Gaztañaga 18 Jan '08

18 Jan '08

Hi to all, Flyweight library will be reviewed January 21-30. For those interested in the library, this post contains all the information needed for the review: *Author:* Joaquín M. López Muñoz *Description:* Flyweights are small-sized handle classes granting constant access to shared common data, thus allowing for the management of large amounts of entities within reasonable memory limits. Boost.Flyweight makes it easy to use this common programming idiom by providing the class template flyweight<T>, which acts as a drop-in replacement for const T. *Online docs:* http://tinyurl.com/2sstyr http://svn.boost.org/svn/boost/sandbox/flyweight/libs/flyweight/index.html *Download:* http://tinyurl.com/hrdm6 http://www.boost-consulting.com/vault/index.php?&direction=0&order=&directo… *Notes:* 1) We've seen some suggestions in the mailing list for Flyweight. Joaquín has nicely explained a couple of issues that we'd like to address/discuss in the review: http://tinyurl.com/33ghtf http://svn.boost.org/svn/boost/sandbox/flyweight/libs/flyweight/doc/review_… 2) Flyweight needs Boost 1.35 elements because the library depends on libraries like Interprocess for some features/tests. Since SVN snapshot tarballs seem to be missing these days, those who want to try flyweight can download a working SVN-HEAD snapshot here: http://igaztanaga.drivehq.com/boost_trunk.tar.bz2 3) Serialization tests won't work. This feature is expected to work when some new features (discussed in the mailing list between Joaquín and Robert Ramey) are added in Boost.Serialization. Those are expected for Boost 1.36. Regards, Ion

1 0

[smart_ptr] shared_ptr documentation inconsistency
by Frank Mori Hess 18 Jan '08

18 Jan '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The default shared_ptr constructor, which creates an empty shared_ptr, gives "use_count() == 0" as a post condition. However, the documentation for use_count says it returns "an unspecified nonnegative value when *this is empty". I'd like it to return 0 for an empty shared_ptr, as that appears to be the only way to distinguish an empty shared_ptr from one sharing ownership of a null pointer. - -- Frank -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHkRr05vihyNWuA4URArScAKCpSzE1iBEP02fn5GJhs3n/rwoItwCgkAxf uRlugdHTVX9TIsZH5swMy70= =9uJe -----END PGP SIGNATURE-----

1 0