- Boost - lists.boost.org

[1.46.1] Release notes
by Daniel James 09 Mar '11

09 Mar '11

Hi, As always, I'm preparing the release notes. I left it a bit late this time, and there's not that many changes, so I've tried to summarise the existing changes myself. But I've probably got it completely wrong. So please check at: http://beta.boost.org/users/news/version_1_46_1 Normal procedure applies; you can either email me your changes or edit the notes yourself at: https://svn.boost.org/svn/boost/website/public_html/beta/feed/history thanks, Daniel

3 5

[serialization/fusion] Why aren't fusion vectors serializable with boost.serialization?
by David Sankel 09 Mar '11

09 Mar '11

Why aren't fusion sequences serializable? TIA, David -- David Sankel Sankel Software www.sankelsoftware.com

3 2

[Review] Boost.Type Traits Extension by Frederic Bron
by Joel Falcou 09 Mar '11

09 Mar '11

Dear All, According to the Boost Formal Review Schedule [1], fast track review of Frédéric Bron's extensions to the Type Traits Library starts on March 14th and lasts until March 18th, 2011 under my management. [1]http://www.boost.org/community/review_schedule.html =========== What is it? =========== This extension adds 37 new traits corresponding to the following 37 operators: - binary: ==, !=,<,<=,>,>=, , +, -, *, /, %, +=, -=, *=, /=, %=, , &&, ||, ,&, |, ^,<<,>>,&=, |=, ^=,<<=,>>= - prefix: ++, --, +, -, !, ~, * - postfix: ++, -- Each trait can detect if the operator can be used with particular types and if needed, if the return type is convertible to some type. =================== Getting the library =================== The latest version can be downloaded by different ways: - from the vault with unix line ending: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=type_t… - from the vault with dos line ending: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=type_t… - from the sandbox:http://svn.boost.org/svn/boost/sandbox/type_traits/ The entry point of the documentation is type_traits/libs/type_traits/doc/html/boost_typetraits/category/value_traits/operators.html The library has been tested with: - MSVC 8, 9, 10 on Windows, - g++ 4.4.5 on Linux, - intel 10.0 and 11.1 on Linux. To test the library, the simplest is to untar the headers in your boost include directory. For this, you can download the header part of the extension: - from the vault with unix line ending: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=type_t… - from the vault with dos line ending: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=type_t…

1 0

boostcon2011
by Jeff Flinn 08 Mar '11

08 Mar '11

I was just going to register, but see: "Registration Not Yet Open For 2011" Is that up to date? Any idea when "full" registration will be opened? It's easier from our company book-keeping requirements to do a single transaction. Thanks, Jeff

2 1

Review Results for Proposed Boost.Process library
by Marshall Clow 08 Mar '11

08 Mar '11

---------------------------- Executive Summary ---------------------------- Boris Schäling's Process library was reviewed from February 7th, 2011 through February 20, 2011. The library sparked a lively debate on the mailing list, and in the end, eight reviews were submitted: - 1 review ACCEPT - 2 reviews CONDITIONALLY ACCEPT - 5 review DO NOT ACCEPT Since there was not a clear view in either the discussion or the votes that this library should be accepted: The Process library IS NOT ACCEPTED into Boost. There was considerable disagreement both about the scope of the library (what features to provide) and how the features were implemented. More than one alternate design was proposed, and the advantages and disadvantages of various approaches (where to install signal handlers, having a single thread vs. one thread/child) were debated vigorously. However, there was a fairly broad consensus that the library, in its present state, was not ready to be included into Boost. Thank you to everyone who participated, and especially to Boris and those who wrote a review. I would like to encourage Boris to continue development of his library and to resubmit it for review at a future date. ---------------------------- Concerns voiced by reviewers (a partial list) ---------------------------- * There was considerable push back by the reviewers about the cross-platform interface; specifically the use of #ifdefs * Artyom pointed out the possibility of deadlock given the current implementation, and a lack of wide-character support on Windows. * Oliver said "I'm missing the possibility to send signals to a process and to wait for a process to be stopped (SIGSTOP) or resumed (SIGCONT) using boost.asio." * There was a lot of discussion about the correct way to handle SIGCHILD, and how to implement passing data back and forth between the parent and child processes. * There was an involved many-sided discussion on about what facilities a Boost.Process library should provide. * More than one person proposed an alternate interface for the library (Jeff Flinn, Darren Garvey, Max Sobolev, possibly more) * Brendon Costa expressed concerns that it would be easy to end up with zombie processes using the current library. * Jeremy Maitin-Shepard felt that "The lack of efficient asynchronous waiting support, and the overly complicated stream behavior interface, are show-stoppers for me". * Jeff Flinn did not like the lack of launch error reporting (among other things) -- Marshall Clow; Review Manager

