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

Futures revisited
by Slawomir Lisznianski 08 Mar '04

08 Mar '04

Hello, During discussions on possible extensions to Boost.Threads, concept of Futures came up rather frequently. Below, I’d like to introduce a particular implementation available at www.rhapsodia.org of which requirements were defined as follows: 1. Provide means to register exception types with a "Future Registry". Rationale: I find it imperative that users should not have to define a list of exception types on each invocation yielding a Future object. Instead, provide the ability to register exception types with a Future Registry and bundle it with Future objects. I feel that compile time registration should be sufficient. 2. Work under the assumption that asynchronous invocations returning Futures and system threads are not coupled. In particular, Futures implementation should not relay on joining with a particular thread to perform synchronization for returning results. Rationale: Although most prevalent, the technique of joining with a particular thread to synchronize on returning result is too limiting. It implies that each task be run on a dedicated thread, specially created to handle it and destroyed to meet with a caller using a Future. Although this approach may be adequate under certain conditions, it generally tends to be expensive on system resources and disorganizes the application. For example, it’s impossible to control the number of concurrently running threads. It may also perform poorly if executed code happens to run shortly as the overhead of creating a thread and cleaning up after it may be significant. More robust approach is to use a queue and a thread pool for running tasks. This adds complexity on the synchronization side, as we can no longer rely on a lifetime of a thread to join with Future’s result. 3. Ability to utilize Futures with arbitrary code without explicit support for them. Rationale: For implementation to be widely adopted, it should be possible to turn just about any function call into a Future-armored asynchronous invocation. No explicit thread synchronization primitives should be used as well. 4. Implement using existing Boost.Threads facilities only. Rationale: Boost.Threads library provides enough support to implement Futures paradigm that meets requirements listed here. 5. STL and Boost compatible. For example, storing Futures in an STL container. Be strongly typed. Futures implementation and usage patterns must naturally coexist with STL and Boost code. Additionally, compile-time type validation is key to safer code. Attached is a sample file from Rhapsodia library showing the use of Futures. Regareds, Slawomir Lisznianski [ www.rhapsodia.org ]

2 1

Blipping back on the radar... hopefully.
by Hubert Holin 08 Mar '04

08 Mar '04

