- Boost - lists.preview.boost.org

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

[serialization] crash with save/load binary
by Vladimir Prus 09 Feb '04

09 Feb '04

Robert, the attached program crashes for me, and I can't understand why. There's a class which contains an array and stores/loads that array. When I run the program, I see: Saving 3{3 4 5 6 } Saving 2{2 3 } Read 3{3 4 5 6 } Aborted That is, first object is deserialized correctly, but the second is not. Is there something wrong with my code, or it's a bug in serialization library? Thanks in advance, Volodya

1 1

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

09 Feb '04

What's the status of the code/doc polishing for the items in boost/pending? I'd like to help out, especially with: * The queues and heaps: queue.hpp, mutable_queue.hpp, fibonacci_heap.hpp. * disjoint_sets I'm planning on using these classes in my multi-state mazes project. Cromwell Enage __________________________________ Do you Yahoo!? Yahoo! Finance: Get your refund fast by filing online. http://taxes.yahoo.com/filing.html

2 2

Is the release boost_1_31_0.tar.gz file OK?
by Beman Dawes 09 Feb '04

09 Feb '04

I've had a report that boost_1_31_0.tar.gz gets a checksum error halfway through unzipping. Has anyone else had a problem? Or used the file successfully? --Beman

7 7

Re: [Boost-users] [BGL] Removing vertices and internal properties
by Jeremy Siek 09 Feb '04

09 Feb '04

Hi Frédéric, Could you post a short (but complete) program showing what you are trying to do? Thanks, Jeremy On Feb 9, 2004, at 3:41 AM, Frédéric Mayot wrote: > Hi, > > I have a graph in the form of an adjacency_list with an internal > property. I'm > using vecS for both vertices and edges (and I don't want to use listS). > > When I remove a vertex with remove_vertex(), it seems that my property > map is > invalidated. Can I remove the property (from the map) which > corresponds to the > deleted vertex ? Is there any solution ? > > Thanks. > > Fred > > _______________________________________________ > Boost-users mailing list > Boost-users(a)lists.boost.org > http://lists.boost.org/mailman/listinfo.cgi/boost-users > _______________________________________________ Jeremy Siek <jsiek(a)osl.iu.edu> http://www.osl.iu.edu.edu/~jsiek Ph.D. Student, Indiana University Bloomington C++ Booster (http://www.boost.org) Office phone: (812) 856-1820 _______________________________________________

1 0

[BGL] Problems in adjacency_list_io.hpp
by Frédéric Mayot 09 Feb '04

09 Feb '04

Hi, I tried to use adjacency_list_io.hpp functions and I saw a small problem : 2 functions void getSubset ( no_property& p, const no_property& s ); and std::istream& operator >> ( std::istream& in, no_property& ) are not templated and are in a header file ! This prevents me to link my program since I include this header in different compilation units. I added "inline" before the two functions and the problem was solved. Fred

2 1

[Boost-bugs] [ boost-Support Requests-893381 ] problem buildingboost_python.dll from boost V1.31.0
by SourceForge.net 09 Feb '04

09 Feb '04

Support Requests item #893381, was opened at 2004-02-09 05:23 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=893381&group_i… Category: Python Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: David Abrahams (david_abrahams) Summary: problem building boost_python.dll from boost V1.31.0 Initial Comment: hi everybody, when trying to build the boost_python.dll and lib of the new boost 1.31.0 with the visual studio project files (found in: boost/libs/python/build/VisualStudio) (i use MSVC6 ). i get following errors: ../boost/graph/detail/adjacency_list.hpp (lines 1055, 1057) error C2244: 'bidirectional_graph_helper_with_property.... and error C2954: template definitions can't be put into each other ../boost/mem_fn.hpp (line 315) error C2039: 'dm' no element of '_mfi' i had no problem building those files in boost 1.30.2: 0 errors 0 warnings (my genuine respect here!!) did anyone come across the same problem and solved it? by the way i couldn't build the dlls (neither from 1.30.2 nor 1.31.0) with the stlport (i use stlport 4.6.1). is there any possibility to do that? i get the errors "fprintf" not in _STL and "strcmp" not in _STL could you please help me ? with my best regards oliver ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=207586&aid=893381&group_i… ------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn _______________________________________________ Boost-bugs mailing list Boost-bugs(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/boost-bugs

1 0