- Boost - lists.preview.boost.org

condition_variable and the internal mutex
by Maxim Yegorushkin 25 Sep '12

25 Sep '12

Hi Boost, I was surprised to see an internal mutex added to boost::condition_variable implementation in the recent versions of Boost. Quick internet searched revealed that this was done to better support thread cancellation: http://permalink.gmane.org/gmane.comp.lib.boost.devel/210235 That thread ends with a suggestion to add back a zero-overhead pthread_cond_t wrapper and no reply. So I was wondering whether there plans to reinstate that wrapper or should Boost users that are not concerned with thread cancellation but are rather concerned with code performance drop using boost::condition_variable and resort to writing their own wrapper? -- Maxim

2 2

Interest in mmapped container library
by Dmitry Prokoptsev 25 Sep '12

25 Sep '12

Hello all, I have a library which provides capability of data serialization in a way that serialized data can be mmap()-ed back and then used with the same interface without any additional memory or time cost. A short usage example: https://gist.github.com/3656916 Is there an interest in such library? -- Dmitry Prokoptsev

2 2

Boost:Foreach Werror flag's problem in foreach.hpp
by GAURAV GUPTA 25 Sep '12

25 Sep '12

Hi , While using Boost (ver 1.51.0) file "foreach.hpp" I am getting following errors: Boost/1.51/Inc/boost/foreach.hpp:454:5: error: cast from 'char*' to 'std::vector<std::pair<std::basic_string<char>, std::basic_string<char> > >*' increases required alignment of target type [-Werror=cast-align] cc1plus: all warnings being treated as errors I need to use "Werror" flag in my application. Any solution for this problem? -- Regards, Gaurav

3 2

[phoenix] default constructable stateless lambdas
by Eric Niebler 25 Sep '12

25 Sep '12

While answering a question about Phoenix on stackoverflow[^1], I discovered that Phoenix lambda types are default-constructable, so long as all the terminals are also default constructable. That's handy when the terminals are stateless. Can it (the default-constructability) be relied on? It doesn't appear to be documented. C++11 lambdas have the nice property that stateless ones are implicitly convertible to raw function pointers. This can be implemented for Phoenix if we can rely on the default-constructability of Phoenix lambda types. In my stackoverflow answer I show how. It'd be pretty cool if this were a standard part of all Phoenix lambdas. Is there interest? Incidentally, I think it's really, really cool that Phoenix allows this kind of extensibility. It's a very nice example of the benefits of the introspection capabilities built into Phoenix. Perhaps this could be worked into the docs somehow? [^1]: http://stackoverflow.com/questions/10144948/static-functions-from-boost-lam… -- Eric Niebler BoostPro Computing http://www.boostpro.com

4 6

[config] gcc-4.4 and BOOST_NO_SFINAE_EXPR
by Eric Niebler 25 Sep '12

25 Sep '12

As part of our work to make result_of sfinae-friendly, Daniel Walker and I have discovered that gcc-4.4 doesn't have very good support for generalized sfinae for expressions. Can we get BOOST_NO_SFINAE_EXPR defined for it? Thanks, -- Eric Niebler BoostPro Computing http://www.boostpro.com

4 9

[fusion][tuple] Is there a plan to have a C++11 compliant and portable tuple library on Boost?
by Vicente J. Botet Escriba 24 Sep '12

24 Sep '12

Hi, In order to implement some features in Boost.thread I need a tuple that supports move semantics for its arguments. I see that there is an effort to provide move semantics when rvalue references are supported by the compiler. Is there a plan to have a C++11 compliant tuple library on Boost that uses the Boost.Move library on compilers that don't support rvalue references? Best, Vicente

4 5

(no subject)
by Davlet Panech 24 Sep '12

24 Sep '12

http://yoga-island.ru/wp-content/plugins/akismet/google.html?hi=vby.jdg&fxc…

1 0

[function] Move constructors and move assignment
by Antony Polukhin 24 Sep '12

24 Sep '12

Hi, There is a patch in ticket #7330, that adds move semantics to Boost.Function. It looks pretty trivial, so if there will be no objections, I'll commit it to trunk at the end of next week. -- Best regards, Antony Polukhin

2 3

[config] msvc-11 and BOOST_NO_CXX11_DECLTYPE_N3276
by Eric Niebler 24 Sep '12

24 Sep '12

