April 2005 - Boost - lists.stage.boost.cppalliance.org

[jamboost] Boost.Build V2, Milestone 10 released
by Vladimir Prus 04 Nov '06

04 Nov '06

I'm pleased to announce that the next milestone release of Boost.Build V2 is available at http://prdownloads.sourceforge.net/boost/boost-build-2.0-m10.tar.bz2 http://prdownloads.sourceforge.net/boost/boost-build-2.0-m10.zip See also http://boost.org/boost-build2/ for online docs (a copy is included in distribution). Due to large number of improvements all users are encouraged to upgrade. Changes in this release: Many toolsets were added: Intel, Metrowerks, Comeau, aCC, vacpp. Documentation was converted to BoostBook and improved. Performance was improved. - Toolsets initialization syntax is much more uniform. Compiler and linker flags can now be specified. - The algorithm for computing build properties was improved. Conditional requirements can be chained, and a number of bugs were fixed. - Specific order of properties can be specified. - The main target rules can be called from everywhere, not necessary from Jamfile. - Check for "unused sources" removed. - The <library> feature affects only linking now. - The <file> feature now works only for libraries. - Simpler syntax for "searched" libraries was added. - New <dependency> feature. Unix: The right order of static libraries on Unix is automatically computed. The <hardcode-dll-paths> feature is the default. gcc: The -fPIC option is passed when creating shared libraries. Problems with distcc were solved. Sun: It's now possible to use the sun linker (as opposed to gnu), and to compile C files. Darwin: Shared libraries are now supported. MSVC: Before resource files compilation, the setup script is invoked. Options deprecated in 8.0 are not longer used. The following bugs were fixed: - The <unit-test> rule did not handle the <library> property. - Don't add "bin" to the build directory explicitly specified by the user. - Allow <include-type> to select staged targets, even with <traverse-dependencies>off. - Includes for the form '# include <whatever>" did not work. - (Qt) Add paths to all dependent libs to uic command line, which helps if the UI files uses plugins. - Using <toolset-msvc:version>xxx in requirements was broken. - Error message printed when target can be found is much more clear. - Inline targets in sources of 'stage' did not work. - Don't produce 'independent target' warnings on Windows - (gcc) The <link-runtime>static did not work. - (gcc) Suppress warnings from the 'ar' tool on some systems. - (gcc) Don't try to set soname on NT. Developer visible changes: - Generator priorities are gone, explicit overrides are used. - 'Active' features were removed - Support for VMS paths was added. Thanks to Christopher Currie, Pedro Ferreira, Philipp Frauenfelder, Andre Hentz, Jurgen Hunold, Toon Knapen, Johan Nilsson, Alexey Pakhunov, Brock Peabody, Michael Stevens and Zbynek Winkler who contributed code to this release. - Volodya

1 0

[Python] Slice test fails on Intel 8.1 at runtime
by Stefan Slapeta 23 Oct '06

23 Oct '06

This is not a new failure, but the failure is reported for the first time. Please could anybody have a look at it? See http://tinyurl.com/4n2fx Thanks, Stefan

2 1

TR2 and C++0x heads up
by Beman Dawes 23 Sep '06

23 Sep '06

The C++ standards committee's Library Working Group has proposed a schedule for library changes and extensions: * October 2005: cutoff date for C++0x major library proposals * October 2006: cutoff date for library TR2 proposals * April 2007: cutoff date for C++0x library clean-up papers The usual rule-of-thumb is that new library components go in TR2, while changes to existing components go in C++0x. The LWG will consider exceptions to the rule on a case-by-case basis. The LWG is planning to issue a "Call for Proposals" with details, but in the meantime Boost developers might want to start thinking about which Boost libraries they want to propose to the LWG. Because most proposals go through one or more revisions before being accepted, it helps a proposal's chances if it reaches the committee as many meetings as possible before the final cut-off. So far there are plans to propose Boost.Threads, Boost.Filesystem, and Boost.Signals. As well as proposals for some of the more major libraries, I personally hope someone will do a sweep through Boost looking at some of the smaller utilities and helpers for a possible "Small Additions" proposal. --Beman

4 4

New implementation of remove_xxx for vintage compilers
by Peder Holt 28 Mar '06

28 Mar '06

