March 2011 - Boost - lists.boost.org

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 08 Mar '11

08 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

[Polygon] Unqualified name lookup of 'gtlsort' in templates
by Doug Gregor 07 Mar '11

07 Mar '11

The Polygon library has a minor C++ standards-conformance issue w.r.t. unqualified name lookup in templates for 'gtlsort' operator. In particular, the header <boost/polygon/polygon.hpp> includes a number of source files that make unqualified calls to 'gtlsort'. 'gtlsort' itself is not defined until much later, when <boost/polygon/detail/scan_arbitrary.hpp> pulls in <boost/detail/polygon_sort_adaptor.hpp>. At least in the cases used in the Boost.Polygon test, 'gtlsort' isn't found by ADL at instantiation time, either. Clang detects this conformance problem, which is described here: http://clang.llvm.org/compatibility.html#dep_lookup The solution is to provide forward declarations of the two 'gtlsort' overloads in a header that all users of 'gtlsort' depend on. For example, introducing a forward header containing namespace boost { namespace polygon { template <typename iter_type> void gtlsort(iter_type _b_, iter_type _e_); template <typename iter_type, typename pred_type> void gtlsort(iter_type _b_, iter_type _e_, const pred_type& _pred_); } } and including it before the users of 'gtlsort' would work fine. - Doug

2 1

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

07 Mar '11

----- "Peter Dimov" <pdimov(a)pdimov.com> a écrit : > Ivan Le Lann wrote: > > > Useless sarcasm aside, isn't that an abuse of atomics? > > Reference counting an abuse of atomics? It's one of the primary use > cases for them. > I was not challenging the fact to use atomics to refcount. I was challenging the "Let's refcount since it can be atomic!". Atomics are a heavy dependency, and they're not free. In the end, that's still about challenging COW. Point is I'd hate to hear in a few years that C++ is "that language where you have to do atomics to add two 512bits integers". But I'm probably wrong about all this, Ivan

1 0

[xint] Utility question, how to implement...
by Rene Rivera 07 Mar '11

07 Mar '11

Chad, Unfortunately I don't have time to do a review of your library (even a quick one). But I do have one question... In my general code library I have an implementation of a one-way-accumulator based on the facilities provided by the Botan library. It's an algorithmically efficient implementation using Barrett reducers for modulo exponentiation with small bases and large exponents. My question is: How would I go about implementing the equivalent in your library? NOTE: I can post my code if need be to make this a clearer question. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail

3 7