- Boost - lists.boost.org

Updates to the Review Schedule/Upcoming Reviews
by Jeff Garland 09 Mar '04

09 Mar '04

I've recently checked in a new version of the review schedule. So you don't have to go to CVS and look, here is the set up upcoming reviews: Library Author Review Mgr Dates Circular Buffer Jan Gaspar Pavel Vozenilek 2004 Mar 5-15 Indexed Set Joaquín M López Muñoz Pavel Vozenilek 2004 Mar 20-30 Assignment Thorsten Ottosen Tom Brinkman 2004 Apr 1-11 Serialization Robert Ramey Jeff Garland 2004 Apr 13-20 Container Traits Thorsten Ottosen Hartmut Kaiser 2004 Apr 28-May 7 Tribool Douglas Gregor - - More IO Daryle Walker - - Iostreams Jonathan Turkanis - - Output Formatters Reece Dunn - - Pointer Containers Thorsten Ottosen - - Named Params David Abrahams & Daniel Wallin - - Wave Hartmut Kaiser - -

3 3

[Boost-bugs] [ boost-Bugs-912368 ] boost::tokenizer implicit typename
by SourceForge.net 08 Mar '04

08 Mar '04

Bugs item #912368, was opened at 2004-03-09 00:46 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=912368&group_i… Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Brian Ravnsgaard Riis (ravnsgaard) Assigned to: Nobody/Anonymous (nobody) Summary: boost::tokenizer implicit typename Initial Comment: boost::tokenizer gives warnings on gcc 3.3.1 (MinGW build) about implicit typenames in two typedefs in offset_separator::operator() and char_separator::operator(). Both typedefs look like: typedef tokenizer_detail::assign_or_plus_equal< tokenizer_detail::get_iterator_category< InputIterator>::iterator_category> assigner; I changed them to: typedef tokenizer_detail::assign_or_plus_equal< typename tokenizer_detail::get_iterator_category< InputIterator>::iterator_category> assigner; I.e. I added a "typename" keyword inside the typedef. g++ warned that "Implicit typename is deprecated". ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=107586&aid=912368&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

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