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

RE: [boost] Re: future of boost.threads
by Darryl Green 10 Feb '04

10 Feb '04

> -----Original Message----- > From: Peter Dimov [mailto:pdimov@mmltd.net] [snip] > Now, in C++ functions actually can return either a value or > an exception. > That is, > int f(); > can return an int or throw an exception. Hence, when you > execute that f in a > thread, you should be able later to call > > int thread::join(); > > and it should return whatever f returned. Yes. I think you mentioned this last time exception propogation across threads was discussed, and I agree. I seem to recall that William Kempf was keen to shift the burden of these sorts of things to some form of wrapper/function object (see http://article.gmane.org/gmane.comp.lib.boost.devel/14237) > > Note that you can't add exception marshalling on a higher > level (with the > current interface) because you can't access a thread's state > (to retrieve > its return value or exception) from another thread. Can't some function object wrapper catch and store the exception somewhere other than in the "thread state" for later access from some sort of async call object regardless of the underlying thread implementation? The joining thread would wait on one of these async call objects (ie join). The async call object and the wrapper would have shared access/ownership of the result (exception or return value) storage. What am I missing? Regards Darryl Green. ########################################################################## This e-mail is for the use of the intended recipient(s) only. If you have received this e-mail in error, please notify the sender immediately and then delete it. If you are not the intended recipient, you must not use, disclose or distribute this e-mail without the author's prior permission. We have taken precautions to minimise the risk of transmitting software viruses, but we advise you to carry out your own virus checks on any attachment to this message. We cannot accept liability for any loss or damage caused by software viruses. ##########################################################################

3 2

Access to regression-logs/cs-win32_rc_1_31_0_metacomm?
by Douglas Paul Gregor 10 Feb '04

10 Feb '04

Aleksey, Could we get group-write access to htdocs/regression-logs/cs-win32_rc_1_31_0_metacomm on Sourceforge? We'd like to be able to do a "cvs update" in doc/html, to get the BoostBook makeover into the nightly documentation. Doug

5 6

RE: [boost] Re: future of boost.threads
by Darryl Green 10 Feb '04

10 Feb '04

> -----Original Message----- > From: Stefan Seefeld [mailto:seefeld@sympatico.ca] > > Darryl Green wrote: > > What am I missing? > > to 'catch and store' an exception, i.e. to take it out of its > (C++) call stack, you need a 'virtual constructor' of some sort, > so the exact type is remembered in the clone (which is not just > a slice of a common base class) and can be re-dispatched in > a different context, i.e. the joining thread. I was assuming that all the discussion about how to define the set of exceptions to be caught was about trying to (rather painfully) avoid slicing. The virtual constructor sounds like magic to me, but maybe it is just sufficiently advanced technology. Do you have a trick up your sleeve to actually do this? And how does it relate to whether it can be done without changing the existing boost.thread interface? Thinking about it, I suspect Peter Dimov was thinking of avoiding the virtual constructor by keeping the referenced object alive after the "join". I guess you could do this by blocking in the catch block (ie don't really terminate at all) until the async call object is destroyed. I'm probably still missing something... Regards Darryl. ########################################################################## This e-mail is for the use of the intended recipient(s) only. If you have received this e-mail in error, please notify the sender immediately and then delete it. If you are not the intended recipient, you must not use, disclose or distribute this e-mail without the author's prior permission. We have taken precautions to minimise the risk of transmitting software viruses, but we advise you to carry out your own virus checks on any attachment to this message. We cannot accept liability for any loss or damage caused by software viruses. ##########################################################################

1 0

serialization update for boost-1.31.0?
by Neal Becker 10 Feb '04

10 Feb '04

Is serialization13 the latest? It doesn't seem to build with boost-1.31.0. Looks like it maybe isn't converted to new iterator adaptors?

1 0

RE: [boost] Perfect Forwarding (almost)
by Powell, Gary 10 Feb '04

10 Feb '04

It also seems to work with virtual base classes! (ick!) tested on: gcc 3.2 Yours, -Gary- PS I won't post any more files to the listserv after this one. (promise!)

1 0

RE: [boost] Re: Re: Exceptions as streams
by Reece Dunn 10 Feb '04

10 Feb '04

Jonathan Turkanis wrote: >To me, the ability to write an exception to a stream is unimportant, >since you can just use what(). The ability to write to an exception >class using operator<< has a certain appeal; I would defintely use if >it were free. On the other hand, if the stream operations are only >happening before the exception is thrown, and if you are dealing with >an exception type that already has the ability to hold some text, you >can get the same effect by using a stringstream. I'm not sure it's >worth introducing a new exception class just to save programmers the >trouble of defining a stringstream. Maybe for use in certaint types of >testing it would be helpful. Using a stringstream would be my approach to achieve this affect, but I wonder what would happen if the stream operation generated an exception? E.g. throw( std::ostringstream() << "Error #" << 404 << weberror( 404 )); what if weberror thows an exception? Also, is ostringstream guaranteed not to throw an exception? Throwing an exception during the exception process is not a good idea! Regards, Reece _________________________________________________________________ Stay in touch with absent friends - get MSN Messenger http://www.msn.co.uk/messenger

2 1

Announcement: Upcoming formal review of FC++
by Mat Marcus 10 Feb '04

10 Feb '04

The formal review of fcpp by Brian McNamara and Yannis Smaragdakis will commence on Friday February 13th at 12 noon, PST and and run to Monday, February 23rd, 12 noon PST. The library is currently available at <http://www.cc.gatech.edu/~yannis/fc++/boostpaper/> Here is a brief introduction to the library: FC++ is a library for doing functional programming in C++. The library provides a general framework to support various functional programming aspects, such as higher-order polymorphic functions, currying, lazy evaluation, and lambda. In addition to the framework, FC++ also provides a large library of useful functions and data types. The main utility of the library comes from its ability to implement functional programming designs, especially those which use higher-order polymorphic functions or lazy evaluation in significant ways. The library also contains a number of ancillary components that implement features like currying and lambda for function objects; these features are also useful in their own right. For information about submitting a Formal Review, see <http://www.boost.org/more/formal_review_process.htm> Please try out the library so that you will be prepared to say whether or not you think the library should be accepted by Boost during the upcoming review period next week and why. Compiler notes: This library has been tested with icc7 and with gcc-3.1.1 (and various other gcc-3.x.y versions) on Solaris and Linux. The library is also likely to compile on VC++7.1 and Comeau (prior versions of the library succeeded with these compilers, but this particular snapshot has not been tested with them). The library covers a great deal of the C++ language and thus requires a high degree of standard conformance; compilers like gcc-2.95.x and VC++6 will not be able to compile the library. Getting started: The web page http://www.cc.gatech.edu/~yannis/fc++/boostpaper/ mentions all the basics: The zip file will expand into these subdirectories: fcpp/fcpp/ # the library (.hpp) files fcpp/fcpp_clients/ # the example (.cpp) files Running the examples just involves invoking the complier with the right #include paths; for example, # in the fcpp_clients directory g++ -I/path/to/boost -I../fcpp some_example.cpp There is also a gnu-style Makefile included with the clients (examples), which will compile all of the examples in batch (you will have to edit a tiny bit at the top of the Makefile). The examples in the clients directory are a mix of both (regression-type) tests cases which cover the features of the library and example applications which demonstrate some of the library's utility. The README file in the client directory gives a short explanation of some of the more interesting clients. The documentation at http://www.cc.gatech.edu/~yannis/fc++/boostpaper/ provides a walkthrough and reference for most of the main features of the library. There are also some pointers out to other papers and documentation on the main FC++ web site: http://www.cc.gatech.edu/~yannis/fc++/ Conformance to Boost guidelines: The library meets most of the requirements described at http://www.boost.org/more/lib_guide.htm Here are a few notable exceptions: - the current library headers are too "monolithic"; you #include "prelude.hpp" and suck in all of the library - some of the lambda internals should be rewritten to use MPL rather than hand-rolled metaprogramming code - only a few of the example programs utilize the Boost testing framework (to automate regression testing) Should the library be accepted into Boost, Brian will remedy these deficiencies. (If you notice other major problems along these lines, please bring them to Brian's attention during the review.) The Formal Review manager is Mat Marcus.

1 0

Boost files space on Yahoo Groups nearly full
by Beman Dawes 10 Feb '04

10 Feb '04

The Boost files space on Yahoo Groups nearly full. Please delete files and directories you may have created which are no longer of interest. Thanks, --Beman

1 0

Exceptions as streams
by Geoff Leyland 09 Feb '04

09 Feb '04

Hi, Excuse me if this is already somewhere in boost - I haven't managed to find it. Does anyone else think that an exception that you can write to like a stream would be useful? So that you could go throw streamy_exception() << "Couldn't open the file " << file_name; and then later catch (streamy_exception &s) { std::cerr << "Oops! : " << s; // or std::cerr << "Oops! : " << s.what(); } I have code that does the above - it really isn't very tricky. If there was interest I could tidy it up a bit. It'd probably be even better to use the format library to compose the error message - then translations would become much easier. Cheers, Geoff

2 1

RE: [boost] Re: future of boost.threads
by Hurd, Matthew 09 Feb '04

09 Feb '04

> On Behalf Of David Abrahams > Subject: [boost] Re: future of boost.threads > > Stefan Seefeld <seefeld(a)sympatico.ca> writes: > > > Glen Knowles wrote: > >> From: David Abrahams [mailto:dave@boost-consulting.com] > >> >> Of course you cannot portably pass all exceptions, but you may be > able > >> >> to pass all the ones that use standard types. > >> > > >> >And what if the std library or somebody else throws exceptions > >> >*derived* from the standard types? > >> If it is not a recognized corba exception what the ACE TAO does is > >> eat it with a catch(...) and then throws a corba system exception on > >> the other side. > > > > > > yes, so all exceptions that are allowed to pass have to be explicitely > > declared > > as such. If it is not declared, a special standard exception will be > > thrown (or may be something equivalent to 'unexpected'). If it is > > derived from a declared one, it will be sliced. > > Is everyone convinced that propagating the exception into the joining > thread is the right behavior or even semantically sensible? No. I'm not. Though I do think it makes sense sometimes. Other times, (perhaps most other times for my code??), I think normal unhandled exception behaviour is appropriate. For example, if I have a pool of worker threads it makes no sense to me to have the unhandled exception propagate back. What happens to the other threads happily chewing through work? It should be the responsibility of the worker pool to handle this appropriately. If it was a simple single thread work off load or perhaps a block waiting thread then exception propagation may make sense to me. That is, if I have someone waiting to join() me. What happens if no one wants to join() the fun, where does your exception go? Sometimes a thread might just do its work and shutdown or some such, the semantics of your app might not require a join(). It might be an asynch messaging passing app where program life time is determined by shutdown messages propagating through or some such. I think support for propagating exceptions to support particular use cases and idioms makes sense, but I don't see it as a safe thing for all. Default behaviour should be to blow up and cause the chaos you've asked for within your design. You should have to ask for propagation explicitly where appropriate. I am also completely and utterly convinced that I am fairly ignorant of these matters ;-) Regards, Matt Hurd _______________________ Susquehanna Pacific P/L hurdm(a)sig.com +61.2.8226.5029 _______________________ 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