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

Proposed addition to the iterator library for iterating over all tuples.
by Alex Mendes da Costa 19 Jun '09

19 Jun '09

Hi folks: I quite often have to write code to do the following: Given N sequences, generate all the N-tuples s.t. the i'th element in each tuple is drawn from the i'th sequence. For example, if sequence S1 is { 1, 2, 3 } and sequence S2 is { 10, 20 }, I need to generate these tuples: (1, 10), (2, 10), (1, 20), (2, 20). I think this problem could be solved elegantly with a iterator similar to zip_iterator. I have some questions: (1) Is there already a way to do this in boost? (2) If not, would this be a worthwhile addition to the iterator library? (3) If so, could I contribute code for this, or must the existing library owners write it? (4) If so, how would I go about getting my code added? Most of the docs seem to be about submitting entire libraries, rather than extensions to existing libraries. Thanks, Alex

3 7

[variant, MPL] Is there a variant -> mpl sequence metafunction ?
by Jaakko Järvi 13 Nov '06

13 Nov '06

make_variant_over<Seq>::type creates a variant type from an MPL Sequence. Is there an operation that would do the opposite, create an MPL sequence from a variant? I cannot just use the type parameter list as such because the types that stand for an empty type are different in both libraries: boost::detail::variant::void_ in variant, and something else in MPL. Best, Jaakko -- Jaakko Järvi, jarvi(a)cs.tamu.edu

2 3

[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

Bind comparisons
by David Abrahams 03 Feb '06

03 Feb '06

Is it really true that I can write bind(f, _1) > _2 but can't write _1 > _2 ?? I can't imagine a good reason for that restriction, but I don't see any indication that the latter is supported in the docs. -- Dave Abrahams Boost Consulting www.boost-consulting.com

6 11

[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

[database]
by Brock Peabody 10 Nov '05

10 Nov '05

Hi, I've added the code for the database project to the sandbox. I've also made the following changes based on feedback from Caleb and Jonathan: 1) fixed <: digraphs 2) added transaction functions to the abstract interface. Added a reference_counted_transaction_manager class for use in implementations that don't support nested transactions. 3) made the interface support null field detection via boost.optional 4) iteration supports BiDirectional model instead of RandomAccess 5) added a transaction class for scoped transaction management on the to-do list: 1) documentation - this is going to be a word document or something at first since I know nothing about html. 2) make .jam files 3) test cases - I'm not sure how these are going to work. 4) investigate possibility of supporting a prepare_statement function

2 2

Macros at namespace scope: trailing semicolon?
by David Abrahams 14 Oct '05

14 Oct '05

I am defining a macro, BOOST_PARAMETER_KEYWORD(tag_namespace, name) that declares a keyword for the Parameter library. It has to be used at namespace scope. I have the option to define it so that correct usage requires a trailing semicolon, or so that the trailing semicolon is forbidden. Unfortunately I don't have the ability to make it optional. Which should I choose? IMO there's no chance of confusing it with a function call, since a function call would be illegal in the context in which it's used, and people are naturally more likely to add a semicolon without thinking about it, and if I design the macro so that a semicolon is required it will interact more smoothly with editors and pretty-printers. So I can't see any good reason not to require the semicolon. Arguments? -- Dave Abrahams Boost Consulting www.boost-consulting.com

7 18