March 2011 - Boost - lists.boost.org

Boost.Thread: Support for variadic templates
by Daniel Neuberger 09 Mar '11

09 Mar '11

Are there plans for Boost.Thread to support variadic templates sometime soon? We'd use c++0x, but it looks like there's no plan to support timed_join and interruption/cancellation. Will Boost.Thread continue to do so though or is there something I'm missing in regards to c++0x? Thanks! - Daniel P.S. I asked basically the same question on the boost user list, but go no response. See http://thread.gmane.org/gmane.comp.lib.boost.user/66171.

2 3

[spirit] alert when backtracking?
by Arno Schödl 09 Mar '11

09 Mar '11

Hello, is there any way to detect at runtime or compile time whether Boost.Spirit needs backtracking? It would be nice to be alerted to the fact that the grammar is not LL(1) and thus has potential for optimization. Regards, Arno -- Dr. Arno Schödl | aschoedl(a)think-cell.com Technical Director think-cell Software GmbH | Chausseestr. 8/E | 10115 Berlin | Germany http://www.think-cell.com | phone +49 30 666473-10 | US phone +1 800 891 8091 Amtsgericht Berlin-Charlottenburg, HRB 85229 | European Union VAT Id DE813474306 Directors: Dr. Markus Hannebauer, Dr. Arno Schoedl

4 7

