November 2004 - Boost - lists.boost.org

Dynamic pluggable factories?
by Boost Rookie 02 Nov '04

02 Nov '04

Hi, is there anything in Boost which resembles the dynamic pluggable factories as described in the article "Industrial Strength Pluggable Factories" written by Timothy R. Culp and published in the October 1999 issue of C++ Report (available online http://www.javareport.com/joop/crarticle.asp?ID=1520)? If there is no such thing, has something like it been discussed? dismissed? I for one can see a real need for it! /br __________________________________ Do you Yahoo!? Check out the new Yahoo! Front Page. www.yahoo.com

4 3

[1.32 Release] Second draft of the tarballs is available
by Misha Bergal 01 Nov '04

01 Nov '04

Fixed privileges: * Unix: files/directories are writable/readable by owner and readable by others. Consequenty, regression.py now is able to correctly unpack the tarballs on Unix systems. * Windows: all files are writable The zip/tarballs are available from the following locations: http://www.meta-comm.com/engineering/boost/boost_1_32_0.tar.bz2 http://www.meta-comm.com/engineering/boost/boost_1_32_0.tar.gz http://www.meta-comm.com/engineering/boost/boost_1_32_0.zip -- Misha Bergal MetaCommunications Engineering

1 0

Re: [boost] Draft tarball & multi - index
by JOAQUIN LOPEZ MU?Z 01 Nov '04

01 Nov '04

----- Mensaje original ----- De: Craig Carr <craig.carr(a)perform-sol.com> Fecha: Lunes, Noviembre 1, 2004 7:39 pm Asunto: [boost] Draft tarball & multi - index > I don't know if this is valid here, but all none of the examples > in the multi-index library examples compile with vc7.1. All produce > internal compiler errors except basic.cpp > > Craig. Hi Craig, Boost.MultiIndex ought to work with that compiler. Have you checked the following? http://boost- consulting.com/boost/libs/multi_index/doc/compiler_specifics.html#msvc_7 1 If you haven't done so, please turn /Gm off. Please report whether this solves the problem. Best, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

too much typing
by Neal D. Becker 01 Nov '04

01 Nov '04

I'm always writing (e.g.) std::vector<double> out (size); std::transform (in.begin(), in.end(), out.begin(), func); Wouldn't it be nice to have versions of the std algorithms that worked like: template<typename out_cont_t, typename in_cont_t, typename UnaryOperation> inline out_cont_t transform_r (const in_cont_t& in, UnaryOperation u) { out_cont_t out (boost::size (in)); std::transform (boost::begin (in), boost::end (in), boost::begin (out), u); return out; } Then you can say: std::vector<double> out = transform_r<std::vector<double> > (in, func); That is, the first template parameter is the desired return container type, and the algorithm constructs the return value into it. Since constructors can be elided, I think this may be just as efficient as the original, or maybe better. OK, perhaps it looks like I didn't save much typing, but when you chain function calls you save a lot.

5 4

Draft tarball & multi - index
by Craig Carr 01 Nov '04

01 Nov '04

I don't know if this is valid here, but all none of the examples in the multi-index library examples compile with vc7.1. All produce internal compiler errors except basic.cpp Craig.

1 0

Re: [boost] [filesystem] regressions for operations_test
by JOAQUIN LOPEZ MU?Z 01 Nov '04

01 Nov '04

----- Mensaje original ----- De: Beman Dawes <bdawes(a)acm.org> Fecha: Domingo, Octubre 31, 2004 11:03 pm Asunto: Re: [boost] [filesystem] regressions for operations_test > At 03:56 PM 10/31/2004, JOAQUIN LOPEZ MU?Z wrote: > >Hi, > > > >msvc, msvc-stlport, iw-7_1-vc6 > >and iw-7_1-vc6-stlp-4_5_3 currently fail this > >test (see for instance http://tinyurl.com/4xo4a) > >I don't know for sure, but I've got the hunch this > >might be related with the fact that 2004 is > >a leap year and today we've had a 1-hour adjustment > >in some countries due to the daylight saving policy. > >These two facts combined might yield an offset > >outside the expected range. > >Just wanted to note this in case it might ring a > >bell for somebody. > > Or it might just be because offsets cross the daylight savings > time > boundary. > Well, that's what I was saying. The leap year and the cross-daylight saving issues combined will yield a time difference of 366*24*3600+3600 seconds, off the expected value by 1 hour. > I'll wait until the tests have cycled again, and then take a look. > If my theory's correct, these tests will revert to normal by November 2. This phenomenon will happen again 2008, October 26 to 28, and 2012 October 28 to 30. In 2016, however, the cross-daylight offset plays on the subtracting raher than the adding side, so the tests won't fail :) Excuse my indulgence on this silly issue. Joaquín M Lópeez Muñoz Telefónica, Investigación y Desarrollo

1 0

Lazy Metaprogramming Library [UPDATE]
by Vesa Karvonen 01 Nov '04

01 Nov '04

Hi, I have made some optimizations (resulting in an order of magnitude (10x) improvement in compile-time in some cases on GNU g++) to the library and implemented a couple of new metafunctions. The latest snapshot can now be downloaded from the Files Section (both zip and tar.bz for your convenience): http://groups.yahoo.com/group/boost/files/LazyMPL/ Please note that the library is only a proof-of-concept made in about 2 days. It should be quite possible to provide a more comprehensive library of lazy metafunctions and provide facilities like the lambda-facility of Boost MPL. (Also, you shouldn't worry about the upper case naming used in the library.) Lazy template metaprogramming, as shown by the lazy metaprogramming library, eliminates the number one stumbling block of template metaprogramming as described by every introduction or guide to template metaprogramming (e.g. http://www.boost.org/libs/mpl/doc/#applyif and Generative Programming section 10.11.1.3 Taking Advantage of Lazy Behavior (particularly pages 441-443... "You should remember this when writing static code" ;)). In lazy template metaprogramming, invocations (::type) are only needed when a value needs to be explicitly examined (e.g. to extract the head of a list). Use of the typename-keyword can be practically eliminated and forwarding (use of inheritance) is the usual way to implement functions. Explicit invocations can (are) also be used for optimizing lazy metafunctions, but optimizations are just optimizations. There is no need to optimize unless the metaprogram executes too slowly. It is likely that user metacode can rely on optimized library primitives for the most part. Regards, Vesa Karvonen <--- README-file ---> Lazy Metaprogramming Library ============================ Vesa Karvonen vesa_karvonen(a)hotmail.com This is a minimal proof-of-concept library that shows how one can implement lazy template metaprograms. Problem ------- Most contemporary template metaprogramming libraries are strict, which means that the result of a metafunction call is evaluated completely once the metafunction is invoked. Furthermore, metafunctions are written so that the arguments they receive are assumed to be completely evaluated. In addition to strictly evaluated function calls, most strict programming languages provide lazy control structures, such as `if' and `while', that evaluate their subexpressions only when needed. In contemporary template metaprogramming libraries, the separation between lazy control structures and strict metafunctions is often quite fuzzy, which can make programming quite confusing and burdensome. Basically, a programmer using a contemporary template metaprogramming library has to explicitly annotate the evaluation order of the metacode by carefully selecting when to invoke and when not to invoke a metafunction. The invocations can not simply be completely left out, because strict metafunctions do not accept uninvoked arguments. Solution -------- The metaprogramming style used in this library is different. Metafunctions and metadata structures (type lists) in this library are designed to be lazy. In particular, metafunctions assume that the arguments they receive are only delayed promises to compute the value of the argument once explicitly invoked. This change of style eliminates the need to constantly think about evaluation order. Metafunction invocations are only needed when a value explicitly needs to be examined. For example, the metafunction `HEAD<l>' evaluates to the head of the given list `l'. In order to do that, `HEAD' needs to explicitly invoke the parameter `l' to expose the list constructor `CONS' for pattern matching. However, and most importantly, callers of `HEAD' do not need to invoke the actual parameter for `HEAD'. (Explicit invocations can also be used for optimization, but it isn't strictly necessary.) In theory, the style used in this library could be the ideal way to implement template metaprograms, because the C++ standard almost requires template instantiations to be cached, which means that delayed promises are actually computed only once, saving CPU time. In other words, C++ implementations are almost required to perform memoization. In practice, however, the representation of type information may take a lot of memory and access to the instantiation cache isn't necessarily implemented efficiently. This can make lazy metaprograms less efficient in terms of time and space than their strict counterparts. Contents of the package ----------------------- The `inc/lazy_mpl' directory contains the library implementation. Only a minimal core plus a few higher-order functions on lists are provided. The list functions imitate the Haskell 98 standard prelude functions. The `test' directory contains a couple of ad hoc tests demonstrating the lazy programming style and the use of lazy lists. To get most out of the code, you should take a look at the unoptimized implementations of the higher-order list manipulation metafunctions `MAP', `FOLD[R|L]', `APPEND', `TAKE', `DROP', `ITERATE', `FILTER', and `ZIP_WITH'. As you can hopefully see, they are very cleanly expressed. That is how lazy metaprogramming would look like to a casual user. Future work ----------- This library is only a proof-of-concept. The intention is to show that lazy template metaprogramming is not only possible, but can yield both powerful and readable metaprograms. One important remaining issue would be to implement a lambda mechanism of some sort, which would make the use of higher-order metafunctions more convenient. Another issue would be to study how to best optimize lazy metafunctions. Many of the metafunctions in the library have been manually optimized by considering which of their arguments are strict (always invoked) and then making the implementation take advantage of the strictness by invoking the arguments early. The optimizations do not change the way the metafunctions are used (assuming the optimizations are correct), but can have a significant effect (order of magnitude) on performance. (I have not proven that the manually introduced optimizations are correct---I wouldn't be surprised if some of the optimization were incorrect.) Hopefully a good selection of optimized lazy metafunctions can practically eliminate the need for library users to manually optimize their code. At any rate, optimizations are only needed when a metaprogram evaluates too slowly. Copyright --------- (C) Copyright Vesa Karvonen 2004. Distributed under the Boost Software License, Version 1.0. (See accompanying file LICENSE.) _________________________________________________________________ Don't just search. Find. Check out the new MSN Search! http://search.msn.com/

2 1