- Boost - lists.boost.org

serialization update for boost-1.31.0?
by Robert Ramey 10 Feb '04

10 Feb '04

Niel Becker wrote: >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? I'm hoping to upload an updated version in the next couple of days. I Had some difficulties in tracking changes in the release candidates. I'm Chasing a couple of final bugs, and making tweaks for VC 6.0, Intel, And dinkumware. My latest (pretty good) version can be found a www.rrsd.com Its #16, or you can wait a couple of days. Robert Ramey

1 0

Interest in aspect oriented library
by christopher diggins 10 Feb '04

10 Feb '04

Would there be some interest in an Aspect Oriented Programming library amongst Boost users? I have done some preliminary work on creating macros for crosscutting concerns into existing classes at http://www.heron-language.com/aspect-cpp.html and I am wondering if I should continue work on it. Thanks in advance! Christopher Diggins yet another language designer and avid Boost fan http://www.heron-language.com

4 4

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