- Boost - lists.preview.boost.org

[progress] progress_timer inserts \n and std::endl
by Caleb Epstein 18 Nov '04

18 Nov '04

Is there any that boost::progress_timer to inserts *both* \n and std::endl to the output stream when it is destroyed? I think it should just do the std::endl. -- Caleb Epstein caleb dot epstein at gmail dot com

1 0

bug in bgl?
by Eyal Farago 18 Nov '04

18 Nov '04

I'm trying to use the edge(u, v, g) on a revese_grap h, I get a stack overflow after the programs enters an infinite loop(or actually infinite recursive call). once looking at the selected overload I could see a very strait-forward correction: template <class BidirectionalGraph, class GRef> inline std::pair<typename BidirectionalGraph::edge_descriptor, bool> edge(const typename BidirectionalGraph::vertex_descriptor u, const typename BidirectionalGraph::vertex_descriptor v, const reverse_graph<BidirectionalGraph,GRef>& g) { return edge(v, u, g); //this should be: edge(v, u, g.mg) } the next call to edg(...) shoul pass the adapted grap. eyal.

2 1

RE: [boost] Re: [Review] Named parameters library
by Stefan Seefeld 18 Nov '04

18 Nov '04

> From: Doug Gregor [mailto:dgregor@cs.indiana.edu] > Since I've been researching in this area for several years... > > Dave is correct: no compiler out there is going to optimize this, > because the side effects are killer. It is possible to analyze that > behavior and perform the optimization Thorsten is describing, but > > (1) There are better ways than looking at it from the memory > subsystem/pointer magic angle > (2) This is very much an open research area; don't > expect this from a > research compiler for at least 2 years. > (3) This is very much an open research area; don't > expect this from a > commercial compiler for at least 10 years. > > Copy elision and the RVO are all we have. We can't rely on anything > more than that. out of curiosity: what about the LD_PRELOAD trick that's used on ELF systems to replace symbols at startup ? It's notably used by some tools to swap in special versions of operator new/delete to analyze memory management without the need to recompile anything. Is there any way for a compiler to know that some calls can be fully evaluated at compile-time ? Thanks, Stefan

2 1

[review] Formal review of the Smart Container library ends today
by Pavol Droba 18 Nov '04

18 Nov '04

Hi All, Formal review of the Smart Container library ends today. I'd like to thank you all, that participated and offered opinions about this library. I will now take my time as the review manager to sumarize the conclusion for the final verdict. Best regards, Pavol PS: There is still a little time to submit a review if somebody is willing to do so.

2 2

index.htm: gratuitous HTML reformatting
by David Abrahams 18 Nov '04

18 Nov '04

It appears that recent changes to our index page changed all tags on the index page to uppercase. From cvs annotate: ... 1.186 (rogeeff 28-Oct-04): </P> 1.186 (rogeeff 28-Oct-04): </TD> 1.186 (rogeeff 28-Oct-04): </TR> 1.186 (rogeeff 28-Oct-04): </TABLE> 1.186 (rogeeff 28-Oct-04): <TABLE> 1.186 (rogeeff 28-Oct-04): <TR> 1.186 (rogeeff 28-Oct-04): <TD> </TD> 1.186 (rogeeff 28-Oct-04): <TD> 1.186 (rogeeff 28-Oct-04): <P>The Boost.. ... Every line with a tag in it was last changed by "rogeeff". These kinds of sweeping changes are really bad for any source control system, especially when they're entirely unneccessary. In this case it's complicating the process of merging changes into the release branch. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com

5 6

[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