January 2008 - Boost - lists.preview.boost.org

optional and typed_in_place_factory
by James Pelletier 19 Feb '08

19 Feb '08

I've run into problems using the typed_in_place_factory and optional objects. First, I ran into a problem where I initialized a typed_in_place_factory with a temporary and then used the factory after the temporary was destroyed. After a few hours of hair pulling, I figured out that the factory currently only stores references. This was a surprise because I have been using boost::bind for quite a while and it holds copies of the arguments. I propose that the typed_in_place_factory hold copies of the data as well. Users can pass boost::ref objects for types that aren't copyable with the added benefit that they explicitly know they need to keep the referenced object alive while the factory exists. Consistency between the behavior of boost::bind and the typed_in_place_factory is desirable because of their similar nature. Second, I've noticed that operator= for the optional takes a factory object by value. It seems like taking the argument by const reference would be desirable to prevent copying of the factory (which could be expensive if the changes to the typed_in_place_factory mentioned previously are accepted). Also, the conversion constructor takes the factory by const reference, so this may have just been a simple oversight. Below is a patch based on HEAD as of 2007-01-29. -------------------------------------------------------------- Index: boost/optional/optional.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/optional/optional.hpp,v retrieving revision 1.12 diff -p -r1.12 optional.hpp *** boost/optional/optional.hpp 26 Jun 2006 18:01:36 -0000 1.12 --- boost/optional/optional.hpp 29 Jan 2008 18:52:11 -0000 *************** class optional : public optional_detail: *** 510,516 **** // Assigns from an expression. See corresponding constructor. // Basic Guarantee: If the resolved T ctor throws, this is left UNINITIALIZED template<class Expr> ! optional& operator= ( Expr expr ) { this->assign_expr(expr,&expr); return *this ; --- 510,516 ---- // Assigns from an expression. See corresponding constructor. // Basic Guarantee: If the resolved T ctor throws, this is left UNINITIALIZED template<class Expr> ! optional& operator= ( Expr const& expr ) { this->assign_expr(expr,&expr); return *this ; Index: boost/utility/detail/in_place_factory_prefix.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/utility/detail/in_place_factory_prefix.hpp,v retrieving revision 1.2 diff -p -r1.2 in_place_factory_prefix.hpp *** boost/utility/detail/in_place_factory_prefix.hpp 26 Jun 2007 23:07:25 -0000 1.2 --- boost/utility/detail/in_place_factory_prefix.hpp 29 Jan 2008 18:52:13 -0000 *************** *** 26,32 **** #include <boost/preprocessor/repetition/enum_trailing_params.hpp> #define BOOST_DEFINE_INPLACE_FACTORY_CLASS_MEMBER_INIT(z,n,_) BOOST_PP_CAT(m_a,n) BOOST_PP_LPAREN() BOOST_PP_CAT(a,n) BOOST_PP_RPAREN() ! #define BOOST_DEFINE_INPLACE_FACTORY_CLASS_MEMBER_DECL(z,n,_) BOOST_PP_CAT(A,n) const& BOOST_PP_CAT(m_a,n); #define BOOST_MAX_INPLACE_FACTORY_ARITY 10 --- 26,32 ---- #include <boost/preprocessor/repetition/enum_trailing_params.hpp> #define BOOST_DEFINE_INPLACE_FACTORY_CLASS_MEMBER_INIT(z,n,_) BOOST_PP_CAT(m_a,n) BOOST_PP_LPAREN() BOOST_PP_CAT(a,n) BOOST_PP_RPAREN() ! #define BOOST_DEFINE_INPLACE_FACTORY_CLASS_MEMBER_DECL(z,n,_) BOOST_PP_CAT(A,n) BOOST_PP_CAT(m_a,n); #define BOOST_MAX_INPLACE_FACTORY_ARITY 10

2 1

Review request: Proto
by Eric Niebler 15 Feb '08

15 Feb '08

Proto, the library for defining expression template-based domain-specific languages, is ready for review. It's already actively being used by Boost.Xpressive and by Spirit-2, and is a key enabling technology in the long-planned unification of Phoenix and the Lambda Library. Documentation is here: http://boost-sandbox.sourceforge.net/libs/proto Download proto.zip from here: http://www.boost-consulting.com/vault/index.php?directory=Template%20Metapr… -- Eric Niebler Boost Consulting www.boost-consulting.com

6 10

[asio] read_until.cpp fails to compile on HP-UX_ia64_gcc
by Boris Gubenko 11 Feb '08

11 Feb '08