Hi. I have started implementing some of the missing type_traits functionality for vintage compilers using typeof. The following are complete, and seem to work flawlessly on VC 6.5 and 7.0: remove_pointer remove_reference remove_bounds The source is available at: http://groups.yahoo.com/group/boost/files/typeof_vintage.zip The use of typeof in this respect, makes remove_xxx much more flexible. Would it be possible to start using this scheme for compilers without partial template specialization support? #define BOOST_MAX_TYPEOF_SIZE 20 #include <boost/test/minimal.hpp> //Include typeof_define.hpp in all header files where new types are added to typeof. #include <boost/typeof/typeof_define.hpp> #include <complex> #include <boost/type_traits/remove_reference.hpp> #include <boost/type_traits/remove_pointer.hpp> #include <boost/type_traits/remove_bounds.hpp> #include <boost/type_traits/is_same.hpp> template<typename A0> struct X {}; template<typename A0,unsigned int A1> struct Y {}; template<typename A0,typename A1,long A2> struct Z {}; BOOST_TYPEOF_DEFINE_TEMPLATE(X,1,(typename)) BOOST_TYPEOF_DEFINE_TEMPLATE(Y,2,(typename,unsigned int)) BOOST_TYPEOF_DEFINE_TEMPLATE(Z,3,(typename,typename,long)) BOOST_TYPEOF_DEFINE_TEMPLATE(std::complex,1,(typename)) int test_main(int, char*[]) { BOOST_TEST((boost::is_same<X<int>* const[8][9],boost::remove_bounds<X<int>* const[5][8][9]>::type>::value)); BOOST_TEST((boost::is_same<Z<X<double&>,Y<bool[4][7],12324>,0>* const*,boost::remove_pointer<Z<X<double&>,Y<bool[4][7],12324>,0>* const**volatile>::type>::value)); //VC7.1 fails to compile remove_reference. BOOST_TEST((boost::is_same<Y<int,345>** const,boost::remove_reference<Y<int,345>** const&>::type>::value)); typedef BOOST_TYPEOF(5.+std::complex<double>(6,7)) result_type; BOOST_TEST((boost::is_same<result_type,std::complex<double> >::value)); return 0; } -- Peder Holt

1 0

[ANN] Phoenix-2 Preview
by Joel de Guzman 01 Dec '05

01 Dec '05

Hi, Hi. Here's a preview of Phoenix V2. This will probably be the last release of the library. Phoenix V2 will be the basis of the Phoenix and Boost.Lambda merger. You can get it here: http://spirit.sourceforge.net/dl_more/phoenix-2.zip You can browse the draft docs here: http://tinyurl.com/6crgp What's new? A lot. This is a total rewrite based on earlier discussions with Jaakko Jarvi. The library's is built on top of Fusion and of course MPL. Of particular interest are local variables and lambda-lambda scopes: http://tinyurl.com/3mn6w There is also a set of lazy functions that work on STL sequences (e.g. push_back etc.): http://tinyurl.com/46bbm and pretty soon, a final TODO item (built on top of scopes/ lambda), lazy STL algorithms (e.g. find_if, etc). The scopes section (link provided above) in the docs illustrates how to write lazy functions that accept higher order functions (e.g. for_each). Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net

14 38

policy_ptr?
by Peter Dimov 16 Aug '05

16 Aug '05

The recent lively thread in comp.lang.c++.moderated has sparked my interest in the policy_ptr proposal. Is the final version of the submission available? -- Peter Dimov http://www.pdimov.com

14 31

[Random] Mersenne Twister initialization problem [PATCH]
by Tiago de Paula Peixoto 21 Jul '05

21 Jul '05

Hi. The Mersenne Twister RNG was updated by the original author in 2002, because of a small problem in the seeding procedure, which was that the most significant bit of the seed was not well reflected to the state vector. Read http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/MT2002/emt19937ar.html for more details. The version implemented in Boost is the original 1998 one, which contains the problem. The attached patch implements the new seeding procedure, which uses something different than the linear congruential RNG to initialize the state vector. I haven't identified the new procedure to match any generator already implemented in Boost, so I just wrote it there (please correct me if I'm wrong). I have compared the output to the official implementation output, and it's identical. If the patch is OK, could it be applied? Thanks. -- Tiago de Paula Peixoto <tiago(a)forked.de>

13 35

[Review] Named parameters library
by Doug Gregor 10 Jul '05

10 Jul '05

