- Boost - lists.preview.boost.org

Lazy Metaprogramming Library
by Vesa Karvonen 18 Nov '04

18 Nov '04

Lazy Metaprogramming Library ============================ Vesa Karvonen vesa_karvonen(a)hotmail.com 30. October 2004 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, there usually is no clear separation between lazy control structures and strict metafunctions, 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 metafunction do not accept uninvoked arguments. Solution -------- The metaprogramming style used in this library is different. Metafunctions and data 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 actual 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 parameter. 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 functional programming terms, C++ implementations are almost required to perform memoization or graph reduction. 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 couple of higher-order functions on lists are provided. 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 implementation 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 casually user. Future work ----------- This library is only a proof-of-concept. The intention is to show that lazy template metaprogramming is possible and can yield correct and highly readable metaprograms. The metafunctions in this library are written for clarity rather than optimized for heavy use. In particular, many of the provided metafunctions are strict in one ore more parameters, which means that those parameters are always invoked as a result of invoking the metafunction. An optimization technique called ``strictness analysis'' could be used to systematically optimize the metafunctions. The optimization would not change the way the metafunctions are used, but would change how they are evaluated internally. In some cases the optimization could be significant. Another practical issue would be to implement some sort of lambda mechanism, which would make the use of higher-order metafunctions more convenient. Copyright --------- (C) Copyright Vesa Karvonen 2004. Distributed under the Boost Software License, Version 1.0. (See accompanying file LICENSE.) _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.com/

4 3

Re: Lazy Metaprogramming Library
by Vesa Karvonen 17 Nov '04

17 Nov '04

David Abrahams >Terje Slettebø: > > >> Yes, that is exactly what I mean above. *Systematic* use of lazy > >> template metaprogramming would yield the following (unoptimized) > >> factorial function: > >> > >> template<class n> > >> struct FACT > >> : IF<IS_0<n>, > >> INT<0>, > >> TIMES<n, FACT<PRED<n> > > > {}; > > > > Elegant, indeed. > >But it doesn't work ;-) Yes, the code snippets in my message have several typos. Like I recall seeing certain B.S. saying in a USENET posting, I don't (always) compile my e-mails. :) However, I have written a complete walkthrough of the factorial example that you can find in the library I just updated: http://groups.yahoo.com/group/boost/files/LazyMPL/ [...] >In fact it would look almost the same in MPL, though ;-) > > template<class n> > struct fact > : if_<equal_to<n, int_<0> >, > int_<1>, // <== here's the fix ;-) > multiplies<n, fact<typename prior<n>::type> > > {}; Yes, I realize that MPL contains *lots* of "glue" to make Strict TMP (strict template metaprogramming) as pleasant as possible. However, are you sure that the above works? It seems to me that you are missing at least an invocation... ;--) >The one typename appears there because prior can work on iterators as >well as numeric types. We can kill it this way: > > template<class n> > struct fact > : if_<equal_to<n, int_<0> >, > int_<1>, > multiplies<n, fact<minus<n, int_<1> > > > > {}; > >And this particular case is especially friendly to MPL. ^^^^^^^^^^^^^^^^^^^^^^^^^^ >Some of those advantages are lost when you're not manipulating >numeric values. I'm not sure what mean here. Please elaborate. > >> As you can see, all explicit invocations are eliminated. I think > >> that there is a huge difference between applying laziness in an > >> essentially ad hoc manner (little here and little there) rather than > >> applying it systematically (all metafunctions are lazy). > >Agreed, in the general case. Yes, like I said earlier, the factorial function isn't a particularly good example---for several reasons. (However, the factorial function does have the virtue of being a simple case to understand and discuss.) > >> template<long n> > >> struct FACT<INT<n> > // #1.A > >> : INT<(n * FACT<(n-1)>::eval::value)> {}; > ^^^^^ >I don't think so. You can only pass a type here. [Again, this is fixed in the example that you can find in the updated library.] >MPL isn't afraid of specializations, FWIW. There's nothing going >on in the above example that couldn't be done with MPL so far. Also note that Lazy TMP (lazy template metaprogramming) can be done without pattern matching. I've used pattern matching in the proof-of-concept library, because it can sometimes be simpler and I have no interest to avoid pattern matching just because some compiler might not support it properly. (Of course, pattern matching is something that should be avoided when one is designing generic operations. Explicitly naming a specific (type) constructor in a pattern can make the code dependent on a particular representation.) >This FACT isn't generic (doesn't work for LONG<3>, for example; I >assume you have LONG). No. The library only has the INT-template, whose template argument is a long. Designing a complete numeric tower hasn't been a priority so far. (Actually, I think that supporting several primitive integer types may be an unnecessary overkill anyway, but this is something I have no interest to discuss at this point. It would be a red-herring, IMO. The issue is orthogonal to the issues of Lazy TMP vs Strict TMP.) > > [...] concept of using both strict and non-strict > > parameters in the same algorithm. :) > > Just when I thought I had grokked metaprogramming. ;) >It's just an FP thing. Has nothing to do with TMP, really. Yes, that is basically true. (While speaking of the concept of strictness, that is.) However, issues related to strictness and laziness are particularly important when it comes to template metaprogramming. The C++ template mechanism is both too lazy and too strict. It is too lazy in the sense that a metafunction has to be explicitly invoked to get the final value of a computation. It is too strict in the sense that once a metafunction is invoked, all the invocations in the body of the metafunction (or specialization) are evaluated immediately. > >> #1.A and #1.B) The explicit invocation of the `l' parameter > >The only explicit invocation of `l' I can see is in #1. Maybe that's >what you meant. [Yes. #1 referred to the invocation and #1.A/#1.B referred to points where the information revealed by the invocation was used.] -Vesa Karvonen _________________________________________________________________ Don't just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/

