- Boost - lists.boost.org

RE: [boost] Re: Questions about the new license
by Powell, Gary 10 Feb '04

10 Feb '04

Ok then, forget it.... If you want to rip off this software you aren't going to ask anyway. No amount of laws is going to prevent it, and there is no money on my side to enforce it even if I thought you were ripping boost off. I'll trust to the wrath of public opinion of those contributors to Boost when they find out, and they will eventually, will be enough. Who would want to work for someone who did that? Not I. Beman, You can add my name to the page which lists those who agree to the new license and can have any of their previously submitted source code modified to use it. Yours, Gary Powell

1 0

Questions about the new license
by Robert Ramey 10 Feb '04

10 Feb '04

Powell, Gary wrote >#1 I'd prefer that any software I contribute to boost remain "free", as in >I don't want someone to add 20 lines of code to a library and then sell it. >You can sell the compiled machine code but not the original or the modified >source other than to cover duplication and distribution costs. Why not? Who cares? >#2 I have worked for a overly restrictive employer who was paranoid that >anything anyone might do on their own time might be owned by the employee >and not the employee. It would be extremely helpful if the license states >clearly that derivatives cannot be owned. Again: why not? As long as the status of the original is unchanged why should anyone care? >I'm all for a company like "Boost Consulting", I think they add plenty of >value to the boost community and give back way more than they take from the >free software. >However greedy companies have been known to take free software, modify it >and not return it to the public domain. Again so what? If this is such a concern, don't contribute it - just sell it yourself. >There of course is no time limit and no way to prevent this from happening >but it would be better if the copyright was a copy left. Nothing wrong with copy left. Its different, but not necessarily better. >Also all that bit about the liability disclaimers, forget it, you can be >sued for anything, at anytime, not withstanding the claim about the >liability, it might as well not be there for all the good it will do us. On >the other hand it does give us a leg up in the event of a lawsuit, "We >claimed it was worthless your honor." With such little faith in the legal system, why are you even concerned About the license at all? >Also one should be able to write a book about boost, use part of the >documentation without a heap of trouble. But a bound reprint of the >documentation is owned by???? Hmmm - a good question. Robert Ramey

1 0

Fwd: [boost] Re: Exceptions as streams
by Geoff Leyland 10 Feb '04

10 Feb '04

On 10/02/2004, at 12:14 PM, Jonathan Turkanis wrote: > "Geoff Leyland" <gley001(a)ec.auckland.ac.nz> wrote in message > news:9EDC4024-5B52-11D8-B48C-000A95DB9BF6@ec.auckland.ac.nz... >> 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? >> ... > > Have you seen > > http://www.boost.org/more/error_handling.html > > particularly item 4 ("Format the what() message o demand"), but also 3 > and 5? > > Jonathan I have now, thanks, and in principle I agree with what it says. I think, though, that not all exceptions are created equal. When I first started using exceptions I wrote an exception class that had static buffers for the data it might need to store, because I thought that exceptions might be thrown in low memory situations. I don't think I have ever seen any of my code throw an out of memory exception. I don't think I've ever seen a string constructor throw. I know that the stream operators could probably throw, but they don't very much compared to the mistakes I make. I have also been down the road of writing loads of little exception classes for different kinds of problem, each containing the relevant fields for the particular type of exception, so that all the data you needed to interpret the exception was available in the public interface of the exception. Needless to say, it was a pain in the ass, and I never wrote any code that interpreted the data in the exception (except to format "what") In my little command line world, the errors I usually get are that people have forgotten a key-value pair in an input file, or they've spelt the path to a plugin wrong. I could print out the problem and try to continue, and inevitably crash. I could print out the problem and exit or assert, but sometimes I'm running hundreds of tests over a few days, and I don't want the damn thing to stop completely in the middle of the night because I've made a mistake configuring one of the tests. So what I do is throw an exception with a readable message. The main program running the test loop can catch these exceptions, store them all up, and print them all out right at the end of the tests, telling me which tests had problems and why, so that they don't get lost in all the other guff the tests are printing out. There are lots of legitimate reasons for throwing lots of types of exceptions, and I'm not implying that throwing some kind of "streamy_exception" is appropriate in all (or even more than a few) places, but it has made my life a lot easier, and made a lot of silly mistakes easier to fix. cheers, Geoff

4 11

Silently ignoring errors (was Re: future of boost.thread s )
by Rob Lievaart 10 Feb '04

10 Feb '04

The discussion drifted away from "should we be able to pass exceptions from one thread to another" to a more general topic of what to in case of unexpected errors. I'd like to put in my $0.02 cents here. While there are cases where the best solution to unexpected errors, is restart a thread, ignore part of the results and pray. I think they are not that common and require explicit programmer action to decide when to pray and when to really give up and abort the program. Catching and silently ignoring an error by default is IMHO the worst possible choice. It should be possible for a programmer to ignore a lot of errors if he wants to, even acces violations in some cases, but I think the default behavior should be for the system to "scream" as as loud as possible if something unexpected happens. So coming back to the boost.threads discussion, if the default behavior for unexpected exceptions was to dump core, or jump into the debugger that seems like a pretty loud scream. (As several others allready pointed out the more information you get in a situation like this the better) When I need other behavior, it should be a conscious decission on my part to handle these unexpected situations, and then they are not really unexpected anymore. Kind regards, Rob Lievaart. <war story> The first example that comes to mind is a system where I spent a week and a half looking for a bug (After several others had tried to find it before me an failed) that had been in the system for wel over a year. The bug caused _allways_ caused an error in the program that was silently ignored. The program worked "perfectly", for a while, untill the harddisks became larger and the amount of free space on customers computer increased. Then it started giving loads of problems. If this error had not been silently ignored, the bug would have been spotted during the first test after it was introduced, and it probably would never have been checked in into the revision control system. </ware story>

2 1

RE: [boost] Re: Questions about the new license
by Powell, Gary 10 Feb '04

10 Feb '04

Boost licensing policy aside for a moment, the CPL is your friend. --------------------------------- I agree. Or course that begs the question why have a special "boost" license? (Although I understand that not all parties to boost are bound by the laws of NY State and those of the US. And the USofA has not signed up for the world court. What does it take to include a CPL? a copy of the full text? And would including both a CPL AND the boost text corrupt the code to make it not boost acceptable? -Gary-

1 0

Re: [boost] [BGL] <boost/pending/*.hpp> documentation
by Cromwell Enage 10 Feb '04

10 Feb '04

Will all the header files mentioned in the TO-DO list stay where they're at once they're polished up? If not, where will their final home(s) be? Cromwell Enage __________________________________ Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online. http://taxes.yahoo.com/filing.html

2 1

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