- Boost - lists.boost.org

Boost 1.36.0 release notes missing Circular Buffer changes
by Dean Michael Berris 01 Sep '08

01 Sep '08

Hi, I took a look at the code in trunk and in 1.36.0, and I notice the release notes don't mention the change in behavior of Boost.Circular_Buffer WRT the default constructor. Should we add: Circular Buffer: * default constructor now doesn't allocate memory, and sets the capacity of the buffer to 0 To the 1.36 release notes? -- Dean Michael C. Berris Software Engineer, Friendster, Inc.

1 0

Re: [boost] [review wizard/admin] Not-yet-committed, but accepted libraries
by JOAQUIN M. LOPEZ MUÑOZ 31 Aug '08

31 Aug '08

________________________________________ De: boost-bounces(a)lists.boost.org [boost-bounces(a)lists.boost.org] En nombre de Ronald Garcia [garcia(a)cs.indiana.edu] Enviado el: sábado, 30 de agosto de 2008 18:56 Para: Boost mailing list CC: John R. Phillips Asunto: [boost] [review wizard/admin] Not-yet-committed, but accepted libraries > > A few libraries have been reviewed and accepted into boost, but have > not yet appeared in SVN as far as I can tell. Could some light be > shed on the status of the following libraries? Apologies if I have > simply overlooked any of them: > > Flyweight (Joaquín Mª López Muñoz) I'm glad you ask :) The review raised some important issues that only during this summer I've had the time to attack. I've got everything ready for a post-review version during the following week. My target release is Boost 1.38. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

[pointer container] Wishlist: Iterating through nullable vectors and compiler firewalls
by Andrew Hain 31 Aug '08

31 Aug '08

Two quick queries. Would it make sense to have the iterator increment and decrement operators and begin() member function of ptr_vector< nullable<> > skip missing records so that applications have no need to check? What is stopping pointer container classes from being used with opaque types as a compilation firewall? -- Andrew Hain Oasys http://www.oasys-software.com

2 2

[log] Yet more questions for Andrey: formatting severity
by Igor Nazarenko 31 Aug '08

31 Aug '08

By default, severity is printed as integer. What's the easiest way to print the corresponding string (e.g. "info" for severity 0, "warn" for severity 1, and so on)? I tried defining operator<< for my severity enum, but attr<severity_level> doesn't work; that is, the output operator doesn't get invoked (I assume because attribute "Severity" is internally of type "int" and not of my enum type). Thanks a lot! Igor

3 4

Re: [boost] [Boost-users] [filesystem][xpressive] Hotfix patches available for 1.36.0
by Mat Marcus 31 Aug '08

31 Aug '08

On Fri, Aug 29, 2008 at 1:36 PM, Eric Niebler <eric(a)boostpro.com> wrote: > Michael Marcin wrote: >> >> If the fixes are not critical enough to justify making a point release >> than they should wait until the next release. > > So you're against hotfixes. <shrug> I would say, take the hotfix if you are > experiencing the problem addressed by the hotfix. Otherwise, wait for the > next release. > > -- > Eric Niebler > BoostPro Computing > http://www.boostpro.com For some of us the answer is not <shrug>. Are hotfixes really the way forward? Not to pick on filesystem, threads or xpressive, but hotfixes are a bit difficult to manage in a coporate environment. It's hard enough to get boost accepted/updated without having to defend against people who argue that it's too risky to use boost due to "inadequate quality control" e.g. "boost 1.35.0 didn't work out of the box (windows thread bugs, filesystem compilation errors, etc.), boost 1.36.0 doesn't work out of the box, and there are no dot-releases planned". It really helps if there is a perception of stable, high quality, official, numbered releases. - Mat

5 8

[review wizard/admin] Not-yet-committed, but accepted libraries
by Ronald Garcia 31 Aug '08

31 Aug '08

A few libraries have been reviewed and accepted into boost, but have not yet appeared in SVN as far as I can tell. Could some light be shed on the status of the following libraries? Apologies if I have simply overlooked any of them: Flyweight (Joaquín Mª López Muñoz) Binary Int (Matt Calabrese) Floating Point Utilities (Johan Råde) Factory (Tobias Schwinger) Forward (Tobias Schwinger) Scope Exit (Alexander Nasonov) Time Series (Eric Niebler) Property Tree (Marcin Kalicinski) -- No documentation in SVN Any information on the whereabouts of these libraries would be greatly appreciated. Cheers, ron

2 1

[vault] or maybe sandbox?
by Robert Jones 30 Aug '08

30 Aug '08

I am unclear of what the vault contains, and of its relation to the sandbox. The sandbox is a versioned repository, whereas the the vault appears not to be. What is the workflow here, if there is one? By what path do libraries arrive at Boost proper (ie. part of some release), and where in the process are the review points? Thanks, Rob.