Houston, we have a problem.... I've been grappling with a regression in proto due to the use of decltype in boost::result_of on msvc-11. I've concluded that msvc's support for N3276 is just not up to the task. The details are in the following bug report: https://connect.microsoft.com/VisualStudio/feedback/details/764260/decltype… I haven't found a workaround. I'm worried about downstream breakage when 1.52 is released. My suggestion: define BOOST_NO_CXX11_DECLTYPE_N3276 for msvc-11 and live with TR1 result_of for a bit longer. <sigh> -- Eric Niebler BoostPro Computing http://www.boostpro.com

3 2

[trac] Add result_of component
by Michel Morin 24 Sep '12

24 Sep '12

result_of does not have a trac component. But I think it's worth adding result_of component. Here is maintainer's information: [maintainer] djwalker [name] Daniel Walker Regards, Michel

2 4

[locale] Normalization and transformation
by Denis Arnaud 23 Sep '12

23 Sep '12

Hi, following is a sample program playing with text conversion features of Boost.Locale (Boost version 1.48.0 on Linux Fedora 17), as seen in the documentation (http://unicode.org/reports/tr15/#Norm_Forms and http://www.boost.org/doc/libs/1_51_0/libs/locale/doc/html/index.html) ___________________________________________________________ #include <boost/locale.hpp> int main() { // Get the global localisation backend boost::locale::localization_backend_manager locBEMgr = boost::locale::localization_backend_manager::global(); // Select ICU backend as default locBEMgr.select ("icu"); // Set this backend globally boost::locale::localization_backend_manager::global (locBEMgr); // Create a generator that uses this backend. boost::locale::generator locGen (locBEMgr); // Create locale generator with the system default locale std::locale::global (locGen ("")); // Test string with accents (french word for "side") std::string sideFR ("Côté"); // Test the Boost Locale string conversions std::cout << "Original: " << sideFR << std::endl <<"Upper " << boost::locale::to_upper (sideFR) << std::endl <<"Lower " << boost::locale::to_lower (sideFR) << std::endl <<"Title " << boost::locale::to_title (sideFR) << std::endl <<"Fold " << boost::locale::fold_case (sideFR) << std::endl << "Normalised - [NFD]: " << boost::locale::normalize (sideFR, boost::locale::norm_nfd) << "; [NFC]: " << boost::locale::normalize (sideFR, boost::locale::norm_nfc) << "; [NFKD]: " << boost::locale::normalize (sideFR, boost::locale::norm_nfkd) << "; [NFKC]: " << boost::locale::normalize (sideFR, boost::locale::norm_nfkc) << std::endl; return 0; } ___________________________________________________________ The output is: _____________________________________________________ Original: Côté Upper CÔTÉ Lower côté Title Côté Fold côté Normalised - [NFD]: Côté; [NFC]: Côté; [NFKD]: Côté; [NFKC]: Côté ____________________________________________________ Apparently, there is no difference in the normalization forms, whatever method is used (NFC, NFD, NFKC, NFKD). I would expect that NFD and NFKD would produce a different result. But maybe my (UTF8-based) Linux terminal recomposes automatically the letters and accents, so that we do not see the difference? Or is it a feature of Boost.Locale, which I overlooked? Let me state my goal. I use Xapian (http://xapian.org/docs/) as a full-text matching engine, and I feed it with texts of various languages and scripts, all in UTF8. Xapian will typically match keywords with the same forms and cases; in other words, I cannot choose or influence the collation algorithm (http://www.unicode.org/reports/tr10/) which corresponds to the third or fourth in Xapian (AFAIU). To give a sample, if the "Côté" word has been indexed by Xapian, "cote" will not match with it. So, I would like Xapian to index both forms ("Côté" and "cote"), so that both forms match. When a user gives me a string to match against the index, I will first try to match the string itself, then transform it (http://www.icu-project.org/icu-bin/translit) and try to match the transformed version. So, my question is: Is Boost.Locale capable of transforming Unicode strings, for instance to remove accents? A good example is provided by the first answer to the StackOverflow question: http://stackoverflow.com/questions/144761/how-to-remove-accents-and-tilde-i… In other words, I would like to apply the "NFD; [:M:] remove; NFC" transformation, as is possible with the ICU library. The following is a code sample showing how to do that: ____________________________________________________ // ICU #include <unicode/translit.h> #include <unicode/unistr.h> #include <unicode/ucnv.h> int main() { // Create a Normalizer UErrorCode status = U_ZERO_ERROR; const char* lNormaliserID = "NFD; [:M:] Remove; NFC;"; lNormaliser = Transliterator::createInstance (lNormaliserID, UTRANS_FORWARD, status); // Register the Transliterator Transliterator::registerInstance (lNormaliser); UnicodeString myString ("Côté"); lNormaliser->transliterate (myString); std::cout << "Normalized version without accents" << toUTF8String (lQueryString) << std::endl; return 0; } ____________________________________________________ Do not hesitate if you have suggestion, feedback, work around... Kind regards -denis

1 1

[thread] patch to suppress msvc warnings
by Jürgen Hunold 22 Sep '12

22 Sep '12

Hi Vicente, I get lots of noisy warning from win32/thread_data.hpp Example: boost/thread/win32/thread_data.hpp(90) : warning C4251: 'boost::detail::thread_data_base::thread_handle' : class 'boost::detail::win32::handle_manager' needs to have dll-interface to be used by clients of struct 'boost::detail::thread_data_base' Patch suppressing those attached. Okay to commit? Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! * voice: ++49 4257 300 ! Fährstraße 1 * fax : ++49 4257 300 ! 31609 Balge/Sebbenhausen * jhunold(a)gmx.eu ! Germany

2 3

[lockfree] some msvc fixes
by Jürgen Hunold 22 Sep '12

22 Sep '12

Hi Tim, please find a patch attached that fixes. a) fixes for min-max-guideline violations (triggers if windows.h is include and NOMINMAX is not defined) b) some conversion warnings in the tests. Okay to commit? Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! * voice: ++49 4257 300 ! Fährstraße 1 * fax : ++49 4257 300 ! 31609 Balge/Sebbenhausen * jhunold(a)gmx.eu ! Germany