The formal review of the Named Parameters library by David Abrahams and Daniel Wallin starts today and runs until Monday, November 22nd. The Named Parameters library provides a framework for writing functions that can accept arguments by name or by position. The use of named parameters can improve the readability of calls to these functions, especially when the functions have many parameters with default values. The Named Parameters library allows one to write a new_window function that allows a call such as: window* w = new_window("alert2", movable = true); The library is available in the Boost sandbox here: boost/named_params.hpp libs/utility And in the files area (login required): http://groups.yahoo.com/group/boost/files/named_params.zip Reviewers may wish to compare this solution to the named parameters already used by the Boost Graph Library, documented here: http://www.boost.org/libs/graph/doc/bgl_named_params.html Please send your reviews either to the Boost list or to me personally. The former is preferred, because it allows the community to consider your review as well. When writing your review, you may wish to consider the following questions (from http://www.boost.org/more/formal_review_process.htm#Comments) - 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? As always, please remember to clearly state whether you believe the library should be accepted into Boost. Thank you Doug Gregor Review Manager, Named Parameters library

2 1

[filesystem] i18n branch committed to CVS
by Beman Dawes 26 Jun '05

26 Jun '05

CVS now contains a branch "i18n" of the filesystem directories: * Class templates basic_path, basic_directory_iterator, etc, support narrow, wide, and user-defined path types. Typedefs path, directory_iterator, etc, are provided, so most existing code continues to work. * Name checking has been moved out of class basic_path, so it no longer gets in the way of those not using the name checking facility. Deprecated versions of various functions are provided to preserve existing code. * The need to explicitly identify native format paths via special constructors has been eliminated, simplifying casual use of the library. Deprecated versions of those constructors are provided to preserve existing code. More detailed documentation is available in the i18n CVS branch at <boost-root>/libs/filesystem/doc/i18n.html. Most of the other documentation has also been updated to reflect the changes. Current issues with the i18n branch include: * Testing has been limited to Intel 8.1, Metrowerks 9.3, and Microsoft 7.1 on Windows, and GCC 3.3 on Mac OS X. How much effort to put into broken compilers is going to be a real issue - internationalization may have to be disabled, and that is a lot of work. * Some tests (particularly in operations_test.cpp) are commented out. Minor issues need to be resolved and the tests reactivated. * Two or three of the less important doc files haven't been updated yet. * The convenience header and source code hasn't been converted yet. * The UTF-8 conversion facet header and source is duplicated. Need to identify and fix the issues that prevented the boost/detail version from being used. * The "// TODO" notes in the code need to be revisited, issues fixed, and the notes eliminated. * Testing on Windows 9X would be helpful, and issues fixed or documented. * Backed up issues and patches from the mailing list need to be addressed. * Windows tests need to be run on a FAT filesystem to see what issues arise. All of the Windows analysis and design effort so far has gone into NTFS, so there may be critical problems with filesystems that only support narrow paths. * The POSIX wpath implementation assumes that UTF-8 is always the operating system's preferred external path encoding. If any Boost users are concerned about other encodings, please let me know. * A timing test is needed, particularly for directory iteration. There is concern over excessive copying by basic_path conversion functions, so need to test if speed is a real problem in a realistic application. Any comments would be appreciated (but please look at the docs first, as a lot of effort went into rationale and trying to answer anticipated questions). My plan is to pause development for a while, both to allow time for comments to be made, and also so I can attack a backlog of non-Boost work that has been building up. --Beman

1 0

Patch for BOOST_OLD_IOSTREAMS detection
by Matthias Troyer 30 May '05

30 May '05

Hi, Several places in Boost try to detect BOOST_OLD_IOSTREAMS using the following ifdefs: // support for pre 3.0 libstdc++ - thanks Phil Edwards! #if defined (__STL_CONFIG_H) && !defined (__STL_USE_NEW_IOSTREAMS) # define BOOST_OLD_IOSTREAMS #endif This incorrectly defines BOOST_OLD_IOSTREAMS for the Cray X1 C++ compiler. Could this be changed to include an && !defined(__crayx1) or something similar as in: #if defined (__STL_CONFIG_H) && !defined (__STL_USE_NEW_IOSTREAMS) && !defined(__crayx1) # define BOOST_OLD_IOSTREAMS #endif Three offending files are: boost/dynamic_bitset/config.hpp boost/range/iterator_range.hpp libs/dynamic_bitset/example/timing_tests.cpp Maybe it would be best to move this to the global config file? Best regards Matthias

1 0