6 7

Opinion and help with implementing futures
by Bram Neijt 30 Aug '08

30 Aug '08

Dear reader, I've been wanting to implement a future in C++ for some time, and combined some code to come up with the attached. The idea is that the future is a function wrapper around a function call which will call the function in a second thread upon creation. Then at a later moment, the future can yield the return value of the wrapped function (or block until this result is know). I'm happy with the result I got so far. It's a very rough draft, and I would like your help to clean up some details: - I would like to have the Future wrapper work with the boost::function< int (argument, argument)> syntax, but I can't figure out how to get the return type from that syntax to allow for the return value to be defined (the d_result member). - What would be the best way to handle function arguments? Binding all the parameters before passing the resulting bound function object seems like the solution, but is it really the best solution? And last but not least: has this already been done and what is the general opinion within the boost community on having a class like this? Greetings, Bram Neijt Attached are two files, one is the Future class and the second is a test program showing it's general functioning. The output of running the test program should show: Creating future Future thread working Main waiting for 3 seconds Future thread working Future thread working Calling upon future to return Future thread working Future thread working Future thread working Future thread working Future thread working Future thread working Future returned: 9

2 1

Proto<markus>::review()(proto::accept);
by Markus Werle 30 Aug '08

30 Aug '08

Hi! I think Proto should be accepted for inclusion into boost. A general purpose Expression Template library is hard to write. Proto is the most sophisticated and closest approach to perfection available today. - What is your evaluation of the design? Proto is well-designed in many aspects, though I got the impression that some beauty and purity was sacrificed on the altar of compile-time efficiency, but that's OK. (And yes, I hate BOOST_PP_MACROS!) Proto catches the most important issues of a general purpose expression template library, I especially like the way how expression storage and expression evaluation is strictly separated and the way I can add my own functionality. Proto covers the most important aspects of an ET library, sometimes in very elegant ways. Proto's design adressed compile time issues. That's a value in itself. OTOH: Transforms leave me with mixed feelings. I am not very good at catching ideas without good step-by-step documentation and I got messed up with grammars vs. transforms. This part of proto is new and it looks like a candidate for rework. I'd like to have an extra review in half a year only on the grammar and transform part of proto (*)[comment below]. That's a DSEL all by itself and I guess that interface may have some pitfalls. Larry Evans has worked that out in detail. There may be issues in the naming convention used there, e.g. I am unsure whether and_ is the appropriate name for what it does. - What is your evaluation of the implementation? None. Not enough time. Steven Watanabe did it for us all. Code looks clean. For my taste too many levels of nested namespaces, but that's the boost trend at the moment. I may appreciate this style later in my life, once I understand why you need it. - What is your evaluation of the documentation? The quality varies from excellent to hard to read. I agree with all what David writes about the docs. There is some potential for improvement, but that should not hinder the inclusion into boost: we need a community effort here since Eric's skill level probably is way too high in order to have some feeling for why the unaware might have problems with parts of the doc. The teacher should be one step ahead, not too far ahead. - What is your evaluation of the potential usefulness of the library? We really, really need this. Better today than tomorrow. The whole world is waiting for this to come. And C++ again rocks - Did you try to use the library? A couple of hours, but only for some of the examples. - With what compiler? VC8, Intel 10.1 - Did you have any problems? Nope. Eric-faster-than-lightning fixed those before I could run into them ... - How much effort did you put into your evaluation? I read the docs three times and worked through some details. I investigated the type representation of expressions by reading purposely generated compiler error messages and tried to figure out the design. - Are you knowledgeable about the problem domain? I had several attempts to write some kind of ET library on my own, some parts published at daixtrose.sourceforge.net. I also planned to write something like proto myself, but due to lack of time and programming skills I lost the race before it began. (rm -rf /work/markus/ideas/expresion_templates_revisited) Eric, thanks for the time saved by the publication of proto. Markus P.S. This review is short, sorry. I had some unexpected tasks to do the last week which hindered further investigation. I'll put some more effort into this in the future. (*) I'd like to have an extra review on _every_ boost library in a 2-year-cycle. By this boost::multi_array could probably be forced to model assignable like any other STL container and ::_1 from boost::bind will move into its own namespace - just to mention my two favourite change requests ...

3 3

Re: [boost] [filesystem][xpressive] Hotfix patches available for 1.36.0
by Eric Niebler 29 Aug '08

29 Aug '08

Michael Marcin wrote: > If the > fixes are not critical enough to justify making a point release than > they should wait until the next release. So you're against hotfixes. <shrug> I would say, take the hotfix if you are experiencing the problem addressed by the hotfix. Otherwise, wait for the next release. -- Eric Niebler BoostPro Computing http://www.boostpro.com

1 0