[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

[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

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

07 Mar '11

This is not a review, simply a question with regard to the default_random_generator constructor. If I'm reading random.hpp correctly, there is no way for a user to provide the seed value - a useful feature for folks like myself that use PRNGs to model stochastic processes. We frequently need to repeat a particular sequence of 'random numbers'. Any chance the seed could be passed as a parameter defaulted to the existing hard coded time/clock? As long as I'm asking, perhaps the ability to provide a special-purpose generator of our own design? I'd also like to express my appreciation for the effort you've obviously expended on this project. Thank you. Dick Bridges Western Digital Technologies, Inc. The opinions and data in this missive are my own and do not necessarily represent Western Digital positions, strategies, or opinions.

3 7

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

07 Mar '11

----- "DE" <satan66613(a)yandex.ru> a écrit : > on 07.03.2011 at 9:17 > Jeffrey Lee Hellrung, Jr. wrote : > > Another concern with COW in general is iterator invalidation. Either > > your iterator gets "fatter" and slower (e.g., by being implemented as a > > pointer to the object + offset), or you expand the class of operations > > that invalidate iterators beyond just resizing operations to *any* > > modification operation (compared to a class which does not use COW). > > been the cow atomically ref counted you will NEVER notice it's there I can't wait for the day "atomic free" will be a marketing point, just like "lock free" is today. > think of it: if an operation requires reallocation of the storage > then anyway iterators are invalidated Without COW, the iterators used in another thread are not invalidated, since no data is shared. Anyway, this whole thing sums up to: let me choose the container that suits my needs. Ivan

3 2

[Filesystem V3] path and ostream
by Juraj Ivančić 07 Mar '11

07 Mar '11

During the switch from Filesystem V2 to V3 I was bit by the new operator<<( basic_ostream<...> ) behaviour. The problem is that in V3 the path gets quoted when being output to the stream (and '&' is used as an escape character). This breaks the invariant which used to hold until now: std::stringstream stream; stream << path; assert( stream.str() == path.string() ); I have made the adjustments to my code, but I find this behaviour a bit surprising and was interested in the rationale for this decision. I could not find it on the Boost Filesystem home page. The only reason I could fathom is so that one can do this: std::stringstream stream; stream << path1 << path2; stream >> path3 >> path4; assert( path1 == path3 ); assert( path2 == path4 ); If so - I know several platforms where this will generally fail, as both & and " are legal characters in file names. Thank you for your response.

1 0

what tasktracker do you use?
by DE 07 Mar '11

07 Mar '11

hi all i recently began to use a task tracking and issue tracking system for the work project and i'm interested if anyone use some sort of such tools so the question: what task tracking and/or issue tracking system do you use for your own projects? let me know if this mailing list is the wrong place for this topic -- Pavel P.S. if you notice a grammar mistake or weird phrasing in my message please point it out

4 5

[context][fiber] implementation comments
by Charlls Quarra 07 Mar '11

07 Mar '11

Hi Oliver, I have a couple of comments on implementation context: i noticed you migrate out of the context::create idiom and now context is noncopyable, so it seems right now the only way to have a recyclable context as a member is hold a pointer/ref and allocate on the heap. This might be good for most use cases (which is probably the boost design principles) but i think it leaves out cases where, due to performance constraints, one either wants to recycle a context without touching the heap. Which leaves me to my other comment; could you add an template parameter for a allocator class so all new/delete operations are delegated to it? fiber: this applies here too; can you make the fiber take template parameters for the stack type and possibly use an allocator parameter to delegate all new/delete operations? currently fiber is couple to boost::context::protected_stack again, thanks for your work on the context and fiber libraries Charles J. Quarra

5 20

[range] transform surprise
by Neal Becker 07 Mar '11

07 Mar '11

I'm surprised that boost::range::transform args are template< class SinglePassRange1, class OutputIterator, class UnaryOperation > OutputIterator transform(const SinglePassRange1& rng, OutputIterator out, UnaryOperation fun); I would have expected: template< class SinglePassRange1, class SinglePassRange2, class UnaryOperation > OutputIterator transform(const SinglePassRange1& rng, SinglePassRange2& out, UnaryOperation fun); Why the asymmetry?

3 2

[network] 0.9-devel and BOOST_NETWORK_NO_LIB
by Dean Michael Berris 07 Mar '11

07 Mar '11

Hi Everyone, I just recently finished a consulting project that tied me up good the past three months. Now that I'm pretty much free again to work on cpp-netlib, I went for the things that have been brought up most recently on the list (and the Boost developers mailing list): 1. The server tests that used a different port each, configurable at the command-line with a default. This is already in 0.9-devel. 2. An option to turn off the required external library to be linked with a macro (BOOST_NETWORK_NO_LIB). With this macro defined before any cpp-netlib headers are included (or on the command line) the functions that were made extern or just free functions at namespace level are marked 'inline' and have their definitions pulled in accordingly in each translation unit. This addresses Jeff Garland's and others' concern of the need for an external library when using cpp-netlib when it's always been header-only until 0.9. I'm still wrestling with the thought of making the header-only behavior a default, but I'm not married to the "external library as default" decision either. 3. A consistent look/view between server-side request/response objects and client-side request/response objects. Now they can be dealt with using the same directives and modifiers. 4. Starting to change the library name to Boost.Network (after the suggestions). #2 is still undocumented, but I am going to be including a Doxygen-Sphinx bridge that would allow us to write documentation in-line on the types and have Doxygen invoked when the Sphinx documentation is built. I found a Sphinx extension to do that and it looks like it can be bundled with cpp-netlib as well (because it's under a BSD license) -- it's called "breathe" and can be found here: http://michaeljones.github.com/breathe/ #3 has been in the branch for a while already and it should be doable to back-port some of the things to the 0.8 line. #4 is largely a documentation matter. I have decided that in order for the development of the network library to scale, that I would spear-head a mini-community effort that would be called "The C++ Network Library Project" taking in a diplomatic and consensus-building approach. This way those willing to contribute to the effort can help with setting the direction of the library, the design decisions, etc. with me starting as the "benevolent dictator" and letting more people jump into the fray and becoming co-maintainers and regular contributors. There are already a couple of people (Oleg Malashenko and Emre Turkay) who have recently contributing to the project that I would like to thank, and also give the chance to get a bigger role in the development of the library going forward. So for now the focus is still to get a review-ready library for inclusion in Boost that would be called Boost.Network. I think 0.9 will be ready in a couple of days and will be a the pre-1.0 snapshot that will be submitted for review, getting all the required documentation in place. At this time I'm still looking for able and willing review managers. Feedback would be most definitely appreciated. -- Dean Michael Berris http://about.me/deanberris

1 0

[mpl] int_<INT_MIN> fails to compile under gcc 4.6
by Stirling Westrup 06 Mar '11

06 Mar '11

I'm not actually sure if this is a gcc regression, or a bug in mpl, but the following code, which compiles under gcc 4.5, doesn't do so under gcc 4.6: #include <climits> #include <boost/mpl/int.hpp> typedef boost::mpl::int_<INT_MIN> Foo; Foo f; It produces the errors: /usr/local/include/boost/mpl/aux_/integral_wrapper.hpp: In instantiation of ‘mpl_::int_<-0x00000000080000000>’: test_test.cpp:8:27: instantiated from here /usr/local/include/boost/mpl/aux_/integral_wrapper.hpp:73:96: error: ‘2147483647’ is not a valid template argument for type ‘int’ because it is a non-constant expression /usr/local/include/boost/mpl/aux_/integral_wrapper.hpp:73:96: error: overflow in constant expression [-fpermissive] I've already created a trak ticket for this (#5268), but was wondering if anyone had any insights as to its cause and/or any workarounds. My guess is that its related to gcc rewriting parts of its constant folding code to support constexpr. -- Stirling Westrup Programmer, Entrepreneur. https://www.linkedin.com/e/fpf/77228 http://www.linkedin.com/in/swestrup http://technaut.livejournal.com http://sourceforge.net/users/stirlingwestrup

4 6

TR1 and BOOST_HAS_GCC_TR1
by Mathias Gaunard 06 Mar '11

06 Mar '11

With GCC, TR1 only calls the native TR1 implementation if BOOST_HAS_GCC_TR1 is defined. Isn't it time we get rid of this macro?

2 3

[regex] embed string/char in regex w/o escaping?
by Arno Schödl 06 Mar '11

06 Mar '11

As far as I can see, there is no way to embed a plain string into a regex, without escaping the string. Same with characters. Isn't that a bad omission for a library that becomes the new C++ standard? Escaping something just to unescape it on the other end of the function call seems unnecessary, and it opens up the possibility of ills like regex code injection if someone forgets to escape or does it wrong. I know about Boost.Xpressive, but that won't be the new standard. This is not a lobbying effort for Boost.Xpressive. I have never used it precisely because I wanted to stick to the standard. Now I am a bit worried about pouring something into C++ standard concrete that has a pretty obvious omission in it. Arno -- Dr. Arno Schödl | aschoedl(a)think-cell.com Technical Director think-cell Software GmbH | Chausseestr. 8/E | 10115 Berlin | Germany http://www.think-cell.com | phone +49 30 666473-10 | US phone +1 800 891 8091 Amtsgericht Berlin-Charlottenburg, HRB 85229 | European Union VAT Id DE813474306 Directors: Dr. Markus Hannebauer, Dr. Arno Schoedl

4 5