2 1

Dynamically growing Graph and Graph Algorithms.
by Manas Singh 17 Nov '04

17 Nov '04

The graph algorithms like depth first search and breadthe search works fine when you have the graph readily available before you call the BFS/DFS function. But I am trying to make the DFS and BFS work when I have a dynamiccaly growing graph. More specifically I start with only one node and call the DFS function. When the DFS discovers a node, I add more nodes to the graph in the visitor discover function. But I am not able to grow the graph's color map. So although I am adding vertices to the graph the color map remains the same, and so the DFS fails. Is there any way I can make DFS work with dynamically growing graphs. I come across this requirement while trying to build a web crawler using DFS. When crawling I start with one node only. But gradually I keep on adding nodes in the discover vertex method of DFS. Any suggestions are welcome. Thanks, Manas.

1 0

Boost Graph Library - Property Map Conversions
by Manas Singh 17 Nov '04

17 Nov '04

Is it possible to convert other Property Maps to Vector Property Map? My requirement is that the property map should be able to grow/expand (as I am using it with a dynamic graph which also grows). But I want to make it generic so that it works for any kind of property map. So I think if I am able to convert any type of property map to vector property map then I can grow the property map, when I add new vertices to the graph. Thanks, Manas.

1 0

Building Boost 1.32.0 RC on FreeBSD (GCC 3.4.2)
by Simon Barner 17 Nov '04

17 Nov '04

