Boost logo

Boost :

Subject: Re: [boost] [Review.Coroutine] Some comments
From: Oliver Kowalke (oliver.kowalke_at_[hidden])
Date: 2012-09-08 16:15:39

Am 08.09.2012 21:57, schrieb Vicente J. Botet Escriba:
> Le 08/09/12 20:05, Christopher Kormanyos a écrit :
>>> Am 08.09.2012 16:25, schrieb Vicente J. Botet Escriba:
>>>>>>> On solution could be to make coroutine non-copyable,
>>>>>> Is coroutine copyable?
>>>>> moveable-only - I mean to derive from boost::noncopyable
>>>> I'm lost. How this can help here?
>>> I was thinking about to make coroutine deriving from
>>> boost::noncopyable and not moveable-only.
>>> Then I could refactor coroutine that it does not need
>>> to allocate memory for inner classes.
>>> The user can decide if the coroutine instance is allocated
>>> on the stack or in the freestore and which technique is used.
>> Well, if it were my design, I would make coroutine non-copyable
>> and simply forget about all the related troubles of copy semantics.
>> Furthermore, I would entirely avoid the use of dynamically allocated
>> resources and a coroutine allocator.
>> But, of course, I am predominantly interested in using coroutine
>> in embedded systems that lack a heap and benefit from the predictability
>> of statically allocated resources. As you already mentioned
>> in various communications, though, we can work on a lightweight
>> embedded version in the future.
> The suggested Allocator is just there to responds to your need
> (predictability) :)
Vicente - I looked at packaged_task as you suggested. I found following

packaged_task() : {
typedef typename Allocator::template rebind<detail::task_object<R,FR>
>::other A2;
A2 a2(a); // allocated on the stack, after return from ctor destroyed
typedef thread_detail::allocator_destructor<A2> D;
task = task_ptr(::new(a2.allocate(1)) detail::task_object<R,FR>(f),
D(a2, 1) ); // a2 passed to allocator_destructor

template <class _Alloc>
    class allocator_destructor
       _Alloc& alloc_; // reference to A2
       size_type s_;
       allocator_destructor(_Alloc& a, size_type s)BOOST_NOEXCEPT
       : alloc_(a), s_(s)

allocator_destructor hold only a reference to the allocator A2 but the
instance was allocated on the stack.
Doesn't this mean that the alloc_ member of allocator_destructor will
point to a non-existing object?


Boost list run by bdawes at, gregod at, cpdaniel at, john at