- Boost - lists.preview.boost.org

[Review] Phoenix V3: review results
by Hartmut Kaiser 09 Mar '11

09 Mar '11

All, The review of Phoenix V3 ended on March 2nd. We've got quite some discussion, even if we hoped for more. Overall, 3 people have confirmed that the Phoenix rewrite addresses all issues raised during the original review back in 2008. Nobody raised any concerns or serious issues. So here is the result of the mini-review: Boost.Phoenix is ready to be moved to the Boost SVN trunk! All other discussions were about minor inconsistencies, which Thomas has already fixed by now. There are a couple of suggestions related to the documentation, which he agreed to address as soon as possible: 1) The Phoenix documentation should have a "What's New" section 2) Compile time is often a concern with libraries that make heavy use of expression templates. Adding a compile time test would be ideal. This should be easily invoked and results from various compilers reported within the documentation. The only thing, which needs to be decided (and which has not been discussed yet) is how the migration from Boost.Bind, Boost.Lambda, and Phoenix V2 has to be organized, ensuring minimal disruption for the users of those libraries. I see several possible ways of doing so, but would like to open up the discussion. Any suggestions and comments are welcome. With high likelihood this migration process will be implemented using forwarding headers. Therefore, this point has not to be resolved before moving the main code base to trunk. On the other hand, this migration strategy needs to be in place before merging to the release branch. -------------------- This mini-review wraps up the review process of Boost.Phoenix. Congratulations to Thomas for this version of the excellent library, which will contribute to the unification of the functional landscape in Boost. At the same time I would like to mention a couple of names which are related to the development of Phoenix since its inception, and without those Boost.Phoenix wouldn't have happened. - Joel de Guzman, who wrote the initial V1 and since then was actively involved and driving the development of Boost.Phoenix - Dan Marsden, who is the main developer (with Joel) of Phoenix V2 - Angus Leeming and Daniel Wallin who contributed to V2 - Eric Niebler, the author of Boost.Proto, who contributed to V2 and was actively driving and supporting the development of V3, he also mentored Thomas Heller's GSoC project. Regards Hartmut Review Manager --------------- http://boost-spirit.com

6 5

[config][clang] Does <boost/config/compiler/clang.hpp> need updating?
by Beman Dawes 09 Mar '11

09 Mar '11

http://clang.llvm.org/cxx_status.html now has a table for C++0x features. rvalue references, variadic templates, and static_asserts are showing as green. Does <boost/config/compiler/clang.hpp> need updating? Is there a maintainer for <boost/config/compiler/clang.hpp>? --Beman

6 15

[move] You can do it better: implementing push_back and handling implicit conversions
by Ion Gaztañaga 09 Mar '11

09 Mar '11

Hi to all, Are you a C++ expert? Do you like Boost.Move? I have a challenge for you. During Boost.Move review, Jeffrey Lee Hellrung suggested adding "techniques to capture (implicitly created) rvalues with emulated rvalue references in C++03, e.g., for push_back, when you have knowledge of the types of objects you want to capture". I've worked on this problem these days and the solution is less than obvious (several compilers have has problems with ::boost::is_convertible and non-copyable types). I found a solution (attached test and required boost/move/move.hpp header) after several tries but it's complex (it needs several overloads and enable_if tricks) but I'm sure boosters will find a easier solution ;-) Current solution seems to work on these compilers: MSVC 7.1, 8.0, 9.0, Intel 11.0, GCC 4.3.4, 4.4, 4.4 c++0x mode, 4.5, 4.5 c++0x mode. Problem: MSVC 10.0 (Visual 2010) with real rvalue references seems to have bugs and does not compile the test. I can't find a workaround, a future Service Pack might solve these errors, but maybe we should stick to emulation code in this compiler, unless someone could shed some light on this, of course. Waiting your proposals, Ion

3 6

[iostreams][filesystem] v3 adapter uploaded to ticket #4485
by Jeff Flinn 09 Mar '11

09 Mar '11

I've uploaded an adapter allowing filesystem V3 path to be passed to the iostreams library constructors and methods taking paths. I'm using it with boost 1.44 on MSVC8 and Xcode3.1.2 with gcc4.0.1. It currently requires that BOOST_FILESYSTEM_VERSION is defined to be 3, and that users manually use the adapter like: #include <boost/iostreams/device/mapped_file.hpp> #include <boost/iostreams/filesystem_v3_path_adapter.hpp> ... boost::filesystem::path p(...); namespace io = boost::iostreams; io::mapped_file_source mf_src(io::filesystem_v3_path_adapter(p)); Filesystem V3 is deprecated in the upcoming boost 1.47, and will NOT be included in boost 1.48. Has anyone started updating iostreams to account for the removal of filesystem V2? IIRC, Steven Watanabe has been doing some iostreams maintenance. It looks like Jonathan Turkanis is no longer around, is there a new iostreams maintainer? I can take this on if no one else is/has. In my view, and as a few others have stated as well, filesystem V3 path is the common/portable path currency in boost today. The iostreams interface/implementation can be simplified by utilizing path's portability. The windows implementation would always call CreateFileW passing path.wstring().c_str. Thoughts? Thanks, Jeff

2 1

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