Hi, I am trying to build the lastest boost release candidate (also tried the latest CVS version), and I am getting the below compiler error. I suppose, there is some problem with the wide character support, but I could not fix it. Perhaps someone on this list had similar problems and knows what to do? System Info: FreeBSD 5.3-STABLE, Compiler: (gcc -v) Using built-in specs. Configured with: FreeBSD/i386 system compiler Thread model: posix gcc version 3.4.2 [FreeBSD] 20040728 Let me know, if you need more info, or if I should ask somewhere else, and thanks in advance for your time. Regards, Simon /storage/tmp/portbuild/usr/ports/devel/boost-1.32.0/work/boost_1_32_0/boost/archive/iterators/remove_whitespace.hpp: In instantiation of `boost::archive::iterators::filter_iterator<<unnamed>::remove_whitespace_predicate<wchar_t>, boost::archive::iterators::istream_iterator<wchar_t> >': /storage/tmp/portbuild/usr/ports/devel/boost-1.32.0/work/boost_1_32_0/boost/archive/iterators/remove_whitespace.hpp:165: instantiated from `boost::archive::iterators::remove_whitespace<boost::archive::iterators::istream_iterator<wchar_t> >' /usr/include/c++/3.4/bits/stl_iterator_base_types.h:129: instantiated from `std::iterator_traits<boost::archive::iterators::remove_whitespace<boost::archive::iterators::istream_iterator<wchar_t> > >' /storage/tmp/portbuild/usr/ports/devel/boost-1.32.0/work/boost_1_32_0/boost/detail/iterator.hpp:83: instantiated from `boost::detail::iterator_traits<boost::archive::iterators::remove_whitespace<boost::archive::iterators::istream_iterator<wchar_t> > >' /storage/tmp/portbuild/usr/ports/devel/boost-1.32.0/work/boost_1_32_0/boost/iterator/iterator_categories.hpp:163: instantiated from `boost::iterator_traversal<boost::archive::iterators::remove_whitespace<boost::archive::iterators::istream_iterator<wchar_t> > >' /storage/tmp/portbuild/usr/ports/devel/boost-1.32.0/work/boost_1_32_0/boost/mpl/eval_if.hpp:33: instantiated from `boost::mpl::eval_if<boost::is_same<boost::use_default, boost::use_default>, boost::iterator_traversal<boost::archive::iterators::remove_whitespace<boost::archive::iterators::istream_iterator<wchar_t> > >, boost::mpl::identity<boost::use_default> >' /storage/tmp/portbuild/usr/ports/devel/boost-1.32.0/work/boost_1_32_0/boost/iterator/iterator_adaptor.hpp:167: instantiated from `boost::detail::ia_dflt_help<boost::use_default, boost::iterator_traversal<boost::archive::iterators::remove_whitespace<boost::archive::iterators::istream_iterator<wchar_t> > > >' /storage/tmp/portbuild/usr/ports/devel/boost-1.32.0/work/boost_1_32_0/boost/iterator/iterator_adaptor.hpp:218: instantiated from `boost::detail::iterator_adaptor_base<boost::transform_iterator<boost::archive::iterators::detail::to_6_bit<wchar_t>, boost::archive::iterators::remove_whitespace<boost::archive::iterators::istream_iterator<wchar_t> >, boost::use_default, boost::use_default>, boost::archive::iterators::remove_whitespace<boost::archive::iterators::istream_iterator<wchar_t> >, wchar_t, boost::use_default, wchar_t, boost::use_default>' /storage/tmp/portbuild/usr/ports/devel/boost-1.32.0/work/boost_1_32_0/boost/iterator/iterator_adaptor.hpp:266: instantiated from `boost::iterator_adaptor<boost::transform_iterator<boost::archive::iterators::detail::to_6_bit<wchar_t>, boost::archive::iterators::remove_whitespace<boost::archive::iterators::istream_iterator<wchar_t> >, boost::use_default, boost::use_default>, boost::archive::iterators::remove_whitespace<boost::archive::iterators::istream_iterator<wchar_t> >, wchar_t, boost::use_default, wchar_t, boost::use_default>' /storage/tmp/portbuild/usr/ports/devel/boost-1.32.0/work/boost_1_32_0/boost/iterator/transform_iterator.hpp:92: instantiated from `boost::transform_iterator<boost::archive::iterators::detail::to_6_bit<wchar_t>, boost::archive::iterators::remove_whitespace<boost::archive::iterators::istream_iterator<wchar_t> >, boost::use_default, boost::use_default>' /storage/tmp/portbuild/usr/ports/devel/boost-1.32.0/work/boost_1_32_0/boost/archive/iterators/binary_from_base64.hpp:86: instantiated from `boost::archive::iterators::binary_from_base64<boost::archive::iterators::remove_whitespace<boost::archive::iterators::istream_iterator<wchar_t> >, wchar_t>' /usr/include/c++/3.4/bits/stl_iterator_base_types.h:129: instantiated from `std::iterator_traits<boost::archive::iterators::binary_from_base64<boost::archive::iterators::remove_whitespace<boost::archive::iterators::istream_iterator<wchar_t> >, wchar_t> >' /storage/tmp/portbuild/usr/ports/devel/boost-1.32.0/work/boost_1_32_0/boost/detail/iterator.hpp:83: instantiated from `boost::detail::iterator_traits<boost::archive::iterators::binary_from_base64<boost::archive::iterators::remove_whitespace<boost::archive::iterators::istream_iterator<wchar_t> >, wchar_t> >' /storage/tmp/portbuild/usr/ports/devel/boost-1.32.0/work/boost_1_32_0/boost/iterator/iterator_traits.hpp:49: instantiated from `boost::iterator_difference<boost::archive::iterators::binary_from_base64<boost::archive::iterators::remove_whitespace<boost::archive::iterators::istream_iterator<wchar_t> >, wchar_t> >' /storage/tmp/portbuild/usr/ports/devel/boost-1.32.0/work/boost_1_32_0/boost/mpl/eval_if.hpp:33: instantiated from `boost::mpl::eval_if<boost::is_same<boost::use_default, boost::use_default>, boost::iterator_difference<boost::archive::iterators::binary_from_base64<boost::archive::iterators::remove_whitespace<boost::archive::iterators::istream_iterator<wchar_t> >, wchar_t> >, boost::mpl::identity<boost::use_default> >' /storage/tmp/portbuild/usr/ports/devel/boost-1.32.0/work/boost_1_32_0/boost/iterator/iterator_adaptor.hpp:167: instantiated from `boost::detail::ia_dflt_help<boost::use_default, boost::iterator_difference<boost::archive::iterators::binary_from_base64<boost::archive::iterators::remove_whitespace<boost::archive::iterators::istream_iterator<wchar_t> >, wchar_t> > >' /storage/tmp/portbuild/usr/ports/devel/boost-1.32.0/work/boost_1_32_0/boost/iterator/iterator_adaptor.hpp:218: instantiated from `boost::detail::iterator_adaptor_base<boost::archive::iterators::transform_width<boost::archive::iterators::binary_from_base64<boost::archive::iterators::remove_whitespace<boost::archive::iterators::istream_iterator<wchar_t> >, wchar_t>, 8, 6, wchar_t>, boost::archive::iterators::binary_from_base64<boost::archive::iterators::remove_whitespace<boost::archive::iterators::istream_iterator<wchar_t> >, wchar_t>, wchar_t, boost::single_pass_traversal_tag, wchar_t, boost::use_default>' /storage/tmp/portbuild/usr/ports/devel/boost-1.32.0/work/boost_1_32_0/boost/iterator/iterator_adaptor.hpp:266: instantiated from `boost::iterator_adaptor<boost::archive::iterators::transform_width<boost::archive::iterators::binary_from_base64<boost::archive::iterators::remove_whitespace<boost::archive::iterators::istream_iterator<wchar_t> >, wchar_t>, 8, 6, wchar_t>, boost::archive::iterators::binary_from_base64<boost::archive::iterators::remove_whitespace<boost::archive::iterators::istream_iterator<wchar_t> >, wchar_t>, wchar_t, boost::single_pass_traversal_tag, wchar_t, boost::use_default>' /storage/tmp/portbuild/usr/ports/devel/boost-1.32.0/work/boost_1_32_0/boost/archive/iterators/transform_width.hpp:54: instantiated from `boost::archive::iterators::transform_width<boost::archive::iterators::binary_from_base64<boost::archive::iterators::remove_whitespace<boost::archive::iterators::istream_iterator<wchar_t> >, wchar_t>, 8, 6, wchar_t>' /storage/tmp/portbuild/usr/ports/devel/boost-1.32.0/work/boost_1_32_0/boost/archive/impl/basic_text_iprimitive.ipp:68: instantiated from `void boost::archive::basic_text_iprimitive<IStream>::load_binary(void*, size_t) [with IStream = std::wistream]' /storage/tmp/portbuild/usr/ports/devel/boost-1.32.0/work/boost_1_32_0/libs/serialization/build/../src/basic_text_wiprimitive.cpp:27: instantiated from here /storage/tmp/portbuild/usr/ports/devel/boost-1.32.0/work/boost_1_32_0/boost/archive/iterators/remove_whitespace.hpp:143: error: `boost::archive::iterators::filter_iterator<Predicate, Base>::m_predicate' has incomplete type /storage/tmp/portbuild/usr/ports/devel/boost-1.32.0/work/boost_1_32_0/boost/archive/iterators/remove_whitespace.hpp:78: error: declaration of `struct <unnamed>::remove_whitespace_predicate<wchar_t>' /storage/tmp/portbuild/usr/ports/devel/boost-1.32.0/work/boost_1_32_0/boost/archive/iterators/remove_whitespace.hpp: In member function `typename boost::iterator_adaptor<boost::archive::iterators::filter_iterator<Predicate, Base>, Base, boost::use_default, boost::single_pass_traversal_tag, boost::use_default, boost::use_default>::reference boost::archive::iterators::filter_iterator<Predicate, Base>::dereference_impl() [with Predicate = <unnamed>::remove_whitespace_predicate<wchar_t>, Base = boost::archive::iterators::istream_iterator<wchar_t>]': /storage/tmp/portbuild/usr/ports/devel/boost-1.32.0/work/boost_1_32_0/boost/archive/iterators/remove_whitespace.hpp:140: instantiated from `typename boost::iterator_adaptor<boost::archive::iterators::filter_iterator<Predicate, Base>, Base, boost::use_default, boost::single_pass_traversal_tag, boost::use_default, boost::use_default>::reference boost::archive::iterators::filter_iterator<Predicate, Base>::dereference() const [with Predicate = <unnamed>::remove_whitespace_predicate<wchar_t>, Base = boost::archive::iterators::istream_iterator<wchar_t>]' /storage/tmp/portbuild/usr/ports/devel/boost-1.32.0/work/boost_1_32_0/boost/iterator/iterator_facade.hpp:516: instantiated from `static typename Facade::reference boost::iterator_core_access::dereference(const Facade&) [with Facade = boost::archive::iterators::filter_iterator<<unnamed>::remove_whitespace_predicate<wchar_t>, boost::archive::iterators::istream_iterator<wchar_t> >]' /storage/tmp/portbuild/usr/ports/devel/boost-1.32.0/work/boost_1_32_0/boost/iterator/iterator_facade.hpp:634: instantiated from `Reference boost::iterator_facade<I, V, TC, R, D>::operator*() const [with Derived = boost::archive::iterators::filter_iterator<<unnamed>::remove_whitespace_predicate<wchar_t>, boost::archive::iterators::istream_iterator<wchar_t> >, Value = wchar_t, CategoryOrTraversal = boost::single_pass_traversal_tag, Reference = wchar_t, Difference = ptrdiff_t]' /storage/tmp/portbuild/usr/ports/devel/boost-1.32.0/work/boost_1_32_0/boost/iterator/transform_iterator.hpp:137: instantiated from `typename boost::detail::transform_iterator_base<UnaryFunction, Iterator, Reference, Value>::type::reference boost::transform_iterator<UnaryFunction, Iterator, Reference, Value>::dereference() const [with UnaryFunction = boost::archive::iterators::detail::to_6_bit<wchar_t>, Iterator = boost::archive::iterators::remove_whitespace<boost::archive::iterators::istream_iterator<wchar_t> >, Reference = boost::use_default, Value = boost::use_default]' /storage/tmp/portbuild/usr/ports/devel/boost-1.32.0/work/boost_1_32_0/boost/iterator/iterator_facade.hpp:516: instantiated from `static typename Facade::reference boost::iterator_core_access::dereference(const Facade&) [with Facade = boost::transform_iterator<boost::archive::iterators::detail::to_6_bit<wchar_t>, boost::archive::iterators::remove_whitespace<boost::archive::iterators::istream_iterator<wchar_t> >, boost::use_default, boost::use_default>]' /storage/tmp/portbuild/usr/ports/devel/boost-1.32.0/work/boost_1_32_0/boost/iterator/iterator_facade.hpp:634: instantiated from `Reference boost::iterator_facade<I, V, TC, R, D>::operator*() const [with Derived = boost::transform_iterator<boost::archive::iterators::detail::to_6_bit<wchar_t>, boost::archive::iterators::remove_whitespace<boost::archive::iterators::istream_iterator<wchar_t> >, boost::use_default, boost::use_default>, Value = wchar_t, CategoryOrTraversal = boost::single_pass_traversal_tag, Reference = wchar_t, Difference = ptrdiff_t]' /storage/tmp/portbuild/usr/ports/devel/boost-1.32.0/work/boost_1_32_0/boost/archive/iterators/transform_width.hpp:139: instantiated from `CharType boost::archive::iterators::transform_width<Base, BitsOut, BitsIn, CharType>::fill() [with Base = boost::archive::iterators::binary_from_base64<boost::archive::iterators::remove_whitespace<boost::archive::iterators::istream_iterator<wchar_t> >, wchar_t>, int BitsOut = 8, int BitsIn = 6, CharType = wchar_t]' /storage/tmp/portbuild/usr/ports/devel/boost-1.32.0/work/boost_1_32_0/boost/archive/iterators/transform_width.hpp:71: instantiated from `CharType boost::archive::iterators::transform_width<Base, BitsOut, BitsIn, CharType>::dereference_impl() [with Base = boost::archive::iterators::binary_from_base64<boost::archive::iterators::remove_whitespace<boost::archive::iterators::istream_iterator<wchar_t> >, wchar_t>, int BitsOut = 8, int BitsIn = 6, CharType = wchar_t]' /storage/tmp/portbuild/usr/ports/devel/boost-1.32.0/work/boost_1_32_0/boost/archive/iterators/transform_width.hpp:78: instantiated from `CharType boost::archive::iterators::transform_width<Base, BitsOut, BitsIn, CharType>::dereference() const [with Base = boost::archive::iterators::binary_from_base64<boost::archive::iterators::remove_whitespace<boost::archive::iterators::istream_iterator<wchar_t> >, wchar_t>, int BitsOut = 8, int BitsIn = 6, CharType = wchar_t]' /storage/tmp/portbuild/usr/ports/devel/boost-1.32.0/work/boost_1_32_0/boost/iterator/iterator_facade.hpp:516: instantiated from `static typename Facade::reference boost::iterator_core_access::dereference(const Facade&) [with Facade = boost::archive::iterators::transform_width<boost::archive::iterators::binary_from_base64<boost::archive::iterators::remove_whitespace<boost::archive::iterators::istream_iterator<wchar_t> >, wchar_t>, 8, 6, wchar_t>]' /storage/tmp/portbuild/usr/ports/devel/boost-1.32.0/work/boost_1_32_0/boost/iterator/iterator_facade.hpp:634: instantiated from `Reference boost::iterator_facade<I, V, TC, R, D>::operator*() const [with Derived = boost::archive::iterators::transform_width<boost::archive::iterators::binary_from_base64<boost::archive::iterators::remove_whitespace<boost::archive::iterators::istream_iterator<wchar_t> >, wchar_t>, 8, 6, wchar_t>, Value = wchar_t, CategoryOrTraversal = boost::single_pass_traversal_tag, Reference = wchar_t, Difference = ptrdiff_t]' /storage/tmp/portbuild/usr/ports/devel/boost-1.32.0/work/boost_1_32_0/boost/archive/impl/basic_text_iprimitive.ipp:79: instantiated from `void boost::archive::basic_text_iprimitive<IStream>::load_binary(void*, size_t) [with IStream = std::wistream]' /storage/tmp/portbuild/usr/ports/devel/boost-1.32.0/work/boost_1_32_0/libs/serialization/build/../src/basic_text_wiprimitive.cpp:27: instantiated from here /storage/tmp/portbuild/usr/ports/devel/boost-1.32.0/work/boost_1_32_0/boost/archive/iterators/remove_whitespace.hpp:132: error: `m_predicate' undeclared (first use this function) /storage/tmp/portbuild/usr/ports/devel/boost-1.32.0/work/boost_1_32_0/boost/archive/iterators/remove_whitespace.hpp:132: error: (Each undeclared identifier is reported only once for each function it appears in.) ...failed gcc-C++-action bin/boost/libs/serialization/build/libboost_wserialization.a/gcc/release/basic_text_wiprimitive.o... gcc-C++-action bin/boost/libs/serialization/build/libboost_wserialization.a/gcc/release/basic_text_woprimitive.o