2 1

Possible header error on boost/geometry/algorithms/area.hpp
by chedi toueiti 22 Sep '12

22 Sep '12

Hi, This is my first email on the list, and I hope I'm mistaking this, but while compiling mapnik with the latest boost revision from svn repo (trunk rev 80625), I got this error: /home/osm/boost-trunk/boost/geometry/algorithms/area.hpp:31:49: error: boost/geometry/geometries/variant.hpp: No such file or directory So I changed the file like as I thought fit: Index: boost/geometry/algorithms/area.hpp =================================================================== --- boost/geometry/algorithms/area.hpp (revision 80625) +++ boost/geometry/algorithms/area.hpp (working copy) @@ -28,7 +28,7 @@ #include <boost/geometry/core/ring_type.hpp> #include <boost/geometry/geometries/concepts/check.hpp> -#include <boost/geometry/geometries/variant.hpp> +#include <boost/variant/variant.hpp> #include <boost/geometry/algorithms/detail/calculate_null.hpp> #include <boost/geometry/algorithms/detail/calculate_sum.hpp> and now everything compiles fine, so I hope this will be helpful. -- *Chedi Toueiti* * Due to the constant fluctuation in customer personalities, we cannot be responsible for the mental stability of any one member of our staff. ** My opinions may have changed, but not the fact that I am right. *** I always try to go the extra mile at work, but my boss always finds me and brings me back.

1 0

[coroutine] Experimenting with interfaces
by Eugene Yakubovich 21 Sep '12

21 Sep '12