2 1

Re: [boost] [xint] Boost.XInt formal review (concrete complaint)
by Ivan Le Lann 08 Mar '11

08 Mar '11

----- "Chad Nelson" <chad.thecomfychair(a)gmail.com> a écrit : > On Mon, 07 Mar 2011 09:45:02 +0100 > Ivan Le Lann <ivan.lelann(a)free.fr> wrote: > > >>> I don't think that this is enough to prevent surprises. If someone > >>> does > >>> > >>> thread t( f, x ); > >>> > >>> where x is an integer, the thread would receive a shared copy of x. > >>> The user would need to explicitly call the copy constructor with a > >>> second argument of true to avoid that. > >> > >> You'd think so, but so long as that thread class takes the integer > >> parameter as either a constant reference or by value, or is the only > >> one thread accessing it if it's passed by non-constant reference, > >> that's not the case. > > > > I'm not sure I understand why you say that t does not get a shared > > copy. Anyway what seemed obvious to me with current impl is that block > > below can either leak or double destruct x data. Am I wrong? > > > > void f (integer) {} // by value > > ... > > { > > integer x = 42; > > async ( f, x ); > > async ( f, x ); > > } > (snip) > Unless you > explicitly tell the library to use CoW on external objects, it will > deep-copy them, so each call to async will get its own storage. > Ohhh ... I only get now what you meant with "external objects". I forgot you have only limited COW. Sorry for my slow brain. This might explain why XInt was significantly faster when I added byref arguments. I exspected marginal speedup and got 30%. Ivan

2 1

Re: [boost] [general] is there a noop deallocator in boost? (Moving to devel list.)
by Mostafa 07 Mar '11

07 Mar '11

On Mon, 07 Mar 2011 14:33:19 -0800, Igor R <boost.lists(a)gmail.com> wrote: >> I'm interested in a noop deallocator for use in shared_ptr, but can't >> find >> one in boost, so does anyone know of one? (I know it's trivial to write >> one, but that doesn't out weight the convenience of using a standardized >> one.) > > Well, as far as I see, there's a ticket opened 3 years ago: > https://svn.boost.org/trac/boost/ticket/1913 > And there are several copies of null_deleter in various libraries, eg. > in boost::serialization, boost::signals2, etc. Does any know the status of this ticket? Are there any plans to address it? Thanks, Mostafa

1 0

D-style scope guards?
by Martin Christiansson 07 Mar '11

07 Mar '11