2 1

[bug] xml_escape.hpp/xml_woarchive_impl.ipp cause compile errors with VC8.0 beta
by Marvin H. Sielenkemper 17 Nov '04

17 Nov '04

I tried to compile the current boost libraries with VC8.0 beta. It stopped and reported the following error: ---- SNIP ---- C:\Code\boost\boost\archive\iterators\xml_escape.hpp(47) : error C2440: 'type cast' : cannot convert from 'const wchar_t *' to 'std::_String_const_iterator<_Elem,_Traits,_Alloc>' with [ _Elem=wchar_t, _Traits=std::char_traits<wchar_t>, _Alloc=std::allocator<wchar_t> ] No constructor could take the source type, or constructor overload resolution was ambiguous C:\Code\boost\boost\archive\impl\xml_woarchive_impl.ipp(108) : see reference to function template instantiation 'boost::archive::iterators::xml_escape<Base>::xml_escape<const _Elem*>(T)' being compiled with [ Base=std::_String_const_iterator<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t>>, _Elem=wchar_t, T=const wchar_t * ] C:\Program Files\Microsoft Visual Studio 8\VC\include\xmemory(135) : while compiling class template member function 'void boost::archive::xml_woarchive_impl<Archive>::save(const std::wstring &)' with [ Archive=boost::archive::xml_woarchive ] C:\Code\boost\boost\archive\xml_woarchive.hpp(84) : see reference to class template instantiation 'boost::archive::xml_woarchive_impl<Archive>' being compiled with [ Archive=boost::archive::xml_woarchive ] ---- SNIP ---- The problem seems to be the more restrictive STL implementation which doesn't allow/use pointers as wstring iterators. The following change fixed the problem for me: Index: boost/archive/impl/xml_woarchive_impl.ipp =================================================================== RCS file: /cvsroot/boost/boost/boost/archive/impl/xml_woarchive_impl.ipp,v retrieving revision 1.5 diff -u -w -b -r1.5 xml_woarchive_impl.ipp --- boost/archive/impl/xml_woarchive_impl.ipp 7 Nov 2004 21:27:53 -0000 1.5 +++ boost/archive/impl/xml_woarchive_impl.ipp 16 Nov 2004 08:58:47 -0000 @@ -105,8 +105,8 @@ void xml_woarchive_impl<Archive>::save(const std::wstring & ws){ typedef iterators::xml_escape<std::wstring::const_iterator> xmbtows; std::copy( - xmbtows(BOOST_MAKE_PFTO_WRAPPER(ws.data())), - xmbtows(BOOST_MAKE_PFTO_WRAPPER(ws.data() + ws.size())), + xmbtows(BOOST_MAKE_PFTO_WRAPPER(ws.begin())), + xmbtows(BOOST_MAKE_PFTO_WRAPPER(ws.end())), boost::archive::iterators::ostream_iterator<wchar_t>(os) ); } Regards Marvin H. Sielenkemper, PROVISIO GmbH

