November 2004 - Boost - lists.preview.boost.org

[More IO] Review Status?
by Jonathan Turkanis 18 Nov '04

18 Nov '04

Dear Daryle or Tom, I can see from the most recent review schedule that the More IO library has been rejected, but I have not seen a review result posted. I'm interested to know the rationale for the rejection and future plans for More IO, since I would like to add the Iostreams library to CVS as soon as possible and several of the open issues depend on the status of More IO. For example, during the review of both libraries there was definite support for some sort of null_sink/null_buf. I'd like to know if I should go ahead and add these classes to the iostreams library, or whether I should wait for Daryle to produce a revised version of More IO. Certainly I can put off some of there decisions until later, but I'd rather take a few days and prepare a revision of the Iostreams library all at once. Best Regards, Jonathan

2 1

Fwd: FW: [bug] xml_escape.hpp/xml_woarchive_impl.ipp causecompileerrors with VC8.0 beta
by Marvin Sielenkemper 18 Nov '04

18 Nov '04

"Robert Ramey" <ramey(a)rrsd.com> wrote in message news:<cng1lp$2jk$1(a)sea.gmane.org>... > Very good call - precisely the correct fix! Thank you. > I was never able to see any test results from VC 8.0 since the library > failed to build because of some issue with VC 8.0 and spirit 1.8. I > believe this issue has since been resolved but since then testing > hasn't been done pending final release of 1.32. Yes, this issue is resolved. I posted a fix some time ago directly at sourceforge. :-) > I'm wondering if this is the only issue in relation to VC 8.0? Were > you able to run all the tests and build all the libraries? If so what > kind of results did you get? The library pass 100% with VC 7.1 (no > suprise because that's what I use here). Actually, up to now I only compiled the libraries. The current CVS head (with fixes) compiles 100% with VC 7.1 and VC 8.0. I'll try to run the regression tests. > I would hope that accommodating VC 8.0 would entail only the most > minimal adjustments. Any insight you can give me here would be > interesting. No problems here. The compiler is a little bit closer to ISO. > Also how does one aquire his own copy of vc 8.0 beta - is it worth it?. Try http://lab.msdn.microsoft.com/vs2005/ ... its free ... It does refactoring - but sadly not for C++. It comes with managed C++ - really nice. It contains .Net 2.0 - C# with templates. Sometimes it reminds me of Eclipse. We're currently using it to develop a filesystem filter driver for Win2k/XP. The driver is C++, the tests are partially (managed) C++ and partially C#. Works nicely ... > Personally I hate dealing with microsoft betas. I give the feed back > on problems and the release version has all the same issues. We did report a bug in the new STL (the one that causes boost to break ;-) and it was acknowledged and fixed ... -- MfG Marvin H. Sielenkemper, PROVISIO GmbH

1 0

How bugs fixing policy works in boost?
by Vyacheslav E. Andrejev 18 Nov '04

18 Nov '04

Some time ago I've posted some bugs in date_time, and format libraries. There is no answer, there is no fix, there is no any reaction at all. The only two authors reacts and have applied suggested fixes: Hartmut Kaiser has fixed problem with select_p in spirit and Robert Ramey has partially fixed problem with ADL and vc7.1 in serialization. All others bugs are unanswered. But release is going to be issued. Why this? What is the bugs policy? Release is going to contain known bugs? -- Vyacheslav E. Andrejev System Architect, Excelsior, LLC

6 11

base_from_member suggestions
by Joe Gottman 18 Nov '04

18 Nov '04

I used base_from_member today for the first time. It got me out of a sticky situation, but I think it could use a few modifications. Since it is designed to be used as a base class but does not have any virtual functions, the copy constructor, assignment operator, and destructor should all be protected. Joe Gottman

3 4

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

18 Nov '04

Frank Laub: >Vesa Karvonen wrote: > > Lazy Metaprogramming Library [...] >This is awesome! Thanks! I noticed that you replied to my original post. Have you fetched the latest version of the library from the files section? (See later in this message.) >I have been working on something very similar to this; looks like I'm >not alone in the lazy evaluation idea. I'm not surprised. It seems that similar ideas have occured to several people over the years. >My library goes a bit farther than proof-of-concept by actually trying >to use it in a real-world case. I'm currently looking for an interesting real world problem to solve as an example of using Lazy TMP. If you (who is reading this e-mail) have an idea of a good example, I'm all ears! >I have run into a significant problem however: the template nesting >limitation. I have not yet seen a way to make Lazy TMP scale >for any real problems. Yes, nesting can be a problem. The problem can be alleviated by using optimizations guided by techniques that are called strictness analysis. My proof-of-concept library contains such optimizations. >[...] nth is a fairly trival function: > >#define FUN(n, _name) \ > template<BOOST_PP_ENUM_PARAMS(n, typename _p) > \ > struct _name { >#define BEGIN typedef typename >#define END ::eval eval; }; > >// _p0 = index >// _p1 = {list} >FUN(2, nth) >BEGIN > if_< _p1, > if_< equals< _p0, I<0> >, > car< _p1 >, > nth< > sub< L2< _p0, I<1> > >, > cdr< _p1 > > > > >, > nil > > >END > >Yes, the above code is actually C++! The magic of lazy evaulation >lets us write such elegant stuff. Here is an unoptimized implementation of the same metafunction (it's called AT) from my library. No macros are involved here. template<class i, class l> struct AT : HEAD<DROP<i, l> > {}; template<class n, class l> struct DROP : IF<IS_0<n>, l, DROP<PRED<n>, TAIL<l> > > {}; The DROP-metafunction, in particular, can be optimized using strictness analysis. Here is how one might do it: template<class n, class l> struct DROP : DROP<INT<n::value>, typename l::eval>::eval {}; template<long n, class h, class t> struct DROP<INT<n>, CONS<h, t> > : DROP<INT<n-1>, typename t::eval>::eval {}; template<class h, class t> struct DROP<ZERO, CONS<h, t> > : CONS<h, t> {}; template<class n> struct DROP<n, NIL> : NIL {}; [[Actually, the above optimized implementation is slightly too strict. It shouldn't matter a lot in practise, though. It is also possible to avoid the unwarranted strictness. Can you spot the invalid invocation?]] >The thing is, even with this little example, the compiler will have to >slog though many many nested types (espically brutal is the car and >cdr). This usually results in the compiler running out of memory >pretty quickly for lists that are only 10 elements. Yes. This issue (the buildup of complex unevaluated expressions) is explained in detail using "equational reasoning" in the factorial function example that you can find in the library: http://groups.yahoo.com/group/boost/files/LazyMPL/ See the file `lazy_mpl/example/example_fact.cpp'. >I've looked at your approach and it looks promising, but I'm not sure >it will aleviate this problem. Is there something special about >inheritance that makes the compiler happier in that it doesn't eat up >its memory as fast? The solution is not inheritance. Inheritance doesn't necessarily reduce memory consumption. Inheritance is only used to reduce the notational burden. Use of inheritance eliminates the need for the kind of macros you seem to be using. The key to making Lazy TMP viable (or at least approximately as viable as Strict TMP) is to optimize lazy metafunctions using strictness analysis when necessary. This is explained to some extent in the factorial example and used throughout the library. (I think the technique needs further explanations.) A library of optimized higher-order functions should make Lazy TMP quite useful to the casual template metaprogrammer. >I'm starting to think that C++ was never really meant to do this kind >of thing, Well, it wasn't. You can take it as an axiom. >and therefore is a lost cause? >BTW, I'm cleaning up my library for others to look at, but I can send >it to you in its current state if you don't mind the mess. I can wait for the revised edition. (I'm too busy at the moment working on several other things.) >It works for VC7.1 and (believe it or not) EVC4. I'm sure with a bit >of tweaking it will work fine on g++; the hard part was working around >partial and full specializations not working right on evc4. Been there... Novadays I have very little sympathy for broken compilers. It has been about 6 years since the C++ standard was ratified. I personally find it quite revealing that most compilers still don't implement the standard. I have very little interest to spend my life working around compiler bugs. -Vesa Karvonen _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

2 1

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