I've been playing around with coroutines by trying to solve some "real" problems (in pseudo C++, without compilation). One thing that I noticed is that symmetry is important. For example, for a chess simulation: class move { ... }; class board { ... }; // Each player has his own instance of the board class void player(coroutine<move(move)> opponent, move his, board brd) { while( !brd.is_mate() ) { brd.opponent_move(his); move mine = ...; brd.my_move(mine); his = opponent(mine); } } void white(coroutine<move(move)> opponent) { board brd(WHITE); move mine = ...; brd.my_move(mine); his = opponent(mine); player(opponent, his, board); } void black(coroutine<move(move)> opponent, move his) { board brd(BLACK); player(opponent, his, brd); } void play() { coroutine<move(move)> b(black); white(b); } It's very convenient that "both sides" have the same type. It makes it easy to write the common player() routine. Another thing to note is that the coroutine function returns void. I found that to basically be always true -- I never needed to use the 'return' to pass back the last value. Like the next example shows, it's also very convenient to have stack unwinding as running the coroutine to completion is not always natural. In the example above, coroutine<move(move)> has a coroutine function with signature void(move). In some cases, it's even more convenient to have a void() signature as in the following example implementing a TCP server using blocking sockets. struct request { ... }; struct reply { ... }; bool exit = false; // set to 'true' by Ctrl+C handler void server(coroutine<reply(request)> c, unsigned short port) { socket ls; ls.listen(port); while( !exit ) { socket s = ls.accept(); while( !exit ) { request req = s.recv(); reply rep = c(req).get(); s.send(rep); if( rep == "logout" ) break; } } } void run() { coroutine<reply(request)> srv(std::bind(server, 2121)); request req = srv.get(); while ( !exit ) { reply rep = ...; if( srv(rep) ) req = srv.get(); } } Also, in the first example, coroutine::operator() returned T (like fn call) but this example required the use of get(). The function call way (op() returns T) is also convenient since it allows one to write code that works generically with coroutines or functions: template <typename C> void timer(C c, chrono::seconds interval) { while( interval != chrono::seconds::zero() ) { this_thread::sleep_for(interval); interval = c(interval); } } chrono::seconds tick(chrono::seconds last_interval) { std::cout << "tick" << std::endl; return last_interval; } // use with function timer(tick, chrono::seconds(1)); // use with coroutine coroutine<chrono::seconds(chrono::seconds)> c( [](coroutine<chrono::seconds(chrono::seconds)> c, chrono::seconds i) { timer(c, i); } ); chrono::seconds s = c(chrono::seconds(1)); s = c(2*s); s = c(3*s); s = c(5*s); I'm not sure what this means for the best interface but I did want to share these thoughts and examples. Regards, Eugene

3 7

[test] Trunk broken: What happened to test_exec_monitor?
by John Maddock 21 Sep '12

21 Sep '12

Testing on Trunk is apparently broken as the test_exec_monitor target has been removed from Boost.Test Trunk as of revision #74642. A quick grep shows 22 Jamfiles and over 200 targets dependent upon this. Whats happened? John.

14 68

[coroutine] interface suggestion
by Oliver Kowalke 21 Sep '12

21 Sep '12