Somewhere in the E.U., le 08/03/2004 Bonjour After what seems like an eternity, I may perhaps be able to get back to work on the math libraries I contributed here. For the last year or so, I believe, I could not even find the time to lurk in the newsgroup, that following about a year in which I barely had time to just lurk. I also fear mail sent thru my bigfoot redirector may have been chewn up befor I got it (or else nobody compalined about these libraries ;-) ). I know I have a lot off "Cat Soup" to do (eat :-) ?), and to make things more interesting, I may have to move to Xcode (gcc) as a primary platform rather than CodeWarrior (I may no longer be able to personnaly afford the updates, and MetroWerks has made it impossible for me to update at work by requiring they be purchased thru the internet... and that's corporately impossible where I work). As I had locally incorporated patches which I fear were never uploaded, some to squash incompatibilities, I apologize for the inconvenience. Not all the fires are out, so to speak, but most are now somewhat under control. I should have three weeks with a modicum of time to set a few things straight, at least. Merci Hubert Holin

2 1

std_min/std_max reference return value is problematic with boost::interval
by Michael Stevens 08 Mar '04

08 Mar '04

Eric, The recent changes to the new std_min/std_max caused some unexpected problems in uBLAS. I have narrowed them down to support for boost::numeric::interval in uBLAS. This is picked up by ublas/libs/test7. This test is however not at present part of the regression run. The new std_max (or std_min) is implemented by returning a constant reference to the return value of std::max. This should be OK as std::max similarly returns a const reference to one of its const reference parameters. For gcc this causes some problems when the type is a boost::numeric::interval. The test case is very simple. #include <boost/numeric/interval.hpp> #include <boost/minmax.hpp> int main() { boost::numeric::interval<float> a,b,c; c = boost::std_max(a, a); } gcc (2.95.3 and 3.3.1) is only warning "returning reference to temporary". I am surprised this doesn't show up in more cases. Why gcc thinks it needs a temporary here is beyond me Michael -- ___________________________________ Michael Stevens Systems Engineering ___________________________________

3 3

RE: [boost] Win32 regressions
by Rozental, Gennadiy 08 Mar '04

08 Mar '04

> Test test_tools_test - Regressions on VC++ 6.0 and 7.0. I did not make any changes lately. But from error messages it seems like has something to do with boost::bind. Peter could you please take a look. Gennadiy.

2 2

First lambda
by David Abrahams 08 Mar '04

08 Mar '04

I just tried using the lambda library for the first time. Here's what came out of it, after some struggle: #include <boost/lambda/lambda.hpp> #include <vector> #include <numeric> using namespace boost::lambda; struct X { X() : count(1) {} unsigned long count; }; std::vector<X> xs(10); unsigned long n = std::accumulate( xs.begin(), xs.end(), 0UL, _1 + (&_2) ->* &X::count); This program adds up the "count" members in a vector of X objects. Now, no offense intended, but this is nasty. There's just too much extra syntax required for something so simple, plus you have to make the type into a pointer just so you can dereference it Before I realized I needed to take the address of _2, I had: unsigned long n = std::accumulate( xs.begin(), xs.end(), 0UL, _1 + _2 ->* &X::count); which is only slightly better (but incorrect). I realize that I can use bind: unsigned long n = std::accumulate( xs.begin(), xs.end(), 0UL, _1 + bind(&X::count,_2)); but that's slightly counter-intuitive since the order of the target object and its member pointer are reversed. It'd be nice to allow something like: unsigned long n = std::accumulate( xs.begin(), xs.end(), 0UL, _1 + _2.at(&X::count)); while if _2 were to refer to a pointer type, we could say: unsigned long n = std::accumulate( xs.begin(), xs.end(), 0UL, _1 + _2->at(&X::count)); -- Dave Abrahams Boost Consulting www.boost-consulting.com

6 11

shared_ptr reference count
by John McGinty 08 Mar '04

08 Mar '04

Is there any reason why shared_ptr does not use atomic_count (using InterlockedIncrement, InterlockedDecrement) for the reference count? The lightweight mutex used to protect the count in the current implementation is a spin lock that sleeps when contended. Using atomic count would offer performance improvements in both the uncontended and contended cases. Regards, John McGinty

2 1

Re: [boost]Re: Re: [serialization] non-conformance incollection_load_imp.hpp
by JOAQUIN LOPEZ MU?Z 08 Mar '04

08 Mar '04

----- Mensaje original ----- De: Aleksey Gurtovoy <agurtovoy(a)meta-comm.com> Fecha: Sábado, Marzo 6, 2004 8:17 pm Asunto: Re: [boost]Re: Re: [serialization] non-conformance incollection_load_imp.hpp > Robert Ramey wrote: > > This exchange illustrates the problem rather nicely. Its not > clear > > to me from the name "aligned_storage" that its meant to do the > same > > job as "stack_allocate" and in fact is easily confused with > other > > boost functions. I've been able to find no documentation nor > test > > nor other information. The only place its used is in variant.hpp but > > its not mentioned in the documentation of that either. There is > no > > statement in the header itself as to what it does and the code > is > > sufficiently non-trivial that it's not obvious what its supposed > to > > do. The fact that it has a parameter than stack_allocate > doesn't > > need also suggests that it's intended purpose is different from > that > > of stack_allocate. > > It doesn't, see aligned_storage's "Rationale" subsection in > http://tinyurl.com/39asx. > I don't quite get what you mean. So, does boost::aligned_storage serve as a replacement for stack_allocate? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

[Boost-bugs] [ boost-Bugs-911758 ] Silent random_number_generator failure.
by SourceForge.net 08 Mar '04

08 Mar '04

Bugs item #911758, was opened at 2004-03-08 04:56 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=911758&group_i… Category: random Group: None Status: Open Resolution: None Priority: 5 Submitted By: Cromwell Enage (expaler) Assigned to: Jens Maurer (jmaurer) Summary: Silent random_number_generator failure. Initial Comment: The test program attached to this message fails silently when attempting to execute line 54. (The test does not return, but no exceptions or errors are thrown, either.) The culprit is in <boost/random/random_number_generator.hpp>, line 52: the variate_generator's first template parameter is base_type. Changing it to base_type& will squash the bug. Cromwell Enage ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=911758&group_i… ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0

RE: [boost] serialization library #17
by Hurd, Matthew 08 Mar '04

08 Mar '04

> On Behalf Of Robert Ramey > Subject: [boost] serialization library #17 > > > Robert Ramey Small doc inconsistency with libs/serialization/doc/implementation.html#othercompilerissues Intel 8.0 appears in the left hand side frame but there is no relevant section. Regards, Matt Hurd. IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

1 0

Re: [boost] Re: [indexed_set] volunteers wanted for testing
by JOAQUIN LOPEZ MU?Z 08 Mar '04

08 Mar '04

----- Mensaje original ----- De: Giovanni Bajo <giovannibajo(a)libero.it> Fecha: Viernes, Marzo 5, 2004 4:30 pm Asunto: [boost] Re: [indexed_set] volunteers wanted for testing > Testing on GCC 3.4 uncovers an issue. > > ../../../boost/indexed_set/index.hpp:155: error: there are no > arguments to > `final' that depend on a template parameter, so a declaration of > `final' must > be available > This happens also on all the similar lines in the same class: 161, > 177, 178, > 179. All final* members seem to be inherited from a dependent > base, so they > need to be qualified with "this->" in front of them. The same also > happens in > index_set.hpp, line 133, 459. sequenced_index.hpp: 134, 157, 175, > 176, 177, > 576, 580. > I think there are more occurrence of this but maybe they are not > excercised by > the testes. You're very right. I'll add the missing this->'s. Thanx for the tip. > > test_list_ops.cpp generates an ICE which I already submitted for > analysys. Is there a link in the GCC database that I can track? > All the other tests compile and run succesfully (after the above > fixes).-- > Giovanni Bajo > OK, thank you again. Best, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1