A couple of days ago (don't know exactly when), two asio library tests based on single source -- read_until.cpp -- started to fail to compile on HP-UX_ia64_gcc as the following: ../boost/asio/detail/socket_ops.hpp: In function 'int boost::asio::detail::socket_ops::select(int, fd_set*, fd_set*, fd_set*, timeval*, boost::system::error_code&)': ../boost/asio/detail/socket_ops.hpp:634: error: cannot convert 'fd_set*' to 'int*' for argument '2' to 'int select(size_t, int*, int*, int*, const timeval*)' While compilation error is obvious and can be eliminated by compiling with _XOPEN_SOURCE_EXTENDED macro defined, I could not figure out by looking at SVN log what changes have caused it. I verified that with _XOPEN_SOURCE_EXTENDED macro defined, all asio library tests pass on HP-UX_ia64_gcc. On another HP-UX/gcc platform participating in Boost testing -- HP-UX_pa_risc_gcc -- they pass with and without this macro defined. The platform details: HP-UX_ia64_gcc : HP-UX 11.23 ia64 with gcc 4.2.1 HP-UX_pa_risc_gcc : HP-UX 11.11 PA-RISC with gcc 3.4.2 Is it expected that asio library tests on HP-UX/gcc should be compiled with _XOPEN_SOURCE_EXTENDED macro defined? (for example, for SOLARIS, asio/test/Jamfile.v2 defines _XOPEN_SOURCE=500 and __EXTENSIONS__) And what was the change that broke HP-UX_ia64_gcc ? Thanks, Boris

2 1

[flyweight] Review period extended to February 3
by Ion Gaztañaga 07 Feb '08

07 Feb '08

Hi to all, We've received 4 positive reviews and several comments, but we still want more ;-) Some people expressed interested in the pre-review period and I want to give some time (weekend is the right time to review a Boost library...) to those who are interested in the library and have not found time to review it. The last review day is February 3. Common, the library is very lightweight ;-) to review, it's pretty well documented, it's certainly small and very general purpose. Here is the information. Last call to passengers! *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. What to include in Review Comments ================================== Your comments may be brief or lengthy, but basically the Review Manager needs your evaluation of the library. If you identify problems along the way, please note if they are minor, serious, or showstoppers. Here are some questions you might want to answer in your review: * 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? And finally, every review should answer this question: * Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. Ion Gaztañaga - Review Manager -

12 36

preview of a template geometry library
by Barend Gehrels 05 Feb '08

05 Feb '08

Hi, Herewith the URL to the preview of Geodan's Geometry Library, including documentation and some examples. There are still implementation issues and algorithmic details to be figured out or to be implemented. This is a preview and not yet a real submission. However I think that the community will get a feeling how it works and/or should work. The URL with documentation is here: http://geometrylibrary.geodan.nl/geometry.html and sources can be downloaded from that webpage. Best regards, Barend Gehrels ------------------------------------- Barend Gehrels, Geodan Holding b.v., Amsterdam, The Netherlands, www.geodan.nl

9 21

[serialization] Exception basic_string::resize - possible bug in string archiving?
by Jamie Allsop 04 Feb '08

04 Feb '08

I hate to post this as it's late and I can't help thinking I'm missing something obvious, but here goes. I am getting an exception thrown as a result of executing line 52 of boost/trunk/boost/archive/impl/basic_binary_iarchive.ipp (yes I'm using trunk, but this happens with my 1.34.1 also) The little program shown below causes it, the output of which is, "std::exception: basic_string::resize" I'm using gcc 4.2 on Debian fwiw. --- #include <boost/archive/binary_iarchive.hpp> #include <iostream> #include <string> #include <sstream> int main() { std::string SimpleString( "Archive" ); std::istringstream InputStringStream( SimpleString ); try { boost::archive::binary_iarchive iarchive( InputStringStream ); } catch( const std::exception& e ) { std::cout << "std::exception: " << e.what() << std::endl; } return 0; } --- So am I missing the obvious or is there something more going on here? Thanks, Jamie

1 1

[review] Review of Flyweight library started January 21 and still running!
by Ion Gaztañaga 03 Feb '08

03 Feb '08

Hi all, The formal review of Flyweight library started January 21 and will end January 30, we have a few nice reviews, but I'm sure that those who haven't reviewed it are also interested in the library ;-). The library solves quite a common programming pattern, is small and very well documented. So don't be afraid to try it! Information for reviewers: *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. What to include in Review Comments ================================== Your comments may be brief or lengthy, but basically the Review Manager needs your evaluation of the library. If you identify problems along the way, please note if they are minor, serious, or showstoppers. Here are some questions you might want to answer in your review: * 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? And finally, every review should answer this question: * Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. Ion Gaztañaga - Review Manager -

6 20

Review Request:boost.lexer
by Ben Hanson 01 Feb '08

01 Feb '08

Hi There, I have posted boost.lexer to the Boost File Vault and would like to request a review. Hartmut has integrated my library 'lexertl' into Spirit already, so this is the boost version of that library. Thanks, Ben Hanson

3 2

[1.35.0] Building the release?
by Beman Dawes 01 Feb '08

01 Feb '08

I'm starting to test build release candidate files for 1.35.0. The 1.34.0 and 1.34.1 release candidates were build by hand, IIUC. There is a Python script to do that job (boost-root/tools/release/make_tarballs.py), but it is out of date. I'm starting to work on updating it. What does such a script have to do? * Export SVN branches/release with the correct line endings for POSIX and Windows. * Build the quickbook/boostbook docs. * Set various file permissions. * Build the actual .zip, .gz, .bz2, and .7z files. What else? Where do the beta.boost.org web pages come from? --Beman PS: In the future, I think we should start building release files nightly for the next release as soon as a release ships. That will speed the process of identifying problems.

6 12

[review] Review of Flyweight library begins today January 7
by Ion Gaztañaga 01 Feb '08

01 Feb '08

The formal review of Flyweight library, proposed by Joaquín M. López Muñoz, begins today (sorry for the late announcement): *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. What to include in Review Comments ================================== Your comments may be brief or lengthy, but basically the Review Manager needs your evaluation of the library. If you identify problems along the way, please note if they are minor, serious, or showstoppers. Here are some questions you might want to answer in your review: * 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? And finally, every review should answer this question: * Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. Ion Gaztañaga - Review Manager -

9 18