- Boost - lists.boost.org

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

RFC: parm_string
by Kevin Atkinson 09 Feb '04

09 Feb '04

Here is a very simple, but extremely useful, class I would like to submit for inclusion for boost: parm_string. parm_string is a special string class that is designed to be used as a parameter for a function that is expecting a string. It will allow either a "const char *" or "string" class to be passed in. It will automatically convert to a "const char *". The string can also be accesses via the "str" method. Usage example: void foo(parm_string s1, parm_string s2) { const char * str0 = s1; size_t sz = s2.size() if (s1 == s2 || s2 == "bar") { ... } } .. string s1 = "..."; foo(s1); const char * s2 = "..."; foo(s2); By using parm_string instead on "const char *" one avoids the need to have to use the c_str() member every time a string is passed into a function. It is also more effect than just using "const char *" as the length information is passed in if it is known. It is also more efferent than just using "const string &" as that will involve creating an unnecessary temporary when a non string object is used. In my experience most functions that require a string as a parameter really only need the value of the string and possibly its length. They don't need the functionally of the full "string" class. Attached is parm_string.hpp and a simpile program parm_string.cpp I use a variant of this class heavily in my programs I find it extremely useful. -- http://kevin.atkinson.dhs.org

2 1

Re: GPL'd doc makefile
by Alexander Terekhov 09 Feb '04

09 Feb '04

Alexander Terekhov wrote: > > David Abrahams wrote: > [...] > > I fear that's right. Maybe I should just rewrite that stuff using > > Boost.Build. Heh, easy, right? > > Fix the Boost Software License first, please. BSL does impose > the reciprocation provision with respect to derivative works > (not imposing an obligation to make the source code available), > but it doesn't really authorize the distribution of derivatives. > > http://www.digital-law-online.info/lpdi1.0/treatise26.html > > --- > if there are different authors, then the copyright owner in any > work has to authorize the MAKING of any further derivative works > AND must approve of any DISTRIBUTION of the work that contains > his material. Unless ownership and distribution rules are > resolved at the time the work is being developed, there could be > problems at a later time. > --- > > http://www.opensource.org/licenses/cpl.php > > --- > a) Subject to the terms of this Agreement, each Contributor > hereby grants Recipient a non-exclusive, worldwide, royalty- > free copyright license to reproduce, PREPARE DERIVATIVE WORKS > of, publicly display, publicly perform, DISTRIBUTE AND > SUBLICENSE the Contribution of such Contributor, if any, AND > SUCH DERIVATIVE WORKS, in source code and object code form. > --- http://article.gmane.org/gmane.comp.lib.boost.user/5072 David Abrahams wrote: [...] > > > Clearly, I may distribute "the Software", but may I distribute > > the derivative work? > > This is the answer from our lawyer, Devin Smith. Sorry it took so > long: > > A programmer who -- with the permission of the copyright holder -- > creates a derivative work based on another work actually owns the > derivative work. So, since the programmer of the derivative work owns > it, there's no need for the owner of the original work to grant that > programmer a license to distribute the derivative work. > > Now, that doesn't mean that the owner of the original work can't put > contractual restrictions on what the programmer of the derivative work > can do with the derivative work. The Boost license, for instance, > requires programmers who develop derivative works to include the Boost > license with non-object code distributions of the derivative work. http://crynwr.com/cgi-bin/ezmlm-cgi?3:mss:7647 ---- >> He also has no rights in the derivative work as a whole - such rights don't >> exist. There is no copyright in the work as a whole, only seperate >> copyrights in the pre-existing work, and in the added work. > > This directly contravenes the text of the statute. No. You have to read §103 carefully. I explain below. > The copyright owner say author here instead of copyright owner, it makes things simpler > of a derivative work is a copyright owner with all the rights of a > copyright owner, Yes. He has copyright in his contribution to the whole work. But he does not have the right to make copies of the whole derivative work that include (parts of) another's original work. > except that he cannot prevent the creation of other > works derivative of the original work but not based on his contribution. §103 in full: "Subject matter of copyright: Compilations and derivative works (a) The subject matter of copyright as specified by section 102 includes compilations and derivative works, but protection for a work employing preexisting material in which copyright subsists does not extend to any part of the work in which such material has been used unlawfully. (b) The copyright in a compilation or derivative work extends only to the material contributed by the author of such work, as distinguished from the preexisting material employed in the work, and does not imply any exclusive right in the preexisting material. The copyright in such work is independent of, and does not affect or enlarge the scope, duration, ownership, or subsistence of, any copyright protection in the preexisting material." You might think that (a) means there is copyright in a compiled or derived work, but it is not necessarily so. If eg a compilation (not the compiled work, but the work of compilation) is not itself an original work os authorship then there is no copyright. The same law applies to derivative works. I agree that that is confusing. What (a) really says is that if you make a derivative work without permission from the copyright holder of the original work then you don't even have copyright in your own work. You might think that (a) says there can be copyright in a compiled or derived work as a whole, but it doesn't. (b) make the overall situation perfectly clear - any copyright in the derived work does not extend beyond the contribution of the author of the derived work. Any preexisting material is unaffected by the new copyright. The only thing the second author has copyright in is his own work. If the second author has to make copies of the original work in order to make copies of the whole derived work (which would usually be the case), he has to have the separate permission of the first author to do so. Only the original author has the right to do that. Permission to make a derivative work does not automatically (or even usually) include permission to make copies of/distribute the original work as part of a whole. ---- And, finally, this is fun: http://crynwr.com/cgi-bin/ezmlm-cgi?3:mss:7651 ---- Alan writes an original computer program. It is 3 lines long. It is called "Hello world". Bob takes Alan's program and replaces line 2. The new program is called "Goodbye asshole". "Goodbye asshole" is a derivative work. If Bob did not have Alan's permission to create a derivative work then he gets no rights at all. If Bob had Alan's permission to create a derivative work then he gets the sole right to distribute line 2. He does not get any right to distribute lines 1 and 3. He cannot distribute "Goodbye asshole" including lines 1 and 3 without separate permission from Alan. ---- regards, alexander. P.S. I just love the unified Boost Software License Version 1.0. ;-) -- http://www.xfree86.org/pipermail/forum/2004-February/001978.html http://www.xfree86.org/pipermail/forum/2004-February/001980.html

1 0