- Boost - lists.boost.org

[Review.Coroutine] Some comments
by Vicente J. Botet Escriba 09 Sep '12

09 Sep '12

Hi, thanks Oliver to move the Coroutine library to a Boost review ready proposal. Before doing a formal review, I have some comments, suggestions and questions after a quick reading. Design ==== * I don't know if showing the signature in the documentation will be more informative. This will avoid, in particular, the be forced to explain what T and R and in the the current declaration. Could you replace template< typename Signature, typename Allocator = ctx::stack_allocator > class coroutine { public: class self_t { public: T yield( R); void yield_break(); }; by template< typename Signature, typename Allocator = ctx::stack_allocator >class coroutine; template< typename R, typename ...ArgTypes, typename Allocator > class coroutine<R(ArgTypes...)> { public: class self_t { public: tuple<ArgTypes...>yield( R); void yield_break(); }; * Could you add the following noexcept specifier? class coroutine { // ... coroutine() BOOST_NOEXCEPT; coroutine( coroutine && other) BOOST_NOEXCEPT; coroutine & operator=( coroutine && other) BOOST_NOEXCEPT; explicitoperator bool() const BOOST_NOEXCEPT; bool is_complete() const BOOST_NOEXCEPT; //... }; void swap( coroutine & l, coroutine & r) BOOST_NOEXCEPT; The same applies to generator. * As the template class Allocator is not used to allocate internal memory of the coroutine class. Could the Allocator parameter be renamed StackAllocator? * Could you add an standard Allocator parameter as e.g. the one of packaged_task? 0. template <class F, class Allocator> explicit packaged_task(allocator_arg_t, const Allocator& a, F&& f); C++ International Standard * I understand that the Boost.Context Allocator parameter is part od the class, as context is a low-level class, but coroutine is more high level. Is there a possibility to type erase the StackAllocator (and preceding Allocator) template parameter, as packaged_task do? This will allow to store coroutines (and generators) with the same signature in a container even if they don't share the Allocator. template<typename>class coroutine; template< typename R, typename ...ArgTypes > class coroutine<R(ArgTypes...)> { public: //... template< typename Fn,typename Allocator> generator( Fn fn, std::size_t size = ctx::default_stacksize(), flag_unwind_t do_unwind = stack_unwind, bool preserve_fpu = true, Allocator alloc = Allocator() ); //... }; * Parameters and move semantics. Could the signature parameters be rvalue references? R operator()(A0 a0, ..., A9 a9); I'm asking this because I think that Boost.Tuple has not implemented yet move semantics. * What about moving some of the coroutine/generator optional parameters to a coro::attributes class std::size_t size = ctx::default_stacksize(), flag_unwind_t do_unwind = stack_unwind, bool preserve_fpu = true, * Usually (at least in the C++ standard) a function doesn't throws because of its preconditions are not satisfied. Preconditions: |size| > ctx::minimum_stacksize(), |size| < ctx::maximum_stacksize() when ! ctx::is_stack_unbound(). Effects: Creates a generator which will execute |fn|. If |do_unwind| is |stack_unwind| the destructor of |*this| unwinds the stack before destructing it. If |preserve_fpu| is |true| the floating-point registers are preserved between context switches. Throws: /invalid_argument/ if a precondition is not satisfied. Should the function throw in this case? This should be coherent with |Result operator()()| <http://ok73.ok.funpic.de/boost/libs/coroutine/doc/html/coroutine/generator/…> Preconditions: |*this| is not a /not-a-generator/, |! is_complete()|. which doesn't throws any specific exception if the preconditions are not satisfied. . Documentation ========= coroutine.html s/it can migrated between threads/it can migrate between threads/ s/yield_return/yield_break/ * documentation for the following constructor is missing in the reference template< typename Fn > coroutine( Fn && fn, std::size_t size = ctx::default_stacksize(), flag_unwind_t do_unwind = stack_unwind, bool preserve_fpu = true, Allocator alloc = Allocator() ); Best, Vicente

4 12

Re: [boost] [Boost-users] boost 1.51.0 bz2 archive observations
by Daniel James 08 Sep '12

08 Sep '12

>From the user list: On 31 August 2012 16:39, Aras Vaichas <aras.vaichas(a)gmail.com> wrote: > > There is a slight difference between the 1.51.0 and 1.50.0 boost bz2 files. > > e.g. > \boost_1_50_0.tar.bz2\boost_1_50_0.tar\boost_1_50_0\ > \boost_1_51_0.tar.bz2\boost_1_51_0.tar\.\boost_1_51_0\ This is causing problems for some people's build scripts. The attached patch should fix this.

2 1

boost::assign::map_list_of and references?
by David Hagood 08 Sep '12

08 Sep '12

I was trying to initialize a map using map_list_of, and ran into what I consider an undesirable behavior: class stooge { public: stooge(); stooge(const stooge &); stooge &operator =(const stooge &); }; typedef std::map<std::string,const stooge &> MyMap_t; extern const stooge larry,moe,curly; MyMap_t mymap = boost::assign::map_list_of ("larry",larry) ("moe",moe) ("curly",curly); The above leaves mymap full of bogus references - it seems map_list_of is creating temporary copies of the objects, rather than taking their references, and then the map takes references to those temporaries, and blooley! Changing the assignment to: MyMap_t mymap = boost::assign::map_list_of<std::string, const stooge &> doesn't change anything. (and for various reasons, making stooge noncopyable is not an option). This is under gcc 4.5 i686 target. Am I "doing it wrong" or is this an issue with map_list_of?

1 0

[config] [result_of] Now VC++11 selects decltype-based result_of by default
by Michel Morin 08 Sep '12

08 Sep '12

On VC++11, result_of (on trunk) uses decltype-based implementation by default from r80453: https://svn.boost.org/trac/boost/changeset/80453 Note that VC++11 does not have a C++03/C++11 compiler switch and it always runs in a C++11 mode. Regards, Michel

1 0

[result_of] Usage guidelines
by Andrey Semashev 08 Sep '12

08 Sep '12

Hi, I wonder what is the correct way of declaring polymorphic function object result types and how to use result_of template with regard to argument types. If a function object receives arguments by reference, should its member result<> template be specialized for reference types as well? Also, should result_of<> for this function be instantiated with reference argument types? struct my_foo { template< typename > struct result; // Is this correct? template< typename ArgT > struct result< my_foo(ArgT) > { typedef ArgT type; }; // Or is this correct? template< typename ArgT > struct result< my_foo(ArgT const&) > { typedef ArgT type; }; template< typename ArgT > ArgT operator() (ArgT const& arg) const { return arg; } }; I realize that I can provide both result<> specializations and it will work either way. But when there are more than one argument the specializations begin to pile quickly. Consider also rvalue references and const and non-const qualified my_foo. Another question I have is how to use result_of<> when my_foo is external (i.e. provided by a third party library)? // Which one is the right way? typedef result_of< my_foo(int) >::type result_type1; typedef result_of< my_foo(int const&) >::type result_type2; I cannot know what result<> specializations are provided by my_foo, so probably there isn't an ultimate answer. But perhaps there are some guidelines or best practices? I've looked at result_of docs but there are no recommendations on this.

5 11

Interest in UDL suffixes for built-in and some standard library types?
by Peter Sommerlad 08 Sep '12

08 Sep '12

Dear boost members, I am preparing a paper for the next C++ standardization meeting for providing user-defined-literals for some standard types. b (and a variety of derivations lik bULL) for binary integer literals as in 101b s for std::string as "hello, world!"s s, h, min, etc. for std::chrono::duration literals such as 0xfh for 15 hours i, r for creating std::complex literals see http://wiki.hsr.ch/PeterSommerlad/wiki.cgi?LiteralsForBinaryStringComplexDu… for the paper draft. It also includes machinery to parse integers using the template version of a user-defined literal, because using constexpr operator"" foo(unsigned long long bar); overload loses the ability to treat the number bar as a compile-time constant, e.g., to use as template argument further on. Some people told me, such a facility would be nice in its own way, to be used by other authors of UDL constexpr overloads. I wonder if there is interest to provide standard conforming versions of my implementation (including the required _ prefix) for boost (which would require to clean up things a bit beforehand). Such a boost.suffixes library would only work with C++11 capable compilers that actually implement UDL and constexpr in combination (for some uses the constexpr is not required). gcc4.7.1 is fine, for example, my version of clang didn't do constexpr yet (that might have changed). Feedback, encouragement and thoughts are welcome. TIA and Best Regards Peter. -- Prof. Peter Sommerlad Institut für Software: Bessere Software - Einfach, Schneller! HSR Hochschule für Technik Rapperswil Oberseestr 10, Postfach 1475, CH-8640 Rapperswil http://ifs.hsr.ch http://cute-test.com http://linticator.com http://includator.com tel:+41 55 222 49 84 == mobile:+41 79 432 23 32 fax:+41 55 222 46 29 == mailto:peter.sommerlad@hsr.ch

2 1

Newbie question: Can't see my own posts
by Peter Sommerlad 07 Sep '12

07 Sep '12

Hi, it seems to me that I cannot see my own posts. For one containing a hyperlink I got a post confirmation but it never reached me: > Your message entitled > > Interest in UDL suffixes for built-in and some standard library types? > > was successfully received by the Boost mailing list. Did anybody see that message? Regards and thanks for your help Peter. -- Prof. Peter Sommerlad Institut für Software: Bessere Software - Einfach, Schneller! HSR Hochschule für Technik Rapperswil Oberseestr 10, Postfach 1475, CH-8640 Rapperswil http://ifs.hsr.ch http://cute-test.com http://linticator.com http://includator.com tel:+41 55 222 49 84 == mobile:+41 79 432 23 32 fax:+41 55 222 46 29 == mailto:peter.sommerlad@hsr.ch

2 1

[heap] typedef T gets prevalence over template parameter
by Alex Hagen-Zanker 07 Sep '12

07 Sep '12

Hi, The d_ary_heap does not compile (in VS2010) when the Comparison class contains a typedef T. The typedef takes prevalence over the template parameter T when the heap is derived from the Comparison class. I.e. the following pattern occurs: template<class T, class Cmp> struct heap_base : Cmp { typedef T value_type; // value_type = Cmp::T } I don't know if this is a bug, a user issue, or a compiler issue. But it caused me a lot of headache when I was trying to apply Jeremiah's indirect_cmp with Boost.Heap. See below for a complete failing example. Kind regards, Alex #include <boost/heap/d_ary_heap.hpp> struct less { typedef int T; bool operator()(const int& a, const int& b) const { return a < b; } }; int main() { boost::heap::d_ary_heap<int, boost::heap::compare<less>, boost::heap::arity<4> > my_heap; return 0; }

3 5

[Review] Coroutine : Christopher's Review
by Christopher Kormanyos 07 Sep '12

07 Sep '12

(I lost the initial review announcement.) Yes, I vote that Coroutine should be accepted into Boost! General impression of the library: Coroutine offers enormous potential for programming regimes such as communications software and embedded systems design. For example, a lightweight event/alarm-based cooperative multitasking scheduler for embedded systems can be readily implemented usingCoroutine combined with a timer resource. Oliver has selected a sensible granularity for Coroutine. It includes Boost.Context, Coroutine and the proposed Boost.Fiber. This granularity allows for fine-tuning the implementations of cooperative scheduling mechanisms while avoiding the prohibitively heavy weight of preemptive scheduling that is found in POSIX and often in implementations of the C++11 thread support library. The documentation is terse, yet complete and informative. The examples are good. The design of Coroutine is clearly thought through. In particular, the separation of Coroutine from Context allows for porting to other systems with minimal effort and maximum reliability and code re-use. How long did I work with Coroutine? I worked for about 1 week with Coroutine. In particular, I worked very intensively with Coroutine for 2 days straight. I used Coroutine with VS2010, VS2012-RC and several GNU compilers. I spent a lot of time deeply embedding Coroutine in a hard real-time system. This experience has led to the comments and suggestions shown below. Am I familiar with the regime of Coroutine? Yes. I am absolutely familiar with the regime of Coroutine. I have authored many cooperative multitasking schedulers for a variety of CPU architectures and shipped them in tens of millions of devices. Suggestions for Coroutine: I have several suggestions for Coroutine, none of which stand in the way of immediate acceptance into Boost. 1) The code may potentially benefit from some clean-up. In particular, there is a mixture of tabs and spaces in the code, possibly resulting from programming over two or more time epochs with different styles. A simple reformat will clean this up. Coroutine is desperately needed in the embedded systems community. Along these lines, I suggests some extensions. 2) There should be, let's say, a *lightweight* version (or configuration) of Coroutine for embedded systems 3) The lightweight version can not use the non-placement version of new(). The internal details of a coroutine are stored in the class as a pointer created with non-placement new(). The lightweight version could add a parameter for user-supplied memory and create the coroutine implementation details with placement-new(). 4) Furthermore, the lightweight version should not not use any exceptions whatsoever. I spent two solid hours removing all traces of exceptions while embedding Coroutine. The result was a lightweight mechanism that only costed a few kilobytes of program code. 5) We need to work together to create more contexts for different CPU architectures. The ARM(R) context that is present in Boost.Context uses several ASM operations that my ARM(R) Cortex(R)-M3 does not support. For this reason, I could not complete my benchmark. We can work on this in the future. Thank you for your efforts and good luck! Best regards, Chris.

3 2

[rational] Over/underflow checked update ready for comments
by Dan Searles 07 Sep '12

07 Sep '12

Le 06/09/12 04:28, Dan Searles a ?crit :>Le 06/09/12 04:28, Dan Searles a ?crit : >>>> For those interested in the rational number class, see: >>>> https://svn.boost.org/svn/boost/sandbox/rational >>>> >>>> Requesting comments on the code, and review for >>>> inclusion in the next release. >>>> >>>> >>> Hi, >>> >>> the enum type could follow the one defined in >>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3352.html >>> "When an overflow does occur, the desirable behavior depends on the >>> application, so programmers may specify the overflow mode with a value >>> of type |enum class overflow|. The possible values are: >>> >>> |impossible| >>> Programmer analysis of the program has determined that overflow >>> cannot occur. Uses of this mode should be accompanied by an argument >>> supporting the conclusion. >>> |undefined| >>> Programmers are willing to accept undefined behavior in the event of >>> an overflow. >>> |modulus| >>> The assigned value is the dynamic value mod the range of the >>> variable. This mode makes sense only with unsigned numbers. It is >>> useful for angular measures. >>> |saturate| >>> If the dynamic value exceeds the range of the variable, assign the >>> nearest representable value. >>> |exception| >>> If the dynamic value exceeds the range of the variable, throw an >>> exception of type |std::overflow_error|. >> 'impossible' and 'undefined' are effectively the same thing, and >> equivalent to the 'no check' currently implemented. >Yes and not. Maybe from the point of view of the library, but this is a >useful information from the user point of view. So for the 'impossible' case, what should the library do when there is an over/underflow? >>> 'modulus' makes >>> more sense for the fixed point class that it's being described for >>> than rational numbers. I'm not sure a useful definition can even be >>> made for rationals. >>You are right. modulus for rational has not a clear sense. >> 'Saturate' sounds like it might be useful, but gets problematic >> quickly when there is under/overflow within the largest/smallest >> range limits. >Could you clarify? 'Saturate' implies returning the max value when the computed result is larger than can be represented, and returning the min value when the computed is smaller (more negative) than can be represented, but rationals can underflow between those extremes. For example, what is 1/2 * 1/maxint? >> The point is that if a result of a calculation is not >> exactly representable, you will get an exception to notify you. And of >> course 'exception' is in the new implementation for just that purpose. >A user can be interested in overflow check without exceptions. The >saturate policy should be a good replacement in context where exceptions >are not allowed. I can't quite see a point for there being 3 possible results when there is an overflow: exception, undefined, and ???. Maybe if '???' is a wrong value, but as close as possible? If you don't need the exact answers, float or double would probably be better. Returning zero for ??? might work. >Anyway, you should replace the CamelCase use in the definition of this >new enumeration. I think that basing your definition on the preceding >one could be acceptable. Which ones? Please suggest the names you think would be appropriate. (I tried to pick names that had a low probability of ever being used anywhere else. Common single dictionary words are probably not good.) >>> >>>> BTW, I have no access to the link for the examples and the test. >>> I have not changed those files. The existing examples and test >>> are still valid for the original non-checked case. For the checked >>> case, I have tests which run for hours. The tests for rational >>> instantiated with signed char is exhaustive (there are only so >>> many normalized values. Pairing up each value with every >>> other value on the binary operators doesn't result in much more >>> that 2**32 combinations). For short/int/long long, sets of interesting >>> values are created, and each value is paired up with every other >>> value in the set. I can provide the test drivers if anyone is >>> interested. >>I was interested by the examples and test using the new facility. Could >>you commit them in the sandbox, please? Uploaded the test driver to: https://svn.boost.org/svn/boost/sandbox/rational/Test_Rationals > >Best, >Vicente Thanks Dan Searles

2 1