2 1

GUI library - something to think about
by Maciej Sobczak 17 Nov '04

17 Nov '04

Hi, Considering the fact that some of the Boosters work on the GUI library, I would like to throw something to the mix: http://cpptk.sourceforge.net/ This library uses some template techniques, especially in those places where GUI integrates with C++ (callbacks, variable binding, etc.). As a result, the library is highly generic, uses some of the Boost, should be compatible the rest of Boost and may benefit from further "boostification". Anyway - please note that the concepts used in this library (well, and in Tcl/Tk which is used as an underlying engine) are very different from what normally comes to mind when we think "GUI programming". In particular, this library is not object-based and does not use RAII at all (apart from a couple of places which are not related to GUI), but somehow still manages to "keep the shape". It may help to put some things in perspective. Your comments are welcome, -- Maciej Sobczak : http://www.msobczak.com/ Programming : http://www.msobczak.com/prog/

4 8

Re: [Boost-testing] Re: Re: Intel 7.1-linux tarball results
by Aleksey Gurtovoy 17 Nov '04

17 Nov '04

Robert Ramey writes: > I was considering the situation whereby a particular compiler/configuration > fails all or most of the test because of some issue in the test computer's > build configurtation. Which is what we had. > Since the "release package" just points to the test > results, they can be updated at anytime after the release. Of course. > So I don't see > that this test problem should hold up the release. Oh, definitely not. > > That's all I meant to say. OK, thanks for the clarification. -- Aleksey Gurtovoy MetaCommunications Engineering