Hi, I have used the good old scopeguard in the past and recently done some experiments with the Boost.ScopeExit library. Still I feel that the clean scope statements in D is missing. It will not be possible to do an equally clean solution without having the same features in the language itself, but I could reach as far as this example that reuses the ScopeExit library: void foo() { GUARDED_SCOPE_BEGIN GUARDED_SCOPE_EXIT() { cout << "Returning from foo()" << endl; } GUARDED_SCOPE_EXIT_END GUARDED_SCOPE_SUCCESS() { cout << "foo(): No Errors occurred!" << endl; } GUARDED_SCOPE_SUCCESS_END GUARDED_SCOPE_FAILURE() { cout << "foo(): Exception caught!" << endl; } GUARDED_SCOPE_FAILURE_END GUARDED_SCOPE_END } The GUARDED_SCOPE_BEGIN macro declares one boolean guard to handle return from several levels of nested scopes and one boolean to guard the current scope from exceptions (will be shadowed in nested scopes). GUARDED_SCOPE_END will set the exception_thrown guard to false before that variable is used by the GUARDED_SCOPE_*() destructors. The latter is actually reused ScopeExit code with an added wrapper with a single if-statement. GUARDED_SCOPE_EXIT() will allways run on scope exit. GUARDED_SCOPE_SUCCESS() will only run if the function is exited with wrapper for return keyword (GUARDED_SCOPE_RETURN). The wrapper must be used since it updates the hidden guard variables. Using plain "return" will behave as if exception was thrown. GUARDED_SCOPE_FAILURE() will run when exception is thrown. There is also a separate GUARDED_SCOPE_NESTED_BEGIN that is supposed to be used for all nested scopes. A reference is kept to the return_called variable in the top-level-scope (variable declared by GUARDED_SCOPE_BEGIN). The biggest issue here is that any extra closing curly bracket inserted between GUARDED_SCOPE_*-definitions and GUARDED_SCOPE_END will cause destructors to run before update of guard variable. Could happen if someone thinks it "looks better" without understanding how stuff works. That kind of error will behave as if exception was thrown. Is this something to investigate further? Messy or potentially useful? Suggestions for improvements? I've appended the contents of my small test program at the end of this email. Can be tested by inserting GUARDED_SCOPE_RETURN() and "throw exception();". Regards, /Martin ----------- #include <iostream> #include <exception> #include <boost/scope_exit.hpp> using namespace std; #define GUARDED_SCOPE_BEGIN bool return_called = false; { bool& return_called_ref = return_called; bool exception_thrown = true; #define GUARDED_SCOPE_NESTED_BEGIN { bool& return_called_ref = return_called; bool exception_thrown = true; #define GUARDED_SCOPE_END exception_thrown = false; (void) return_called_ref; } #define GUARDED_SCOPE_RETURN(rc) { return_called_ref = true; return rc; } #define GUARDED_SCOPE_EXIT(Seq) BOOST_SCOPE_EXIT(Seq) #define GUARDED_SCOPE_EXIT_END BOOST_SCOPE_EXIT_END #define GUARDED_SCOPE_SUCCESS(Seq) BOOST_SCOPE_EXIT( (&return_called_ref) (&exception_thrown) Seq) { if(return_called_ref || !exception_thrown) #define GUARDED_SCOPE_SUCCESS_END } BOOST_SCOPE_EXIT_END #define GUARDED_SCOPE_FAILURE(Seq) BOOST_SCOPE_EXIT( (&return_called_ref) (&exception_thrown) Seq) { if(!return_called_ref && exception_thrown) #define GUARDED_SCOPE_FAILURE_END } BOOST_SCOPE_EXIT_END void foo() { GUARDED_SCOPE_BEGIN GUARDED_SCOPE_EXIT() { cout << "Returning from foo()" << endl; } GUARDED_SCOPE_EXIT_END GUARDED_SCOPE_SUCCESS() { cout << "foo(): No Errors occurred!" << endl; } GUARDED_SCOPE_SUCCESS_END GUARDED_SCOPE_FAILURE() { cout << "foo(): Exception caught!" << endl; } GUARDED_SCOPE_FAILURE_END do { GUARDED_SCOPE_NESTED_BEGIN GUARDED_SCOPE_FAILURE() { cout << "Inner scope: Exception caught!" << endl; } GUARDED_SCOPE_FAILURE_END GUARDED_SCOPE_SUCCESS() { cout << "Inner scope: No Errors occurred!" << endl; } GUARDED_SCOPE_SUCCESS_END GUARDED_SCOPE_END } while(0); GUARDED_SCOPE_END } int main() { try { foo(); } catch(exception& e) { cout << "main(): Caught exception: " << e.what() << endl; return -1; } cout << "main(): No Errors occurred!" << endl; return 0; }

9 16

Re: [boost] [xint] Boost.XInt formal review
by Brent Spillner 07 Mar '11

07 Mar '11

On 4 Mar 2011 at 21:57. Christopher Jefferson wrote: >As a point of information, the GAP system (a mathematical computation system I use) calls its primality function " isProbablyPrime". > >Mathematica just says "PrimeQ", but they make the claim that they have done extensive mathematical and practical testing, and never found a number which their >probabilistic algorithm fails on. > >Unless someone is willing to put that amount of work in, I personally would much prefer is_probably_prime. I'd vote for "rabin_miller_pseudoprime()"... those familiar with number theory will understand exactly what it does, and you can add the number of iterations as a parameter with a sensible default value. Other users will at least recognize that it's not quite the same thing as a deterministic primality test, and if they look up the term 'pseudoprime' they'll find plenty of primer material on the subject. At any rate, this is /not/ just a philosophical debate-- there are known attacks that pass pseudoprimes to weak testing functions, and an unsophisticated user who finds a nondeterministic is_prime() function in a library is likely to write susceptible code. (cf. http://webcache.googleusercontent.com/search?q=cache:CPnKD-Rq1X4J:www.iacr.…)

3 2

Boost.Polygon issues
by Barend Gehrels 07 Mar '11

07 Mar '11

Hi Luke, You asked me on the GGL mailing list ( http://bit.ly/hCwdJx ) to verify tests using Boost.Polygon to check Boost.Geometry's behaviour at some points. I cannot reach that point. I ported a test that I already had (recursive polygons) to Boost.Polygon. I'm using the Polygon Set Concept with integer coordinates. Actually all input is in the 90/45 degree range. If I run the program, it often gives me the wrong results, even in the simpler cases. And often it just crashes, in the line 1748 of file polygon_arbitrary_formation.hpp (called from the area function) I extracted two (wrong but not crashing) cases. Source code here: http://bit.ly/fCYRWL Summary of second case: area p: 45000 area q: 55000 area intersection: 0 area union: 60000 The last one, area of union, should be 100000, if the intersection is zero, the union contains everything and its area therefore should sum to 100000 Regards, Barend

2 2