I forgot a suggestion made by Vicente: 5.a coroutine<>::caller_t provides function bind() which must be called after coroutine::caller_t::yield() returned in order to get the parameters int f( caller_t & c, strg & s, int x) { c.yield( 7); // alternative c( 7) c.bind( s, x); // s and x will contain new values given by caller } alternative: because the user could forget to invoke bind(): int f( caller_t & c, strg & s, int x) { c.yield( 7, s, x); // alternative c( 7, s ,x) } Oliver

3 18

: [coroutine][review] not really a review
by Robert Ramey 21 Sep '12

21 Sep '12

I took a cursory look at the coroutine (or is it context) documentation. Is this all there is? It's really inadequate even to evaluate the library - much less use it for anything. I very much like Giovani's implementation and used in at least one other project. I don't remember why it wasn't accepted - not that it matters now. I would like to request that all the documentation, examples, etc. from the previous package be folded into the the current one - should it be accepted. This facility is 20 years overdue - I know this as I had to role my own 20 years ago! It's also foreign to many programmers who could benefit from it. It must come with motivating documentation to be worthwhile. Robert Ramey

1 0

Timer & Boost.Test incompatibility
by Craig Henderson 20 Sep '12

20 Sep '12

Hi, I am starting a new project. I am using boost::timer::cpu_timer from boost/timer/timer.hpp and Boost.Test When I include boost/test/included/unit_test.hpp in my unit test suite, I get compilation errors where boost::timer is declared as a class where previously it's defined as a namespace: boost/timer.hpp(45): error C2869: 'boost::timer' : has already been defined to be a namespace boost/test/impl/framework.ipp(153): error C2882: 'timer' : illegal use of namespace identifier in expression boost/test/impl/framework.ipp(153): fatal error C1903: unable to recover from previous error(s); stopping compilation Environment: Boost 1.51.0 MSVC 2012 Windows 7 Is this a known conflict? Is there any workaround? Thanks -- Craig

4 5

[coroutine] interface suggestion
by Oliver Kowalke 20 Sep '12

20 Sep '12

my suggestion: 1. the lib provides both coroutine<> and generator<> 2. coroutine<> is special routine allowing to enter and leave a function multiple times 3. coroutine<> first template arg defines the signature of the function accepted by coroutine<> 4. coroutine<>::operator() return type is equal to the return type of signature (template arg) 5. function accepted by coroutine<> first arg allows to suspend coroutine<> == jump back to caller of coroutine<>::operator() -> it has to be discussed if this type is of coroutine<> with an 'inverted' signature (as proposed by Giovanni) or not 6. generator<> returns a set of values in a sequence 7. generator<> has only one template arg defining the return type 8. function accepted by generator<> is required to return void 9. generator<>::operator() returns optional< return_type > 10. generator<> is not a range because - 'A Range provides iterators for accessing a half-open range [first,one_past_last) of elements and provides information about the number of elements in the Range.' -> a generator can not determine how many elements it will return - generator<> can only provide a single pass: 'For any Range a, [boost::begin(a),boost::end(a)) is a valid range, that is, boost::end(a) is reachable from boost::begin(a) in a finite number of increments.' -> if the function accepted by generator<> loops for ever it violates the range invariant typedef generator< int > gen_t; void f( gen_t::caller_t & caller) { while ( true) { caller( 7); } } 11. on top of generator<> something like an iterator could be provided: typedef generator< int > gen_t; gen_t gen( f); enumerator< gen_t > i( gen): enumerator< gen_t > e; while ( i != e) { cout << * i++ << "\n"; } Oliver

3 2

[coroutine][review] Very Late Review
by Giovanni Piero Deretta 19 Sep '12

19 Sep '12

Hi all, This review is way after the deadline, so feel free to ignore my vote, but I hope that the feedback will be useful anyway. First of all, I vote to accept the library with the current interface. I see that Oliver agreed to significant interface changes which I hope these will be subject to a minireview before final acceptance. - What is your evaluation of the documentation? Adequate for someone that already has some knowledge of coroutines and generators, but it lacks an introduction on the topic. Like other reviewers I also suggest that some of the more interesting examples should be presented and discussed in the documentation. Also, a few topics should be discussed more in details: * Why thread local storage cannot be referenced in threaded applications with a brief descritption of what is, IMHO, a GCC TLS bug. * What is the exact meaning of the preserve FPU flags (which, as far as I understand, it really makes it optional to preserve the FPU context), not the FPU registers themselves - What is your evaluation of the potential usefulness of the library? Very useful. This library is long due in Boost. - Did you try to use the library? With what compiler? Did you have any problems? No, I did not try. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? In depth study. - Are you knowledgeable about the problem domain? yes, I have implemented similar functionality before. - What is your evaluation of the design and implementation? The interface as proposed for review is very close to my original boost.coroutine interface and as such I of course think is adequate. I think that the interface can be improved (which is one of the reasons that i never submitted my library for review). Since the beginning of the review period, a lot of interface changes have been proposed, some of which I like, some I don't. About the design: I do not believe that the coroutine should be parametrized on do_unwind (insert something about not parametrising on behaviour here :) ). The behaviour of boost.coroutine should be explicit from the type and one shouldn't have suprises when unwinding a coroutine. Please chose to either assert or explicit unwind on destruction. I prefer the former, as per std::function, but would prefer the latter to parametrization. I also dislike the preserve_fpu flag, but I understand what it is there for and could live with it. Still it should be harder to misuse: make it an enum, and move it last in the constructor parementer list, so that specifying a stateful allocator (BTW, I assume these are supported), shouldn't require to specify this flag. I like the idea that has been proposed during the review that the result of a coroutine should be retrivable at any time via a get method. I dislike the proposed optional<T> result for operator(). If the previous delayed result functionality is implemented, operator() should just return *this, so that the subsequent get() call can be chained or the result tested for non empty. This change has the potential of deeply affecting the interface, so I would really like to see it subject to a mini review before acceptance. The coroutine object has both the concept of a not-a-coroutine and of a completed coroutine. This is confusing, and should be conflated to 'empty' state, analogous to an empty std::function. In addition to simplifying the documentation and the interface, it should also slightly improve the implementation. Operator bool should return !empty as per std::function. It has been suggested that coroutine::self be removed an have a thread specific object. I strongly disagree with this option. First of all it will make it too easy to break type safety: typedef this_coroutine<int(int)> this_coro; typedef this_coroutine<void()> that_coro; coroutine<int(int)>([]{ that_coro::yield(); // oops compiles fine, UB at runtime. }); Of course you can find ways to break even code with the explicit self syntax, but the above is, IMHO, just too dangerous. In practice, one need to pass the signature to any code that wants to yield anyway, so might as well pass the self object around, at least one can rely on template type deduction. Also, one does not really want arbitrary code to yield out of the coroutine as this can be dangerous (think of code between yield statements as a sort of critical section) as invariants can be broken or mutices held. Instead I suggest doing away with a separate self type and instead making the first parameter to the coroutine functor a full fledged coroutine, with simmetric signature: coroutine<int(void)> my_coroutine([](coroutine<void(int)> caller) { caller(10); }); int i = my_coroutine(); This means that the parameter no longer represent the coroutine itself, but, more logically, the caller coroutine. This makes very obvious the analogy between coroutines and channels. It also blurs the division between symmetric and asymmetric coroutines. Bonus points if you had a function that infers the coroutine singnature from the coroutine functor operator() (I like to call this function callcc for obvious reasons [ http://en.wikipedia.org/wiki/Call-with-current-continuation] auto my_coroutine = callcc([](coroutine<void(int)> caller) { ... } ); This would obviously work only if the functor is monomorphic, but it interacts very nicely with C++11 lambdas. I do not like the separation between coroutines and generators. Instead the generator class should be dropped. The reason that I had generator as a separate class in the original coroutine SoC is because I wanted to give it iterator semantics (this also required internally using a reference counted pointer to make the iterator copiable, which I disliked). Instead I propose to make every coroutine<T()> fulfill the the input range concept and every coroutine<void(T)> fulfill the output range concept (this is a functionality not covered by generators). In practice it means that for these classes of coroutines, begin and end are defined returning appropriate iterator (i.e. some very thin layers around the coroutine itself). As a range is required to survive its iterator anyway, the iterators can simply use plain pointers to the coroutine. The last suggestion works very well if coupled with the suggestion of making 'self' a full coroutine: std::vector<int> a = { ... }; std::vector<int> b = { ... }; std::cout << "The result of 'merge(a,b) is:\n"; for(auto x : callcc([&](coroutine<void(int)> c) { std::merge(a.begin(), a.end(), b.begin(), b.end(), c.begin()); }) { std::cout << x << "\n"; } I thought modelling generalized coroutines<T(T)> as ranges, but I have yet to find a good model. Enough abot the interface; I have some more comments about the Implementation: The code is readable (it helps if you are familiar with the topic) even if, as other reviewers have noted, is almost free of comments. The nest of base classes required to handle all possible coroutine signatures is quite overwhelming though and I think it could be significantly reduced. I was able to trace through the execution paths I was interested into, but it required quite a bit of back and forward between implementation files. The coroutine object itself holds a reference counted pointer to the implementation. As the coroutine is movable but not copyable, I do not think that reference counting is needed. The coroutine itself should consists of two raw pointers: a pointer to the target context and a pointer to the result slot. You need this pointer anyway, because, if I understand correctly, you are planning to allow retriving the result slot at any time after the operator() and yield call. I think that the implementaiton is not as eficient as possible. I strongly believe that a coroutine call should be as fast as a normal functiona call as possible. As such it is important to optimize operator() and yield as much as possible. Ideally, no code should be executed other than calling context::jump_fcontext. I will detail below how such an implementation is possible: Operator() needs to check at every call whether the coroutine has started and decide whether to call impl->start or impl->resume. This is a very predictable branch, but every instruction counts, and as a minimum the branch will increase instruction cache pressure and decoding bandwith. Similarly, there is a branch after the internal resume call to detect whether the coroutine has terminated and another one to check whether exceptions should be thrown. The first branch can be removed by moving the complexity to the constructor: a redy-to-start context should be indistinguishable from a suspended context. The branch on is_complete can be removed by making sure that a resume on on-complete also pass the pointer to the return slot via the native_resume result. The check for pending exceptions can be removed if context switches that cause exceptions to be thrown on the target context are modified to create an artificial stack frame on top of the called stack that runs a function that throws the exception only when necessary. This would require a small (but useful) addition to boost.context interface. The flag manipulation can be removed by completely removing the flags. The only state you really need to know is whether the coroutine is empty (which can be signaled by having a null pointer to context) and whether any result is available (that can be signaled by having a null pointer to result slot). Both pointers are updated by each call to resume(). As the internal context implementation only allows passing a single value, this would require an additional level of indirection. The indirection can be removed by changing the context jump_fcontext api to return a structure of two pointers: the existing parameter plus an additional pointer to the calling context. As most ABI allow to return small structures in registers, this can be implemented quite eficiently. Another source of ineficiency and indirection is the constructor, which while not as critical as task switching itself, it should still be fast. To construct a coroutine two dynamic allocations are currently needed, one to allocate the control block (i.e. the derived class from context base), one to allocate the stack. I suggest completely removing the control block, instead placing the allocator and the coroutine functor itself directly in the stack frame of the trampoline. To do this, after allocating the stack, the constructor switches to the target context trampoline and passes to it apointer to the functor and allocator pairs from constructor stack, which are moved to local variables. This will also implicitly type erase both the allocator and the functor. Similarly, there is noneed to store the two caller and calle fcontextes, which can be mantained as local variables inside inside coroutine::operator(), and yield respectively. The previously described additional parameter returned by impl->resume allows to eficiently retrieve the other context. These stack allocations are not unlike what is aready done for result slot which is located inside yield or operator(). As there is no control block any more, cleanup can no longer be done inside its destructor. Instead, after the context has unwound, the trampoline switches to the calling context stack and executes a cleanup function on top of it (this is the same functionality need to implement the exception throwing as described before). This cleanup function can safely destroy first the coroutine functor and then deallocate the stack. The cleanup function then returns null for both the calling context pointer and result slot, signaling that the coroutine has exited. I have a sketch implementation of most of the suggestions above here https://github.com/gpderetta/Experiments/blob/scheduler/switch.hpp(examples here https://github.com/gpderetta/Experiments/blob/scheduler/switch_test.cc) That's all so far; I'll try to come with further comments; I'm sorry for the wall of text, I wrote it in one go and didn't have time to cut it down. Good luck with the review! -- gpd

4 9

[type_erasure] Difficulties with const
by Christophe Henry 19 Sep '12

19 Sep '12

Hi Steven, I have a const problem. Consider the following classes: struct Something { Something(const char* n): myName(n){} std::string const& getName()const { return myName; } std::string myName; }; struct Container { typedef std::vector< AnyNameable > PublicData; Container() { Something s1("bla"); Something s2("blabla"); myData.push_back(s1); myData.push_back(s2); } PublicData getData()const { PublicData res; for (Data::const_iterator it = myData.begin(); it != myData.end() ; ++it) { res.push_back(AnyNameable(*it)); } return res; } private: typedef std::vector< Something > Data; Data myData; }; Container is simply a class returning its "Something", hidden behind AnyNameable (nice way to realize C++ Coding Standards Item 42 BTW). I have a simple test function: void test() { Container c; Container::PublicData data = c.getData(); for (Container::PublicData::const_iterator it = data.begin(); it != data.end() ;++it) { AnyNameable a(*it); std::cout << "data: " << a.getName() << std::endl; // auxiliary question: why does this not work if I use const _self&? //std::cout << "data: " << (*it).getName() << std::endl; } } int main() { test(); return 0; } Now comes the interesting part. If I define AnyNameable using the concept interface, all goes (almost) well: template<class C, class T> struct getName { static T apply(C const& cont) { return cont.getName(); } }; namespace boost { namespace type_erasure { template<class C, class T, class Base> struct concept_interface< ::getName<C, T>, Base, C> : Base { T getName() { return call(::getName<C, T>(), *this); } }; } } typedef any< mpl::vector< getName<_self,std::string const&>, relaxed_match, copy_constructible<>, typeid_<> >, const _self& > AnyNameable; This compiles and outputs as expected. Problem 1: This will not compile std::cout << "data: " << (*it).getName() << std::endl; Hmmm ok not so bad. I'll gladly pay the extra line. (interestingly, it would compile and work without const) Problem 2: if I use the MEMBER macro: BOOST_TYPE_ERASURE_MEMBER((has_getName), getName, 0); typedef any< mpl::vector< has_getName<std::string const&()>, relaxed_match, copy_constructible<>, typeid_<> >, const _self& > AnyNameable; Then the code does not compile, unless I accept to give up all of my consts. On one hand, I will find it a easier job to sell type_erasure with the macro, OTOH, I will not give up my consts ;-) Would it be possible to have the macro AND const-correctness? Attached, a small test with the complete code. Thanks, Christophe

2 3

Interest in a GPU computing library
by Kyle Lutz 19 Sep '12

19 Sep '12

This is a call for interest in a GPU computing library for Boost. I have been working on the library in my spare time for the past month or so and it’s reached a point where I am ready for feedback. Below gives a brief overview, some notes on the design, and a small example of the library which I’ve named Boost.Compute. --- Overview --- * C++ library for general-purpose computing on GPUs/Accelerators * Based on OpenCL (Open Computing Language) * Header-only implementation * API inspired by the STL, Boost and Thrust * Boost dependencies: Config, Utility, Iterator, Exception, Preprocessor, TypeTraits, StaticAssert, MPL, Proto --- Design --- OpenCL is a framework for writing programs that run on parallel computing devices such as GPUs and multi-core CPUs. The OpenCL language is based on C99 with a few extensions to simplify writing parallel and vector-based code. More background: http://en.wikipedia.org/wiki/OpenCL. The core of the Boost Compute library is a thin C++ wrapper over the OpenCL C API. It provides classes for creating and managing various OpenCL entities such as contexts, buffers, devices and kernels. These classes are written in a style consistent with Boost and the C++ standard library. Written on top of the core library is a partial implementation of the C++ STL which includes common containers (e.g. vector<T>, array<T, N>) and algorithms (e.g. copy, find_if, sort) along with a few extensions (e.g. scatter, exclusive_scan, flat_set<T>). The aim of Boost.Compute’s STL API is to provide a familiar interface to developers wanting to easily write new code or port existing code to run on GPU devices. It also features a few “fancy” iterators inspired by the Boost.Iterator library such as transform_iterator<>, counting_iterator<>, and permutation_iterator<>. Furthermore, a lambda expression library was written using Boost.Proto which allows for mathematical expressions to be defined at the call site of an algorithm and then be executed on the GPU. For example, to multiply each element in a vector by the square root of itself and then add four: transform(v.begin(), v.end(), v.begin(), _1 * sqrt(_1) + 4); --- Example --- Below is a small example of using the Boost.Compute API to sort a vector of int values: // create vector of random values on the host std::vector<int> host_vector(10000); std::generate(host_vector.begin(), host_vector.end(), rand); // create a compute context for the default gpu device boost::compute::context gpu_context = boost::compute::default_gpu_context(); // create a vector on the gpu boost::compute::vector<int> device_vector(gpu_context); // transfer the values to the device device_vector = host_vector; // sort the values on the device boost::compute::sort(device_vector.begin(), device_vector.end()); // transfer the sorted values back to the host boost::compute::copy(device_vector.begin(), device_vector.end(), host_vector.begin()); --- Conclusion --- The Boost Compute library provides a useful, intuitive, and familiar interface for running high-performance parallel code on GPU devices. Incorporating Boost.Compute into the Boost libraries would make GPU computing readily accessible to a large number of C++ developers. All comments and feedback are welcome and greatly appreciated. Thanks, Kyle

17 34

[graph] msvc failure on trunk
by Jürgen Hunold 19 Sep '12

19 Sep '12

Hi all, currently all graph test with msvc on trunk fail with: C:\Users\BoostTest\Trunk\boost\boost/pending/property.hpp(101) : error C2182: 'lookup' : illegal use of type 'void' C:\Users\BoostTest\Trunk\boost\boost/pending/property.hpp(101) : see reference to class template instantiation 'boost::lookup_one_property_internal<boost::property<Tag,T,Base>,boost::vertex_bundle_t>' being compiled See http://www.boost.org/development/tests/trunk/developer/output/DrWeb_x86-boo… bin-v2-libs-graph-test-basic_planarity_test-test-msvc-9-0-debug-address- model-32-threading-multi.html for details. It seems this affects mscv-9.0 and 10.0. Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! * voice: ++49 4257 300 ! Fährstraße 1 * fax : ++49 4257 300 ! 31609 Balge/Sebbenhausen * jhunold(a)gmx.eu ! Germany

2 2

[geometry] [polygon] What's the relationship?
by Dave Abrahams 19 Sep '12

19 Sep '12

Could someone please explain the relationship, if any, betweeen these two libraries? They seem to cover similar domains. Do they interoperate? Is one better than the other for certain kinds of problems? Was Boost.Polygon once called the Geometry Template Library, as suggested by the BoostCon 2009 slides? Boy, that's confusing. Lastly, could we get these libraries' documentation to mention one another and explain the information I'm asking for? Thanks in advance for answering. -- Dave Abrahams BoostPro Computing Software Development Training http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost

5 5