1 0

[logging] file_appender and rolling_file_appender
by Caleb Epstein 17 Nov '04

17 Nov '04

Attached please find an implementation of two functors for John Torjo's boost::log library which I have called "file_appender" and "rolling_file_appender". Documentation is scant, so I'll try to describe them here. The "file_appender" is meant as a more-or-less drop-in replacement for John's write_to_file functor, except that it keeps the output file open instead of re-opening it for each write. "rolling_file_appender" derives from file_appender and allows the user to specify a maximum file size and a number of files to keep. After each write, it checks if the file is >= <max_size> and, if so, calls the rollover method. This method renames existing logfiles using a numbered suffix, keeping at most <num_files> backups. If <max_size> is specified as 0, rolling_file_appender behaves the same way as file_appender. If <num_files> is 0, there will be only one logfile which will be truncated every time it reaches <max_size>. Both of these objects support a "filename_factory" function which the caller can use to generate unique or date-stamped (or ...) filenames from a user-supplied filename "prototype". I've included a factory function called "strftime_filename_factory" which will take the filename prototype and run it through std::strftime. The rolling_file_appender uses boost::filesystem to handle file remove/rename operations. Feedback is welcome. -- Caleb Epstein caleb dot epstein at gmail dot com

2 2

Re: [Boost-testing] Re: Intel 7.1-linux tarball results
by Aleksey Gurtovoy 17 Nov '04

17 Nov '04

Robert Ramey writes: > Isn't this a link from the 1.32 release package. I'm sorry, but the question doesn't make sense to me. What _is_ "a link from the 1.32 release package"? For that matter, what's "1.32 release package"? We didn't release yet; we only have "final draft tarballs", and the link I posted points to the reports for those. > Can't the link just be left and point to the updated results? Please be more specific: which link? left where? > In fact, isn't possible that a newer version of a compiler (e.g. gcc > 3.4.3?) comes out and we want to re-run show updated test results > eventhough the 1.32 package is frozen. OK, I understand this one :). Yes, it's surely possible, and we can easily do that. > I don't see this has having anything to do with release drafts. Depends what "this" is. The results at http://www.meta-comm.com/engineering/boost-regression/developer/index.html most definitely report the status of the draft tarballs. -- Aleksey Gurtovoy MetaCommunications Engineering

1 0