------=_Part_1333_1169358.1488335078428
Content-Type: multipart/alternative;
 boundary="----=_Part_1334_464699336.1488335078428"

------=_Part_1334_464699336.1488335078428
Content-Type: text/plain; charset=UTF-8

Hello,

I have some questions about call/cc in proposed implementation

I think possibility put any arguments in continuation and access to them
through template function it is lack of type safety, and isn't good idea to
propose it in standard.
Why not specialize continuation with type of input and type of output?
And forward arguments of operator() to constructor of input type.
I rewrote continuation based on boost.context implementation.
Also I get rid of data_available/get_data... why not use optional?
What do you think about it?

https://gist.github.com/cNoNim/bb24a613406de30d2c856bc7df1ab424

Also I don't understand why:

> If an uncaught exception escapes from the entry-function, std::terminate
> is called.
>

We can catch exception in `run` function of `record` and rethrow in
`context_exit`

https://gist.github.com/cNoNim/933978b23ccc13746ffe4f21de187ecd

Sorry for custom naming convention.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/fc546ea4-a355-4a60-a7e7-97927993471d%40isocpp.org.

------=_Part_1334_464699336.1488335078428
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hello,<br><br>I have some questions about call/cc in propo=
sed implementation<br><br>I think possibility put any arguments in continua=
tion and access to them through template function it is lack of type safety=
, and isn&#39;t good idea to propose it in standard.<br>Why not specialize =
continuation with type of input and type of output?<br>And forward argument=
s of operator() to constructor of input type.<br>I rewrote continuation bas=
ed on boost.context implementation.<br>Also I get rid of data_available/get=
_data... why not use optional?<br>What do you think about it?<br><br>https:=
//gist.github.com/cNoNim/bb24a613406de30d2c856bc7df1ab424<br><br>Also I don=
&#39;t understand why:<br><blockquote class=3D"gmail_quote" style=3D"margin=
: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-lef=
t: 1ex;">If an uncaught exception escapes from the entry-function, std::ter=
minate is called.<br></blockquote><div><br>We can catch exception in `run` =
function of `record` and rethrow in `context_exit`<br><br>https://gist.gith=
ub.com/cNoNim/933978b23ccc13746ffe4f21de187ecd <br><br>Sorry for custom nam=
ing convention.<br><br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/fc546ea4-a355-4a60-a7e7-97927993471d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/fc546ea4-a355-4a60-a7e7-97927993471d=
%40isocpp.org</a>.<br />

------=_Part_1334_464699336.1488335078428--

------=_Part_1333_1169358.1488335078428--

.

------=_Part_6298_831946259.1488337284683
Content-Type: multipart/alternative;
 boundary="----=_Part_6299_1959364858.1488337284683"

------=_Part_6299_1959364858.1488337284683
Content-Type: text/plain; charset=UTF-8



On Tuesday, February 28, 2017 at 9:24:38 PM UTC-5, Oleg Ageev wrote:
>
> Hello,
>
> I have some questions about call/cc in proposed implementation
>
> I think possibility put any arguments in continuation and access to them
> through template function it is lack of type safety, and isn't good idea to
> propose it in standard.
> Why not specialize continuation with type of input and type of output?
>

Because:

1) That would limit what you can do with continuations. As currently
proposed, you can pass different parameters to different parts of
continuations. Your idea fixes the interface at call/cc time.

2) P0534 is intended to be as low level as possible while still being
functional. By specializing types, it would be higher level than strictly
*necessary*.

And forward arguments of operator() to constructor of input type.
> I rewrote continuation based on boost.context implementation.
> Also I get rid of data_available/get_data... why not use optional?
>

Use `optional` to do what? To take up more space? To force me to copy
values when I don't have to?

What do you think about it?
>
> https://gist.github.com/cNoNim/bb24a613406de30d2c856bc7df1ab424
>
> Also I don't understand why:
>
>> If an uncaught exception escapes from the entry-function, std::terminate
>> is called.
>>
>
> We can catch exception in `run` function of `record` and rethrow in
> `context_exit`
>

Again, this would make P0534 higher level than strictly needed. If you want
to provide such wrappers, that's great (and welcome). But the low-level
tool shouldn't have those.

As I have argued in other threads, I think it is vital to have both
low-level tools and high-level tools available. For those who need the
greater control, they can have that. But we should also ship with safer
mechanisms that handle such things adequately. And standardizing them means
that they can be inter-operable.

https://gist.github.com/cNoNim/933978b23ccc13746ffe4f21de187ecd
>
> Sorry for custom naming convention.
>

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/3a57e294-7254-4358-828d-c9f7757f5295%40isocpp.org.

------=_Part_6299_1959364858.1488337284683
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Tuesday, February 28, 2017 at 9:24:38 PM UTC-5,=
 Oleg Ageev wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"=
ltr">Hello,<br><br>I have some questions about call/cc in proposed implemen=
tation<br><br>I think possibility put any arguments in continuation and acc=
ess to them through template function it is lack of type safety, and isn&#3=
9;t good idea to propose it in standard.<br>Why not specialize continuation=
 with type of input and type of output?<br></div></blockquote><div><br>Beca=
use:<br><br>1) That would limit what you can do with continuations. As curr=
ently proposed, you can pass different parameters to different parts of con=
tinuations. Your idea fixes the interface at call/cc time.<br><br>2) P0534 =
is intended to be as low level as possible while still being functional. By=
 specializing types, it would be higher level than strictly <i>necessary</i=
>.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"lt=
r">And forward arguments of operator() to constructor of input type.<br>I r=
ewrote continuation based on boost.context implementation.<br>Also I get ri=
d of data_available/get_data... why not use optional?<br></div></blockquote=
><div><br>Use `optional` to do what? To take up more space? To force me to =
copy values when I don&#39;t have to?<br><br></div><blockquote class=3D"gma=
il_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid=
;padding-left: 1ex;"><div dir=3D"ltr">What do you think about it?<br><br><a=
 href=3D"https://gist.github.com/cNoNim/bb24a613406de30d2c856bc7df1ab424" t=
arget=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;https://w=
ww.google.com/url?q\x3dhttps%3A%2F%2Fgist.github.com%2FcNoNim%2Fbb24a613406=
de30d2c856bc7df1ab424\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGG-yyD_HQle8R=
EALDzCPnG3CL1kA&#39;;return true;" onclick=3D"this.href=3D&#39;https://www.=
google.com/url?q\x3dhttps%3A%2F%2Fgist.github.com%2FcNoNim%2Fbb24a613406de3=
0d2c856bc7df1ab424\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGG-yyD_HQle8REAL=
DzCPnG3CL1kA&#39;;return true;">https://gist.github.com/<wbr>cNoNim/<wbr>bb=
24a613406de30d2c856bc7df1ab4<wbr>24</a><br><br>Also I don&#39;t understand =
why:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex=
;border-left:1px solid rgb(204,204,204);padding-left:1ex">If an uncaught ex=
ception escapes from the entry-function, std::terminate is called.<br></blo=
ckquote><div><br>We can catch exception in `run` function of `record` and r=
ethrow in `context_exit`<br></div></div></blockquote><div><br>Again, this w=
ould make P0534 higher level than strictly needed. If you want to provide s=
uch wrappers, that&#39;s great (and welcome). But the low-level tool should=
n&#39;t have those.<br><br>As I have argued in other threads, I think it is=
 vital to have both low-level tools and high-level tools available. For tho=
se who need the greater control, they can have that. But we should also shi=
p with safer mechanisms that handle such things adequately. And standardizi=
ng them means that they can be inter-operable.<br><br></div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #=
ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><a href=3D"https://gist=
..github.com/cNoNim/933978b23ccc13746ffe4f21de187ecd" target=3D"_blank" rel=
=3D"nofollow" onmousedown=3D"this.href=3D&#39;https://www.google.com/url?q\=
x3dhttps%3A%2F%2Fgist.github.com%2FcNoNim%2F933978b23ccc13746ffe4f21de187ec=
d\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGlEnDDsPaNt9pcbR3fSZWvyCnnRQ&#39;=
;return true;" onclick=3D"this.href=3D&#39;https://www.google.com/url?q\x3d=
https%3A%2F%2Fgist.github.com%2FcNoNim%2F933978b23ccc13746ffe4f21de187ecd\x=
26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGlEnDDsPaNt9pcbR3fSZWvyCnnRQ&#39;;re=
turn true;">https://gist.github.com/<wbr>cNoNim/<wbr>933978b23ccc13746ffe4f=
21de187e<wbr>cd</a> <br><br>Sorry for custom naming convention.<br></div></=
div></blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/3a57e294-7254-4358-828d-c9f7757f5295%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/3a57e294-7254-4358-828d-c9f7757f5295=
%40isocpp.org</a>.<br />

------=_Part_6299_1959364858.1488337284683--

------=_Part_6298_831946259.1488337284683--

.

--001a11490382b78e270549a63c55
Content-Type: text/plain; charset=UTF-8

2017-03-01 4:01 GMT+01:00 Nicol Bolas <jmckesson@gmail.com>:

>
>
> On Tuesday, February 28, 2017 at 9:24:38 PM UTC-5, Oleg Ageev wrote:
>>
>> Hello,
>>
>> I have some questions about call/cc in proposed implementation
>>
>> I think possibility put any arguments in continuation and access to them
>> through template function it is lack of type safety, and isn't good idea to
>> propose it in standard.
>> Why not specialize continuation with type of input and type of output?
>>
>
> Because:
>
> 1) That would limit what you can do with continuations. As currently
> proposed, you can pass different parameters to different parts of
> continuations. Your idea fixes the interface at call/cc time.
>

For instance during the implementation of my coroutine and fiber libraries
I encountered that initialization- and termination-phases were required. In
those phases no data at all or data of different types are transferred.
Imagine the type of the transferred data does not have an default-ctor -
you have to pass an value each time the continuation is resumed. What if
you can't produce one or you want to terminate the continuation.
Of course you could use something like variant or optional, but you would
pay each time for the overhead even in cases were you don't need
variant/optional etc.

I've had several implementations of call/cc - the one  presented in P0534
seams to me the most suitable.



> 2) P0534 is intended to be as low level as possible while still being
> functional. By specializing types, it would be higher level than strictly
> *necessary*.
>

right , that's one of the ideas behind P0534

> We can catch exception in `run` function of `record` and rethrow in
`context_exit`

The switch mechanism proposed in P0534 is symmetric, e.g you have to
explicitly specify the continuation that has to resumed next.
To which continuation do you want to jump to in context_exit?

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2Bwfc19mghDOW62NTTtiy%3D2GBwcwCtuBCX9zQWx7qYEuCsQJEw%40mail.gmail.com.

--001a11490382b78e270549a63c55
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">2017=
-03-01 4:01 GMT+01:00 Nicol Bolas <span dir=3D"ltr">&lt;<a target=3D"_blank=
" href=3D"mailto:jmckesson@gmail.com"><span class=3D"" style=3D"" id=3D"gma=
il-:10j.1" tabindex=3D"-1">jmckesson</span>@gmail.com</a>&gt;</span>:<br><b=
lockquote style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,2=
04,204);padding-left:1ex" class=3D"gmail_quote"><div dir=3D"ltr"><span clas=
s=3D"gmail-"><br><br>On Tuesday, February 28, 2017 at 9:24:38 PM UTC-5, Ole=
g Ageev wrote:<blockquote style=3D"margin:0px 0px 0px 0.8ex;border-left:1px=
 solid rgb(204,204,204);padding-left:1ex" class=3D"gmail_quote"><div dir=3D=
"ltr">Hello,<br><br>I have some questions about call/cc in proposed impleme=
ntation<br><br>I think possibility put any arguments in continuation and ac=
cess to them through template function it is lack of type safety, and isn&#=
39;t good idea to propose it in standard.<br>Why not specialize continuatio=
n with type of input and type of output?<br></div></blockquote></span><div>=
<br>Because:<br><br>1) That would limit what you can do with continuations.=
 As currently proposed, you can pass different parameters to different part=
s of continuations. Your idea fixes the interface at call/cc time.<br></div=
></div></blockquote><div><br></div><div>For instance during the implementat=
ion of my <span class=3D"" style=3D"" id=3D"gmail-:10j.2" tabindex=3D"-1">c=
oroutine</span> and fiber libraries I encountered that initialization- and =
termination-phases were required. In those phases no data at all or data of=
 different types are transferred.<br></div><div>Imagine the type of the tra=
nsferred data does not have an default-<span class=3D"" style=3D"" id=3D"gm=
ail-:10j.3" tabindex=3D"-1">ctor</span> - you have to pass an value each ti=
me the continuation is resumed. What if you can&#39;t produce one or you wa=
nt to terminate the continuation.</div><div>Of course you could use somethi=
ng like variant or optional, but you would pay each time for the overhead e=
ven in cases were you don&#39;t need variant/optional etc.</div><br><div>I&=
#39;ve had several implementations of call/cc - the one=C2=A0 presented in =
P0534 seams to me the most suitable.<br><br></div><div>=C2=A0</div><blockqu=
ote style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204=
);padding-left:1ex" class=3D"gmail_quote"><div dir=3D"ltr"><div>2) P0534 is=
 intended to be as low level as possible while still being functional. By s=
pecializing types, it would be higher level than strictly <i>necessary</i>.=
<br></div></div></blockquote><div><br></div><div>right , that&#39;s one of =
the ideas behind P0534<br><br>&gt; We can catch exception in `run` function=
 of `record` and rethrow in `context_exit`<br><br></div><div>The switch mec=
hanism proposed in P0534 is symmetric, e.g you have to explicitly specify t=
he continuation that has to resumed next.<br></div><div>To which continuati=
on do you want to jump to in context_exit?<br></div></div><br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CA%2Bwfc19mghDOW62NTTtiy%3D2GBwcwCtuB=
CX9zQWx7qYEuCsQJEw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2Bwfc19mgh=
DOW62NTTtiy%3D2GBwcwCtuBCX9zQWx7qYEuCsQJEw%40mail.gmail.com</a>.<br />

--001a11490382b78e270549a63c55--

.

------=_Part_1363_539063933.1488354516452
Content-Type: multipart/alternative;
 boundary="----=_Part_1364_933719156.1488354516452"

------=_Part_1364_933719156.1488354516452
Content-Type: text/plain; charset=UTF-8

Oliver, why not standardize the lowest level part first - fcontext_t et a +
stacks allocation? I think this API can be used even with pure C. And we
can build anything ontop. call/cc can have some unwanted overhead. I'm sure
that fcontext_t-related functions are the main values of Boost.Context
library. People still use it even in spite of it were moved into detail.
E.g. see
https://github.com/facebook/folly/blob/master/folly/fibers/BoostContextCompatibility.h
..

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/519ff5a1-cf5e-4641-98c1-835667e737db%40isocpp.org.

------=_Part_1364_933719156.1488354516452
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Oliver, why not standardize the lowest level part first - =
fcontext_t et a + stacks allocation? I think this API can be used even with=
 pure C. And we can build anything ontop. call/cc can have some unwanted ov=
erhead. I&#39;m sure that fcontext_t-related functions are the main values =
of Boost.Context library. People still use it even in spite of it were move=
d into detail. E.g. see <a href=3D"https://github.com/facebook/folly/blob/m=
aster/folly/fibers/BoostContextCompatibility.h">https://github.com/facebook=
/folly/blob/master/folly/fibers/BoostContextCompatibility.h</a>.<br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/519ff5a1-cf5e-4641-98c1-835667e737db%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/519ff5a1-cf5e-4641-98c1-835667e737db=
%40isocpp.org</a>.<br />

------=_Part_1364_933719156.1488354516452--

------=_Part_1363_539063933.1488354516452--

.

--001a114e449034dd1a0549a71110
Content-Type: text/plain; charset=UTF-8

2017-03-01 8:48 GMT+01:00 Victor Dyachenko <victor.dyachenko@gmail.com>:

> I think this API can be used even with pure C.
>

because it's proposed for C++ - class std::continuation manages the
execution context (the stack; one shot-continuation).



> And we can build anything ontop. call/cc can have some unwanted overhead.
> I'm sure that fcontext_t-related functions are the main values of
> Boost.Context library.
>

callcc() and continuation::operator() are only thin wrapper (only one- or
two-lines of code)

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2Bwfc1-7Tyobn4jEehcq6dOCYADo3Tkq--GH-Zvn_uAiw%3DUD%2BA%40mail.gmail.com.

--001a114e449034dd1a0549a71110
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
2017-03-01 8:48 GMT+01:00 Victor Dyachenko <span dir=3D"ltr">&lt;<a target=
=3D"_blank" href=3D"mailto:victor.dyachenko@gmail.com">victor.dyachenko@gma=
il.com</a>&gt;</span>:<br><blockquote style=3D"margin:0px 0px 0px 0.8ex;bor=
der-left:1px solid rgb(204,204,204);padding-left:1ex" class=3D"gmail_quote"=
><div dir=3D"ltr">I think this API can be used even with pure C.</div></blo=
ckquote><div><br></div><div>because it&#39;s proposed for C++ - class std::=
continuation manages the execution context (the stack; one shot-continuatio=
n).<br></div><div><br>=C2=A0</div><blockquote style=3D"margin:0px 0px 0px 0=
..8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class=3D"gmai=
l_quote"><div dir=3D"ltr">And we can build anything ontop. call/cc can have=
 some unwanted overhead. I&#39;m sure that fcontext_t-related functions are=
 the main values of Boost.Context library.<br></div></blockquote><div><br><=
/div><div>callcc() and continuation::operator() are only thin wrapper (only=
 one- or two-lines of code)<br></div></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CA%2Bwfc1-7Tyobn4jEehcq6dOCYADo3Tkq--=
GH-Zvn_uAiw%3DUD%2BA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2Bwfc1-7=
Tyobn4jEehcq6dOCYADo3Tkq--GH-Zvn_uAiw%3DUD%2BA%40mail.gmail.com</a>.<br />

--001a114e449034dd1a0549a71110--

.

------=_Part_1425_1405816666.1488357941451
Content-Type: multipart/alternative;
 boundary="----=_Part_1426_2137026392.1488357941451"

------=_Part_1426_2137026392.1488357941451
Content-Type: text/plain; charset=UTF-8

On Wednesday, March 1, 2017 at 11:26:22 AM UTC+3, Oliver Kowalke wrote:
>
>
> 2017-03-01 8:48 GMT+01:00 Victor Dyachenko <victor.d...@gmail.com
> <javascript:>>:
>
>> I think this API can be used even with pure C.
>>
>
> because it's proposed for C++ - class std::continuation manages the
> execution context (the stack; one shot-continuation).
>
>
Sure, but I think I would be good for C/C++ community to have common tools,
at least on ABI level. Like atomics or complex numbers.


>
>
>> And we can build anything ontop. call/cc can have some unwanted overhead.
>> I'm sure that fcontext_t-related functions are the main values of
>> Boost.Context library.
>>
>
> callcc() and continuation::operator() are only thin wrapper (only one- or
> two-lines of code)
>

Yes, it is slightly thinner than execution_context v2. But it still
controls the lifetime - I need to keep the continuation object somewhere.
May be add something like thread::detach() ?

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/9247af8a-6ec9-418f-94fc-5fa48900b6f2%40isocpp.org.

------=_Part_1426_2137026392.1488357941451
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wednesday, March 1, 2017 at 11:26:22 AM UTC+3, Oliver K=
owalke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
<div><br><div class=3D"gmail_quote">2017-03-01 8:48 GMT+01:00 Victor Dyache=
nko <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obf=
uscated-mailto=3D"6rVOuh2cCQAJ" rel=3D"nofollow" onmousedown=3D"this.href=
=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascri=
pt:&#39;;return true;">victor.d...@gmail.com</a>&gt;</span>:<br><blockquote=
 style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);p=
adding-left:1ex" class=3D"gmail_quote"><div dir=3D"ltr">I think this API ca=
n be used even with pure C.</div></blockquote><div><br></div><div>because i=
t&#39;s proposed for C++ - class std::continuation manages the execution co=
ntext (the stack; one shot-continuation).<br></div><div><br></div></div></d=
iv></div></blockquote><div><br>Sure, but I think I would be good for C/C++ =
community to have common tools, at least on ABI level. Like atomics or comp=
lex numbers.<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"marg=
in: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><d=
iv dir=3D"ltr"><div><div class=3D"gmail_quote"><div>=C2=A0</div><blockquote=
 style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);p=
adding-left:1ex" class=3D"gmail_quote"><div dir=3D"ltr">And we can build an=
ything ontop. call/cc can have some unwanted overhead. I&#39;m sure that fc=
ontext_t-related functions are the main values of Boost.Context library.<br=
></div></blockquote><div><br></div><div>callcc() and continuation::operator=
() are only thin wrapper (only one- or two-lines of code)<br></div></div></=
div></div></blockquote><div><br>Yes, it is slightly thinner than execution_=
context v2. But it still controls the lifetime - I need to keep the continu=
ation object somewhere. May be add something like thread::detach() ?=C2=A0<=
/div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/9247af8a-6ec9-418f-94fc-5fa48900b6f2%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/9247af8a-6ec9-418f-94fc-5fa48900b6f2=
%40isocpp.org</a>.<br />

------=_Part_1426_2137026392.1488357941451--

------=_Part_1425_1405816666.1488357941451--

.

------=_Part_1721_1140330581.1488364782993
Content-Type: multipart/alternative;
 boundary="----=_Part_1722_341074381.1488364782994"

------=_Part_1722_341074381.1488364782994
Content-Type: text/plain; charset=UTF-8



On Wednesday, March 1, 2017 at 6:01:25 AM UTC+3, Nicol Bolas wrote:
>
> 1) That would limit what you can do with continuations. As currently
> proposed, you can pass different parameters to different parts of
> continuations. Your idea fixes the interface at call/cc time.
>
You also can pass different parameters if use optional/varian/custom type
with several different constructors, but get rid of type safety it's very
bad idea...

> 2) P0534 is intended to be as low level as possible while still being
> functional. By specializing types, it would be higher level than strictly
> *necessary*.
>
low level API it's fcontext_t and several functions to context switching,
continuation it's high level wrapper


> Use `optional` to do what? To take up more space? To force me to copy
> values when I don't have to?
>
I think even use of `optional` not necessary, e.g. we can throw kind of bad
access exception

On Wednesday, March 1, 2017 at 10:26:57 AM UTC+3, Oliver Kowalke wrote:
>
> For instance during the implementation of my coroutine and fiber
> libraries I encountered that initialization- and termination-phases were
> required. In those phases no data at all or data of different types are
> transferred.
> Imagine the type of the transferred data does not have an default-ctor -
> you have to pass an value each time the continuation is resumed. What if
> you can't produce one or you want to terminate the continuation.
> Of course you could use something like variant or optional, but you would
> pay each time for the overhead even in cases were you don't need
> variant/optional etc.
>
also you can use custom type for wrap it and reduce overhead, or hide
internals from user

The switch mechanism proposed in P0534 is symmetric, e.g you have to
> explicitly specify the continuation that has to resumed next.
> To which continuation do you want to jump to in context_exit?
>
If I get you right `context_exit` executed ontop of caller context because
in `context_entry` we have:
ontop_fcontext( t.fctx, rec, context_exit< Rec >);
and if we catch exception in continuation, we can rethrow it to caller
context in context_exit
or I don't understand some use cases?

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/9deccbda-26ca-4ad8-a579-1feb674676a6%40isocpp.org.

------=_Part_1722_341074381.1488364782994
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Wednesday, March 1, 2017 at 6:01:25 AM UTC+3, N=
icol Bolas wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><div>1) That would limit what you can do with continuations. As current=
ly proposed, you can pass different parameters to different parts of contin=
uations. Your idea fixes the interface at call/cc time.<br></div></div></bl=
ockquote><div>You also can pass different parameters if use optional/varian=
/custom type with several different constructors, but get rid of type safet=
y it&#39;s very bad idea...<br></div><blockquote class=3D"gmail_quote" styl=
e=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left:=
 1ex;"><div dir=3D"ltr"><div>2) P0534 is intended to be as low level as pos=
sible while still being functional. By specializing types, it would be high=
er level than strictly <i>necessary</i>.<br></div></div></blockquote><div>l=
ow level API it&#39;s fcontext_t and several functions to context switching=
, continuation it&#39;s high level wrapper<br>=C2=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div dir=3D"ltr"><div></div><div>Use `optional`=
 to do what? To take up more space? To force me to copy values when I don&#=
39;t have to?</div></div></blockquote><div>I think even use of `optional` n=
ot necessary, e.g. we can throw kind of bad access exception<br><br>On Wedn=
esday, March 1, 2017 at 10:26:57 AM UTC+3, Oliver Kowalke wrote:<blockquote=
 class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1=
px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail=
_quote">For instance during the implementation of my <span>coroutine</span>
 and fiber libraries I encountered that initialization- and=20
termination-phases were required. In those phases no data at all or data
 of different types are transferred.<br><div>Imagine the type of the transf=
erred data does not have an default-<span>ctor</span>
 - you have to pass an value each time the continuation is resumed. What
 if you can&#39;t produce one or you want to terminate the continuation.</d=
iv><div>Of
 course you could use something like variant or optional, but you would=20
pay each time for the overhead even in cases were you don&#39;t need=20
variant/optional etc.</div></div></div></div></blockquote><div>also you can=
 use custom type for wrap it and reduce overhead, or hide internals from us=
er <br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><div><div class=3D"gmail_quote"><div>The
 switch mechanism proposed in P0534 is symmetric, e.g you have to=20
explicitly specify the continuation that has to resumed next.<br></div><div=
>To which continuation do you want to jump to in context_exit?<br></div></d=
iv></div></div></blockquote><div><span id=3D"result_box" class=3D"short_tex=
t" lang=3D"en"><span class=3D"">If I get you right</span></span> `context_e=
xit` executed ontop of caller context because in `context_entry` we have:<b=
r><div style=3D"background-color: rgb(250, 250, 250); border-color: rgb(187=
, 187, 187); border-style: solid; border-width: 1px; overflow-wrap: break-w=
ord;" class=3D"prettyprint"><code class=3D"prettyprint"><div class=3D"subpr=
ettyprint"><span style=3D"color: #000;" class=3D"styled-by-prettify">ontop_=
fcontext</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> t</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">.</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">fctx</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> rec</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> context_exit</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">&lt;</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"> </span><span style=3D"color: #606;" class=3D"styled-by-prett=
ify">Rec</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> <=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;);</spa=
n></div></code></div>and if we catch exception in continuation, we can reth=
row it to caller context in context_exit<br>or I don&#39;t understand some =
use cases?<br></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/9deccbda-26ca-4ad8-a579-1feb674676a6%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/9deccbda-26ca-4ad8-a579-1feb674676a6=
%40isocpp.org</a>.<br />

------=_Part_1722_341074381.1488364782994--

------=_Part_1721_1140330581.1488364782993--

.

------=_Part_1584_1144695204.1488364831687
Content-Type: multipart/alternative;
 boundary="----=_Part_1585_789244533.1488364831687"

------=_Part_1585_789244533.1488364831687
Content-Type: text/plain; charset=UTF-8



On Wednesday, March 1, 2017 at 6:01:25 AM UTC+3, Nicol Bolas wrote:
>
> 1) That would limit what you can do with continuations. As currently
> proposed, you can pass different parameters to different parts of
> continuations. Your idea fixes the interface at call/cc time.
>
You also can pass different parameters if use optional/varian/custom type
with several different constructors, but get rid of type safety it's very
bad idea...

> 2) P0534 is intended to be as low level as possible while still being
> functional. By specializing types, it would be higher level than strictly
> *necessary*.
>
low level API it's fcontext_t and several functions to context switching,
continuation it's high level wrapper


> Use `optional` to do what? To take up more space? To force me to copy
> values when I don't have to?
>
I think even use of `optional` not necessary, e.g. we can throw kind of bad
access exception

On Wednesday, March 1, 2017 at 10:26:57 AM UTC+3, Oliver Kowalke wrote:
>
> For instance during the implementation of my coroutine and fiber
> libraries I encountered that initialization- and termination-phases were
> required. In those phases no data at all or data of different types are
> transferred.
> Imagine the type of the transferred data does not have an default-ctor -
> you have to pass an value each time the continuation is resumed. What if
> you can't produce one or you want to terminate the continuation.
> Of course you could use something like variant or optional, but you would
> pay each time for the overhead even in cases were you don't need
> variant/optional etc.
>
also you can use custom type for wrap it and reduce overhead, or hide
internals from user

The switch mechanism proposed in P0534 is symmetric, e.g you have to
> explicitly specify the continuation that has to resumed next.
> To which continuation do you want to jump to in context_exit?
>
If I get you right `context_exit` executed ontop of caller context because
in `context_entry` we have:
ontop_fcontext( t.fctx, rec, context_exit< Rec >);
and if we catch exception in continuation, we can rethrow it to caller
context in context_exit
or I don't understand some use cases?

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/95352da6-ee98-4aca-83e1-a28e6e39b712%40isocpp.org.

------=_Part_1585_789244533.1488364831687
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Wednesday, March 1, 2017 at 6:01:25 AM UTC+3, N=
icol Bolas wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><div>1)
 That would limit what you can do with continuations. As currently=20
proposed, you can pass different parameters to different parts of=20
continuations. Your idea fixes the interface at call/cc time.<br></div></di=
v></blockquote><div>You
 also can pass different parameters if use optional/varian/custom type=20
with several different constructors, but get rid of type safety it&#39;s=20
very bad idea...<br></div><blockquote class=3D"gmail_quote" style=3D"margin=
: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div=
 dir=3D"ltr"><div>2)
 P0534 is intended to be as low level as possible while still being=20
functional. By specializing types, it would be higher level than=20
strictly <i>necessary</i>.<br></div></div></blockquote><div>low level API i=
t&#39;s fcontext_t and several functions to context switching, continuation=
 it&#39;s high level wrapper<br>=C2=A0</div><blockquote class=3D"gmail_quot=
e" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddin=
g-left: 1ex;"><div dir=3D"ltr"><div>Use `optional` to do what? To take up m=
ore space? To force me to copy values when I don&#39;t have to?</div></div>=
</blockquote>I think even use of `optional` not necessary, e.g. we can thro=
w kind of bad access exception<br><br>On Wednesday, March 1, 2017 at 10:26:=
57 AM UTC+3, Oliver Kowalke wrote:<blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote">For instance during =
the implementation of my <span>coroutine</span>
 and fiber libraries I encountered that initialization- and=20
termination-phases were required. In those phases no data at all or data
 of different types are transferred.<br><div>Imagine the type of the transf=
erred data does not have an default-<span>ctor</span>
 - you have to pass an value each time the continuation is resumed. What
 if you can&#39;t produce one or you want to terminate the continuation.</d=
iv><div>Of
 course you could use something like variant or optional, but you would=20
pay each time for the overhead even in cases were you don&#39;t need=20
variant/optional etc.</div></div></div></div></blockquote><div>also you can=
 use custom type for wrap it and reduce overhead, or hide internals from us=
er <br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><div><div class=3D"gmail_quote"><div>The
 switch mechanism proposed in P0534 is symmetric, e.g you have to=20
explicitly specify the continuation that has to resumed next.<br></div><div=
>To which continuation do you want to jump to in context_exit?<br></div></d=
iv></div></div></blockquote><span id=3D"result_box" class=3D"short_text" la=
ng=3D"en"><span class=3D"">If I get you right</span></span> `context_exit` =
executed ontop of caller context because in `context_entry` we have:<br><di=
v style=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187=
, 187); border-style: solid; border-width: 1px; overflow-wrap: break-word;"=
 class=3D"prettyprint"><code class=3D"prettyprint"><div class=3D"subprettyp=
rint"><span style=3D"color: #000;" class=3D"styled-by-prettify">ontop_fcont=
ext</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> t</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">.</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify">fctx</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> rec</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> context_exit</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">&lt;</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">=
Rec</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;);</span></d=
iv></code></div>and if we catch exception in continuation, we can rethrow i=
t to caller context in context_exit<br>or I don&#39;t understand some use c=
ases?</div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/95352da6-ee98-4aca-83e1-a28e6e39b712%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/95352da6-ee98-4aca-83e1-a28e6e39b712=
%40isocpp.org</a>.<br />

------=_Part_1585_789244533.1488364831687--

------=_Part_1584_1144695204.1488364831687--

.

--001a11c03ed8835fdd0549a9344e
Content-Type: text/plain; charset=UTF-8

2017-03-01 11:39 GMT+01:00 <ogee@agnicore.com>:

> 2) P0534 is intended to be as low level as possible while still being
>> functional. By specializing types, it would be higher level than strictly
>> *necessary*.
>>
>
> low level API it's fcontext_t and several functions to context switching,
> continuation it's high level wrapper
>

that's wrong


> On Wednesday, March 1, 2017 at 10:26:57 AM UTC+3, Oliver Kowalke wrote:
>>
>> For instance during the implementation of my coroutine and fiber
>> libraries I encountered that initialization- and termination-phases were
>> required. In those phases no data at all or data of different types are
>> transferred.
>> Imagine the type of the transferred data does not have an default-ctor -
>> you have to pass an value each time the continuation is resumed. What if
>> you can't produce one or you want to terminate the continuation.
>> Of course you could use something like variant or optional, but you would
>> pay each time for the overhead even in cases were you don't need
>> variant/optional etc.
>>
> also you can use custom type for wrap it and reduce overhead, or hide
> internals from use
>

you still pay for thinks you don't need


The switch mechanism proposed in P0534 is symmetric, e.g you have to
>> explicitly specify the continuation that has to resumed next.
>> To which continuation do you want to jump to in context_exit?
>>
> If I get you right `context_exit` executed ontop of caller context
> because in `context_entry` we have:
> ontop_fcontext( t.fctx, rec, context_exit< Rec >);
> and if we catch exception in continuation, we can rethrow it to caller
> context in context_exit
> or I don't understand some use cases?
>

if you throw an exception in the middle of your continuation and it it
escapes the top-level continuation you have no guaranttee that the calling
continuation is still valid (might resumed and termianted already)

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2Bwfc19hFNcyjVn%3DoiFn%2Brf%3DzUYYyxjmZ-Zp-wDiK2n61DqeaA%40mail.gmail.com.

--001a11c03ed8835fdd0549a9344e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">2017=
-03-01 11:39 GMT+01:00  <span dir=3D"ltr">&lt;<a target=3D"_blank" href=3D"=
mailto:ogee@agnicore.com">ogee@agnicore.com</a>&gt;</span>:<br><blockquote =
style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pa=
dding-left:1ex" class=3D"gmail_quote"><div dir=3D"ltr"><span class=3D"gmail=
-"></span><span class=3D"gmail-"><blockquote style=3D"margin:0px 0px 0px 0.=
8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class=3D"gmail=
_quote"><div dir=3D"ltr"><div>2) P0534 is intended to be as low level as po=
ssible while still being functional. By specializing types, it would be hig=
her level than strictly <i>necessary</i>.</div></div></blockquote></span><b=
r><span class=3D"gmail-"></span><div>low level API it&#39;s fcontext_t and =
several functions to context switching, continuation it&#39;s high level wr=
apper<br></div></div></blockquote><div><br></div><div>that&#39;s wrong<br><=
/div><div>=C2=A0</div><blockquote style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex" class=3D"gmail_quote"><di=
v dir=3D"ltr"><span class=3D"gmail-"></span><div><span class=3D"gmail-">On =
Wednesday, March 1, 2017 at 10:26:57 AM UTC+3, Oliver Kowalke wrote:<blockq=
uote style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,20=
4);padding-left:1ex" class=3D"gmail_quote"><div dir=3D"ltr"><div><div class=
=3D"gmail_quote">For instance during the implementation of my <span>corouti=
ne</span>
 and fiber libraries I encountered that initialization- and=20
termination-phases were required. In those phases no data at all or data
 of different types are transferred.<br><div>Imagine the type of the transf=
erred data does not have an default-<span>ctor</span>
 - you have to pass an value each time the continuation is resumed. What
 if you can&#39;t produce one or you want to terminate the continuation.</d=
iv><div>Of
 course you could use something like variant or optional, but you would=20
pay each time for the overhead even in cases were you don&#39;t need=20
variant/optional etc.</div></div></div></div></blockquote></span><div>also =
you can use custom type for wrap it and reduce overhead, or hide internals =
from use<br></div></div></div></blockquote><div><br></div><div>you still pa=
y for thinks you don&#39;t need <br></div><div><br><br></div><blockquote st=
yle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padd=
ing-left:1ex" class=3D"gmail_quote"><div dir=3D"ltr"><div><span class=3D"gm=
ail-"><blockquote style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid r=
gb(204,204,204);padding-left:1ex" class=3D"gmail_quote"><div dir=3D"ltr"><d=
iv><div class=3D"gmail_quote"><div>The
 switch mechanism proposed in P0534 is symmetric, e.g you have to=20
explicitly specify the continuation that has to resumed next.<br></div><div=
>To which continuation do you want to jump to in context_exit?<br></div></d=
iv></div></div></blockquote></span><div><span class=3D"gmail-m_611834693342=
1255512short_text" id=3D"gmail-m_6118346933421255512result_box" lang=3D"en"=
><span>If I get you right</span></span> `context_exit` executed ontop of ca=
ller context because in `context_entry` we have:<br><div class=3D"gmail-m_6=
118346933421255512prettyprint" style=3D"background-color:rgb(250,250,250);b=
order-color:rgb(187,187,187);border-style:solid;border-width:1px"><code cla=
ss=3D"gmail-m_6118346933421255512prettyprint"><div class=3D"gmail-m_6118346=
933421255512subprettyprint"><span class=3D"gmail-m_6118346933421255512style=
d-by-prettify" style=3D"color:rgb(0,0,0)">ontop_fcontext</span><span class=
=3D"gmail-m_6118346933421255512styled-by-prettify" style=3D"color:rgb(102,1=
02,0)">(</span><span class=3D"gmail-m_6118346933421255512styled-by-prettify=
" style=3D"color:rgb(0,0,0)"> t</span><span class=3D"gmail-m_61183469334212=
55512styled-by-prettify" style=3D"color:rgb(102,102,0)">.</span><span class=
=3D"gmail-m_6118346933421255512styled-by-prettify" style=3D"color:rgb(0,0,0=
)">fctx</span><span class=3D"gmail-m_6118346933421255512styled-by-prettify"=
 style=3D"color:rgb(102,102,0)">,</span><span class=3D"gmail-m_611834693342=
1255512styled-by-prettify" style=3D"color:rgb(0,0,0)"> rec</span><span clas=
s=3D"gmail-m_6118346933421255512styled-by-prettify" style=3D"color:rgb(102,=
102,0)">,</span><span class=3D"gmail-m_6118346933421255512styled-by-prettif=
y" style=3D"color:rgb(0,0,0)"> context_exit</span><span class=3D"gmail-m_61=
18346933421255512styled-by-prettify" style=3D"color:rgb(102,102,0)">&lt;</s=
pan><span class=3D"gmail-m_6118346933421255512styled-by-prettify" style=3D"=
color:rgb(0,0,0)"> </span><span class=3D"gmail-m_6118346933421255512styled-=
by-prettify" style=3D"color:rgb(102,0,102)">Rec</span><span class=3D"gmail-=
m_6118346933421255512styled-by-prettify" style=3D"color:rgb(0,0,0)"> </span=
><span class=3D"gmail-m_6118346933421255512styled-by-prettify" style=3D"col=
or:rgb(102,102,0)">&gt;);</span></div></code></div>and if we catch exceptio=
n in continuation, we can rethrow it to caller context in context_exit<br>o=
r I don&#39;t understand some use cases?<br></div></div></div></blockquote>=
</div><br>if you throw an exception in the middle of your continuation and =
it it escapes the top-level continuation you have no guaranttee that the ca=
lling continuation is still valid (might resumed and termianted already)<br=
></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CA%2Bwfc19hFNcyjVn%3DoiFn%2Brf%3DzUYY=
yxjmZ-Zp-wDiK2n61DqeaA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2Bwfc1=
9hFNcyjVn%3DoiFn%2Brf%3DzUYYyxjmZ-Zp-wDiK2n61DqeaA%40mail.gmail.com</a>.<br=
 />

--001a11c03ed8835fdd0549a9344e--

.

------=_Part_1779_2035797571.1488366989134
Content-Type: multipart/alternative;
 boundary="----=_Part_1780_850533972.1488366989135"

------=_Part_1780_850533972.1488366989135
Content-Type: text/plain; charset=UTF-8

On Wednesday, March 1, 2017 at 1:59:24 PM UTC+3, Oliver Kowalke wrote:

> if you throw an exception in the middle of your continuation and it it
> escapes the top-level continuation you have no guaranttee that the calling
> continuation is still valid (might resumed and termianted already)
>
I don't understand how calling continuation can be not vaild, if you have
BOOST_ASSERT( nullptr != t.fctx);
before call ontop_fcontext
and if calling continuation existis, and it not top level continuation,
when it's also catch exception, and rethrow to caller

Can you mean that the context is lost because it is moved to the functor?
but we can save calling context for use in catch
    Transfer run(Transfer t)
    {
      Ctx from{ t };
      auto recovery = from.t.fctx;
      try
      {
        Ctx cc = std::invoke(f, std::move(from));
        return { std::exchange(cc.t.fctx, nullptr), nullptr };
      }
      catch (ForcedUnwind const&)
      { throw; }
      catch (...)
      {
        except = std::current_exception();
        return { recovery, nullptr };
      }
    }
`recovery` it's pointer to calling context

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/69ee11fb-5cd0-4e1e-8c61-2792fe062003%40isocpp.org.

------=_Part_1780_850533972.1488366989135
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wednesday, March 1, 2017 at 1:59:24 PM UTC+3, Oliver Ko=
walke wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"lt=
r"><div>if you throw an exception in the middle of your continuation and it=
 it escapes the top-level continuation you have no guaranttee that the call=
ing continuation is still valid (might resumed and termianted already)<br><=
/div></div></blockquote><div>I don&#39;t understand how calling continuatio=
n can be not vaild, if you have <br><div style=3D"background-color: rgb(250=
, 250, 250); border-color: rgb(187, 187, 187); border-style: solid; border-=
width: 1px; overflow-wrap: break-word;" class=3D"prettyprint"><code class=
=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #000;"=
 class=3D"styled-by-prettify">BOOST_ASSERT</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">nullptr</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">!=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> t<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">.</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify">fctx</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">);</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> </span></div></code></div>before =
call ontop_fcontext<br>and if calling continuation existis, and it not top =
level continuation, when it&#39;s also catch exception, and rethrow to call=
er<br><br><span id=3D"result_box" class=3D"" lang=3D"en"><span class=3D"">C=
an</span> <span>you mean</span> <span class=3D"">that the</span> <span>cont=
ext</span> <span>is lost</span> <span>because it</span> <span>is moved to</=
span> <span class=3D"">the functor?<br>but we can save calling context for =
use in catch<br><div style=3D"background-color: rgb(250, 250, 250); border-=
color: rgb(187, 187, 187); border-style: solid; border-width: 1px; overflow=
-wrap: break-word;" class=3D"prettyprint"><code class=3D"prettyprint"><div =
class=3D"subprettyprint"><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify">=C2=A0 =C2=A0 </span><span style=3D"color: #606;" class=3D"styled-b=
y-prettify">Transfer</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> run</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">(</span><span style=3D"color: #606;" class=3D"styled-by-prettify">Trans=
fer</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> t</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">)</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 =
</span><span style=3D"color: #606;" class=3D"styled-by-prettify">Ctx</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span sty=
le=3D"color: #008;" class=3D"styled-by-prettify">from</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> t </span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">};</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color: #0=
08;" class=3D"styled-by-prettify">auto</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> recovery </span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-b=
y-prettify">from</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">.</span><span style=3D"color: #000;" class=3D"styled-by-prettify">t</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">.</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify">fctx</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 </span><spa=
n style=3D"color: #008;" class=3D"styled-by-prettify">try</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 </s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 </span><span style=3D"color: #606;" class=3D"styled-by-prettify"=
>Ctx</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> cc </=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> std</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify">invoke</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify">f</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> std</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">mov=
e</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><=
span style=3D"color: #008;" class=3D"styled-by-prettify">from</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">));</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0=
 </span><span style=3D"color: #008;" class=3D"styled-by-prettify">return</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> std</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify">exchange</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify">cc</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">.</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
">t</span><span style=3D"color: #660;" class=3D"styled-by-prettify">.</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify">fctx</span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #=
008;" class=3D"styled-by-prettify">nullptr</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">),</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">nullptr</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">};</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
=C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">}</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"><br>=C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"sty=
led-by-prettify">catch</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">(</span><span style=3D"color: #606;" class=3D"styled-by-prettify">Forced=
Unwind</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </s=
pan><span style=3D"color: #008;" class=3D"styled-by-prettify">const</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">&amp;)</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=
=A0 </span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span s=
tyle=3D"color: #008;" class=3D"styled-by-prettify">throw</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">}</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color: #=
008;" class=3D"styled-by-prettify">catch</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">(...)</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">except</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> std</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify">current_exception</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">();</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color: #=
008;" class=3D"styled-by-prettify">return</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> recovery</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">null=
ptr</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">};</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0=
 </span><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span></=
div></code></div>`recovery` it&#39;s pointer to calling context<br></span><=
/span></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/69ee11fb-5cd0-4e1e-8c61-2792fe062003%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/69ee11fb-5cd0-4e1e-8c61-2792fe062003=
%40isocpp.org</a>.<br />

------=_Part_1780_850533972.1488366989135--

------=_Part_1779_2035797571.1488366989134--

.

--001a114c6fce2d20b30549a9a56f
Content-Type: text/plain; charset=UTF-8

you can't use recovery after calling std::invloke() because during the
execution of f the context associated with f.ctx/recovery might have been
resumed (so recovery points somewhere in the stackframe) or the context was
terminated before the exception is thrown out of f.

suppose A calls callccc(f) -> that creates B : t.fctx/recovery points  to
the stack of A
B resumes C (created somewhere/before A calls callcc() ...)
C resumes A
A terminates
after A has terminated B is resumed (because A has specified B as the
context that has to be resumed after A's termination)
B resumes and throws an exception
exception is catched in run()
returning recovery ends up in UB because the stack space recovery points to
is invalidated/deleted or was reused and overwritten ....

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2Bwfc18uQYCsx7cRrg5VhkQYCU8RXFys3DV9j%3D7Xuww2nOtePA%40mail.gmail.com.

--001a114c6fce2d20b30549a9a56f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div><div><div><div><div><div><div>you can&#39;t use =
recovery after calling std::<span tabindex=3D"-1" id=3D":2je.1" style=3D"" =
class=3D"">invloke</span>() because during the execution of f the context a=
ssociated with f.<span tabindex=3D"-1" id=3D":2je.2" style=3D"" class=3D"">=
ctx</span>/recovery might have been resumed (so recovery points somewhere i=
n the <span tabindex=3D"-1" id=3D":2je.3" style=3D"" class=3D"">stackframe<=
/span>) or the context was terminated before the exception is thrown out of=
 f.<br><br></div>suppose A calls <span tabindex=3D"-1" id=3D":2je.4" style=
=3D"" class=3D"">callccc</span>(f) -&gt; that creates B : t.<span tabindex=
=3D"-1" id=3D":2je.5" style=3D"" class=3D"">fctx</span>/recovery points=C2=
=A0 to the stack of A<br></div>B resumes C (created somewhere/before A call=
s <span tabindex=3D"-1" id=3D":2je.6" style=3D"" class=3D"">callcc</span>()=
 ...)<br></div>C resumes A<br></div>A terminates<br></div>after A has termi=
nated B is resumed (because A has specified B as the context that has to be=
 resumed after A&#39;s termination)<br></div>B resumes and throws an except=
ion<br></div>exception is <span tabindex=3D"-1" id=3D":2je.7" style=3D"" cl=
ass=3D"">catched</span> in run()<br></div>returning recovery ends up in <sp=
an tabindex=3D"-1" id=3D":2je.8" style=3D"" class=3D"">UB</span> because th=
e stack space recovery points to is invalidated/deleted or was reused and o=
verwritten ....<br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CA%2Bwfc18uQYCsx7cRrg5VhkQYCU8RXFys3D=
V9j%3D7Xuww2nOtePA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2Bwfc18uQY=
Csx7cRrg5VhkQYCU8RXFys3DV9j%3D7Xuww2nOtePA%40mail.gmail.com</a>.<br />

--001a114c6fce2d20b30549a9a56f--

.

------=_Part_1560_2079010813.1488368358604
Content-Type: multipart/alternative;
 boundary="----=_Part_1561_1638125224.1488368358605"

------=_Part_1561_1638125224.1488368358605
Content-Type: text/plain; charset=UTF-8

On Wednesday, March 1, 2017 at 3:01:25 AM UTC, Nicol Bolas wrote:

>
> On Tuesday, February 28, 2017 at 9:24:38 PM UTC-5, Oleg Ageev wrote:
>>
>> Hello,
>>
>> I have some questions about call/cc in proposed implementation
>>
>> I think possibility put any arguments in continuation and access to them
>> through template function it is lack of type safety, and isn't good idea to
>> propose it in standard.
>> Why not specialize continuation with type of input and type of output?
>>
>
> Because:
>
> 1) That would limit what you can do with continuations. As currently
> proposed, you can pass different parameters to different parts of
> continuations. Your idea fixes the interface at call/cc time.
>
> 2) P0534 is intended to be as low level as possible while still being
> functional. By specializing types, it would be higher level than strictly
> *necessary*.
>

FWIW, I strongly disagree. Getting continuation correctly typed is
important and any help the compiler can give when using such a mind-bending
construct as a continuation is very welcome. In particular getting the
typing of something like invoke_on_top is non trivial (it certainly took me
a few tries).

The proposal doesn't seem to describe the semantics, but get_data<T> is
either unsafe (i.e. the equivalent of a reinterpret_cast) or, if checked,
adds non trivial overhead as it requires passing the typeid in addition to
the value itself and checking against it.

In the first case you are better off using explicit void* in your
continuation type so that the type safety hole is evident; in the second
case, the dynamic checking should be opt in, by explicit using std::any,
std::variant or something like that, otherwise it would violate the goal of
being a zero cost abstraction.

I would like to add that, with the current ephemeral continuation semantics
[1] and with the existence of invoke_on_top, the need for a dynamic
continuation type is greatly reduced as you can very cheaply capture a new
continuation with a new type.

Regarding optionality, unfortunately my experience matches Oliver's and it
is pretty much a requirement that any continuation<T> in practice needs to
support yielding with no value.

[1] Ephemeral in the sense that a logical continuation exists only between
the capture point and its restoration point; the fact that we may (or not)
reuse the same std::continuation object to refer to distinct continuations
is immaterial and only done for convenience.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/4e6c13b2-4286-4df8-989b-97cbf3bf1cc7%40isocpp.org.

------=_Part_1561_1638125224.1488368358605
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wednesday, March 1, 2017 at 3:01:25 AM UTC, Nicol Bolas=
 wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><b=
r>On Tuesday, February 28, 2017 at 9:24:38 PM UTC-5, Oleg Ageev wrote:<bloc=
kquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-lef=
t:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Hello,<br><br>I have so=
me questions about call/cc in proposed implementation<br><br>I think possib=
ility put any arguments in continuation and access to them through template=
 function it is lack of type safety, and isn&#39;t good idea to propose it =
in standard.<br>Why not specialize continuation with type of input and type=
 of output?<br></div></blockquote><div><br>Because:<br><br>1) That would li=
mit what you can do with continuations. As currently proposed, you can pass=
 different parameters to different parts of continuations. Your idea fixes =
the interface at call/cc time.<br><br>2) P0534 is intended to be as low lev=
el as possible while still being functional. By specializing types, it woul=
d be higher level than strictly <i>necessary</i>.<br></div></div></blockquo=
te><div><br>FWIW, I strongly disagree. Getting continuation correctly typed=
 is important and any help the compiler can give when using such a mind-ben=
ding construct as a continuation is very welcome. In particular getting the=
 typing of something like invoke_on_top is non trivial (it certainly took m=
e a few tries).<br><br>The proposal doesn&#39;t seem to describe the semant=
ics, but get_data&lt;T&gt; is either unsafe (i.e. the equivalent of a reint=
erpret_cast) or, if checked, adds non trivial overhead as it requires passi=
ng the typeid in addition to the value itself and checking against it. <br>=
<br>In the first case you are better off using explicit void* in your=20
continuation type so that the type safety hole is evident; in the second=20
case, the dynamic checking should be opt in, by explicit using  std::any,=
=20
std::variant or something like that, otherwise it would violate the goal of=
 being a zero cost abstraction.<br><br>I would like to add that, with the c=
urrent ephemeral continuation semantics [1] and with the existence of invok=
e_on_top, the need for a dynamic continuation type is greatly reduced as yo=
u can very cheaply capture a new continuation with a new type.<br><br>Regar=
ding optionality, unfortunately my experience matches Oliver&#39;s and it i=
s pretty much a requirement that any continuation&lt;T&gt; in practice need=
s to support yielding with no value.<br></div><br>[1] Ephemeral in the sens=
e that a logical continuation exists only between the capture point and its=
 restoration point; the fact that we may (or not) reuse the same std::conti=
nuation object to refer to distinct continuations is immaterial and only do=
ne for convenience.<br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/4e6c13b2-4286-4df8-989b-97cbf3bf1cc7%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/4e6c13b2-4286-4df8-989b-97cbf3bf1cc7=
%40isocpp.org</a>.<br />

------=_Part_1561_1638125224.1488368358605--

------=_Part_1560_2079010813.1488368358604--

.

------=_Part_1522_1084710088.1488368951983
Content-Type: multipart/alternative;
 boundary="----=_Part_1523_420722054.1488368951984"

------=_Part_1523_420722054.1488368951984
Content-Type: text/plain; charset=UTF-8



On Wednesday, March 1, 2017 at 2:30:54 PM UTC+3, Oliver Kowalke wrote:
>
> you can't use recovery after calling std::invloke() because during the
> execution of f the context associated with f.ctx/recovery might have been
> resumed (so recovery points somewhere in the stackframe) or the context
> was terminated before the exception is thrown out of f.
>
can you please explain problem by code...
I try implement problem but I don't understand how B after resuming can
throw exception
B depends on A and if A terminated B should be resumed only for
context_unwind by destructor
but ForceUnwind don't catched by run and work correcty...
I found some errors in my version of run now I try use that
    Transfer run(Transfer t)
    {
      Ctx from{ t };
      try
      {
        Ctx cc = std::invoke(f, std::move(from));
        return { std::exchange(cc.t.fctx, nullptr), nullptr };
      }
      catch (ForcedUnwind const&)
      { throw; }
      catch (...)
      {
        except = std::current_exception();
        return { std::exchange(from.t.fctx, nullptr), nullptr };
      }
    }

and try implement problem like this

  std::exception_ptr eptr;
  try
  {
    auto C = Continuation<void, void>::callcc([](auto && yield)
    {
      int counter = 0;
      do
      {
        if (counter == 10)
          throw std::bad_function_call();
        counter++;
      } while (yield = yield());
      return std::move(yield);
    });

    auto B = Continuation<void, int>::callcc([&C](auto && yield)
    {
      int ret = 0;
      do
      {
        if (!(C = C())) break;
      } while (yield = yield(ret++));
      return std::move(yield);
    });

    int ent = 0;
    while (B = B())
    {
      auto ret = B.get();
      if (ret >= 100) break;
    }

    std::cout << "main: done" << std::endl;
    std::cin.ignore();
  }
  catch (...)
  { eptr = std::current_exception(); }

and all works correctly

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/9024ef66-f27a-4553-a2a9-121693dc07d8%40isocpp.org.

------=_Part_1523_420722054.1488368951984
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Wednesday, March 1, 2017 at 2:30:54 PM UTC+3, O=
liver Kowalke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><div><div><div><div><div><div><div><div>you can&#39;t use recovery=
 after calling std::<span>invloke</span>() because during the execution of =
f the context associated with f.<span>ctx</span>/recovery might have been r=
esumed (so recovery points somewhere in the <span>stackframe</span>) or the=
 context was terminated before the exception is thrown out of f.<br></div><=
/div></div></div></div></div></div></div></div></blockquote><div>can you pl=
ease explain problem by code...<br>I try implement problem but I don&#39;t =
understand how B after resuming can throw exception<br>B depends on A and i=
f A terminated B should be resumed only for context_unwind by destructor<br=
>but ForceUnwind don&#39;t catched by run and work correcty...<br>I found s=
ome errors in my version of run now I try use that<br><div style=3D"backgro=
und-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-sty=
le: solid; border-width: 1px; overflow-wrap: break-word;" class=3D"prettypr=
int"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=
=3D"color: #000;" class=3D"styled-by-prettify">=C2=A0 =C2=A0 </span><span s=
tyle=3D"color: #606;" class=3D"styled-by-prettify">Transfer</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> run</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #6=
06;" class=3D"styled-by-prettify">Transfer</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> t</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color: #606;"=
 class=3D"styled-by-prettify">Ctx</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">from</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
 t </span><span style=3D"color: #660;" class=3D"styled-by-prettify">};</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=
=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-prettify"=
>try</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
=C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color: #606;" class=
=3D"styled-by-prettify">Ctx</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> cc </span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> std</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify">invoke</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify">f</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> std</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify">move</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">(</span><span style=3D"color: #008;" class=3D"styled-by-prett=
ify">from</span><span style=3D"color: #660;" class=3D"styled-by-prettify">)=
);</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">return</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> std</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify">exchange</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify">cc</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">.</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify">t</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">.</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify">fctx</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span style=3D"color: #008;" class=3D"styled-by-prettify">nullptr</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">),</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"colo=
r: #008;" class=3D"styled-by-prettify">nullptr</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">};</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">}</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 </span><span style=3D"col=
or: #008;" class=3D"styled-by-prettify">catch</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">(</span><span style=3D"color: #606;" class=3D"sty=
led-by-prettify">ForcedUnwind</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-=
prettify">const</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">&amp;)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
><br>=C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">th=
row</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">}</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 </span><s=
pan style=3D"color: #008;" class=3D"styled-by-prettify">catch</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">(...)</span><span style=3D"color:=
 #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 </span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
</span><span style=3D"color: #008;" class=3D"styled-by-prettify">except</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> std</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify">current_exception</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">();</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><sp=
an style=3D"color: #008;" class=3D"styled-by-prettify">return</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> std</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify">exchange</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">(</span><span style=3D"color: #008;" class=3D"styled-by-pr=
ettify">from</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">.</span><span style=3D"color: #000;" class=3D"styled-by-prettify">t</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">.</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify">fctx</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" cla=
ss=3D"styled-by-prettify">nullptr</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">),</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-pre=
ttify">nullptr</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">};</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =
=C2=A0 =C2=A0 </span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">}</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
=C2=A0 =C2=A0 </span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">}</span></div></code></div><br>and try implement problem like this<br><=
br><div style=3D"background-color: rgb(250, 250, 250); border-color: rgb(18=
7, 187, 187); border-style: solid; border-width: 1px; overflow-wrap: break-=
word;" class=3D"prettyprint"><code class=3D"prettyprint"><div class=3D"subp=
rettyprint"><span style=3D"color: #000;" class=3D"styled-by-prettify">=C2=
=A0 std</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify">exception_p=
tr eptr</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 <=
/span><span style=3D"color: #008;" class=3D"styled-by-prettify">try</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 </span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><=
span style=3D"color: #008;" class=3D"styled-by-prettify">auto</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> C </span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color:=
 #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" c=
lass=3D"styled-by-prettify">Continuation</span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">void</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">=
void</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;::=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify">callcc</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">([](</span><sp=
an style=3D"color: #008;" class=3D"styled-by-prettify">auto</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">&amp;&amp;</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;=
" class=3D"styled-by-prettify">yield</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color: #008;=
" class=3D"styled-by-prettify">int</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> counter </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> </span><span style=3D"color: #066;" class=3D"styled-by-pr=
ettify">0</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0=
 =C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-prett=
ify">do</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br=
>=C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color: #008;" clas=
s=3D"styled-by-prettify">if</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">c=
ounter </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D=
=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span style=3D"color: #066;" class=3D"styled-by-prettify">10</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">)</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-prettify">thr=
ow</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> std</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify">bad_function_call</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">();</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 counter</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">++;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
><br>=C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">}</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">wh=
ile</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span st=
yle=3D"color: #008;" class=3D"styled-by-prettify">yield</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">yield</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">());</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color: #008;" c=
lass=3D"styled-by-prettify">return</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> std</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify">move</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">(</span><span style=3D"color: #008;" class=3D"styled-by-prettify">yield=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">);</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">});</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br>=C2=A0 =
=C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-prettify">aut=
o</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> B </span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"=
color: #606;" class=3D"styled-by-prettify">Continuation</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">void</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"sty=
led-by-prettify">int</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">&gt;::</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify">callcc</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">([&amp;</span><span style=3D"color: #000;" class=3D"styled-by-prettify">C=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">](</span><=
span style=3D"color: #008;" class=3D"styled-by-prettify">auto</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">&amp;&amp;</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">yield</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">int</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> ret </span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"> </span><span style=3D"color: #066;" class=3D"styled-by-prett=
ify">0</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =
=C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-pretti=
fy">do</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
=C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">if</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">(!(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
C </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> C</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">()))</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">break</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 </span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">}</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D=
"styled-by-prettify">while</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">(</span><span style=3D"color: #008;" class=3D"styled-by-prettify">yi=
eld</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"=
color: #008;" class=3D"styled-by-prettify">yield</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify">ret</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">++));</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color: #0=
08;" class=3D"styled-by-prettify">return</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"> std</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify">move</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">(</span><span style=3D"color: #008;" class=3D"styled-by-prettify"=
>yield</span><span style=3D"color: #660;" class=3D"styled-by-prettify">);</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =
=C2=A0 </span><span style=3D"color: #660;" class=3D"styled-by-prettify">});=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br>=
=C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-pretti=
fy">int</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> en=
t </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span s=
tyle=3D"color: #066;" class=3D"styled-by-prettify">0</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">while</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify">B </span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> B</span><span style=3D"color: #660;" class=3D"styled-by-prettify">())</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =
=C2=A0 </span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =
=C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-pretti=
fy">auto</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> r=
et </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> B</span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">.</span><span style=3D=
"color: #008;" class=3D"styled-by-prettify">get</span><span style=3D"color:=
 #660;" class=3D"styled-by-prettify">();</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">if</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify">ret </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">&gt;=3D</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> </span><span style=3D"color: #066;" class=3D"styled-by-prettif=
y">100</span><span style=3D"color: #660;" class=3D"styled-by-prettify">)</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span=
 style=3D"color: #008;" class=3D"styled-by-prettify">break</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">}</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 <br>=C2=A0 =
=C2=A0 std</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">cout </s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;&lt;</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span s=
tyle=3D"color: #080;" class=3D"styled-by-prettify">&quot;main: done&quot;</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">&lt;&lt;</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> std</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify">endl</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 std</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify">cin</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">.</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify">ignore</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">();</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
<br>=C2=A0 </span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>}</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=
=A0 </span><span style=3D"color: #008;" class=3D"styled-by-prettify">catch<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">(...)</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 </span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> eptr </span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> std</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify">current_exception</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">();</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">}</span></div></code></div><br>and all works correctly<br></div></d=
iv>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/9024ef66-f27a-4553-a2a9-121693dc07d8%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/9024ef66-f27a-4553-a2a9-121693dc07d8=
%40isocpp.org</a>.<br />

------=_Part_1523_420722054.1488368951984--

------=_Part_1522_1084710088.1488368951983--

.

------=_Part_1545_1881163314.1488369223264
Content-Type: multipart/alternative;
 boundary="----=_Part_1546_1332742113.1488369223265"

------=_Part_1546_1332742113.1488369223265
Content-Type: text/plain; charset=UTF-8

exception can be thrown by some destructor in context_unwind
but exception in destructor it's bad practice
now I'try implement this

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/7209130d-c572-4097-94a7-d92dcef0f354%40isocpp.org.

------=_Part_1546_1332742113.1488369223265
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">exception can be thrown by some destructor in context_unwi=
nd<br>but exception in destructor it&#39;s bad practice<br>now I&#39;try im=
plement this<br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/7209130d-c572-4097-94a7-d92dcef0f354%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/7209130d-c572-4097-94a7-d92dcef0f354=
%40isocpp.org</a>.<br />

------=_Part_1546_1332742113.1488369223265--

------=_Part_1545_1881163314.1488369223264--

.

------=_Part_1589_791877005.1488369564096
Content-Type: multipart/alternative;
 boundary="----=_Part_1590_934975069.1488369564097"

------=_Part_1590_934975069.1488369564097
Content-Type: text/plain; charset=UTF-8

yes exception leaked if thrown by destructor
  std::exception_ptr eptr;
  try
  {
    auto C = Continuation<void, void>::callcc([](auto && yield)
    {
      int counter = 0;
      do
      {
        counter++;
      } while (yield = yield());
      return std::move(yield);
    });

    auto B = Continuation<void, int>::callcc([&C](auto && yield)
    {
      struct BAD { ~BAD() { throw std::bad_function_call(); } };
      BAD bad;
      int ret = 0;
      do
      {
        if (!(C = C())) break;
      } while (yield = yield(ret++));
      return std::move(yield);
    });

    int ent = 0;
    while (B = B())
    {
      auto ret = B.get();
      if (ret >= 100) break;
    }

    std::cout << "main: done" << std::endl;
  }
  catch (...)
  {
    eptr = std::current_exception();
  }

but how we can workaround this if don't support exceptions catching?

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/0705083b-2e6f-46e9-b624-26ca0b9894ea%40isocpp.org.

------=_Part_1590_934975069.1488369564097
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">yes exception leaked if thrown by destructor<br><div style=
=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187);=
 border-style: solid; border-width: 1px; overflow-wrap: break-word;" class=
=3D"prettyprint"><code class=3D"prettyprint"><div class=3D"subprettyprint">=
<span style=3D"color: #000;" class=3D"styled-by-prettify">=C2=A0 std</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify">exception_ptr eptr</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 </span><span st=
yle=3D"color: #008;" class=3D"styled-by-prettify">try</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 </span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"=
color: #008;" class=3D"styled-by-prettify">auto</span><span style=3D"color:=
 #000;" class=3D"styled-by-prettify"> C </span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"style=
d-by-prettify">Continuation</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">&lt;</span><span style=3D"color: #008;" class=3D"styled-by=
-prettify">void</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </s=
pan><span style=3D"color: #008;" class=3D"styled-by-prettify">void</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">&gt;::</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify">callcc</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">([](</span><span style=3D"c=
olor: #008;" class=3D"styled-by-prettify">auto</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">&amp;&amp;</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"st=
yled-by-prettify">yield</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">)</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"><br>=C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"st=
yled-by-prettify">int</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> counter </span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: #066;" class=3D"styled-by-prettify">0</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0=
 </span><span style=3D"color: #008;" class=3D"styled-by-prettify">do</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0=
 =C2=A0 </span><span style=3D"color: #660;" class=3D"styled-by-prettify">{<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 counter</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">++;</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"><br>=C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">}</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-pr=
ettify">while</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</spa=
n><span style=3D"color: #008;" class=3D"styled-by-prettify">yield</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;=
" class=3D"styled-by-prettify">yield</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">());</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color: #=
008;" class=3D"styled-by-prettify">return</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> std</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify">move</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">(</span><span style=3D"color: #008;" class=3D"styled-by-prettify=
">yield</span><span style=3D"color: #660;" class=3D"styled-by-prettify">);<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =
=C2=A0 </span><span style=3D"color: #660;" class=3D"styled-by-prettify">});=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br>=
=C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-pretti=
fy">auto</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> B=
 </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span st=
yle=3D"color: #606;" class=3D"styled-by-prettify">Continuation</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">void</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">int</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">&gt;::</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify">callcc</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">([&amp;</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify">C</span><span style=3D"color: #660;" class=3D"styled-by-prettify">](<=
/span><span style=3D"color: #008;" class=3D"styled-by-prettify">auto</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">&amp;&amp;</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"col=
or: #008;" class=3D"styled-by-prettify">yield</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">)</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 </span><span style=3D"col=
or: #008;" class=3D"styled-by-prettify">struct</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> BAD </span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">~</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify">BAD</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(=
)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"colo=
r: #008;" class=3D"styled-by-prettify">throw</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> std</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify">bad_function_call</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">();</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">}</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">};</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=
=A0 =C2=A0 BAD bad</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><=
br>=C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"styled=
-by-prettify">int</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> ret </span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span style=3D"color: #066;" class=3D"styled-by-prettify">0</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 </span>=
<span style=3D"color: #008;" class=3D"styled-by-prettify">do</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 =
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-pretti=
fy">if</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">(!(</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify">C </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> C</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">()))</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"sty=
led-by-prettify">break</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"><br>=C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">}</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">=
while</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span =
style=3D"color: #008;" class=3D"styled-by-prettify">yield</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">yield</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify">ret</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">++));</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
=C2=A0 =C2=A0 =C2=A0<br>=C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color: #=
008;" class=3D"styled-by-prettify">return</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> std</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify">move</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">(</span><span style=3D"color: #008;" class=3D"styled-by-prettify=
">yield</span><span style=3D"color: #660;" class=3D"styled-by-prettify">);<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =
=C2=A0 </span><span style=3D"color: #660;" class=3D"styled-by-prettify">});=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br>=
=C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-pretti=
fy">int</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> en=
t </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span s=
tyle=3D"color: #066;" class=3D"styled-by-prettify">0</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">while</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify">B </span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> B</span><span style=3D"color: #660;" class=3D"styled-by-prettify">())</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =
=C2=A0 </span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =
=C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-pretti=
fy">auto</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> r=
et </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> B</span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">.</span><span style=3D=
"color: #008;" class=3D"styled-by-prettify">get</span><span style=3D"color:=
 #660;" class=3D"styled-by-prettify">();</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">if</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify">ret </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">&gt;=3D</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> </span><span style=3D"color: #066;" class=3D"styled-by-prettif=
y">100</span><span style=3D"color: #660;" class=3D"styled-by-prettify">)</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span=
 style=3D"color: #008;" class=3D"styled-by-prettify">break</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">}</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 <br>=C2=A0 =
=C2=A0 std</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">cout </s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;&lt;</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span s=
tyle=3D"color: #080;" class=3D"styled-by-prettify">&quot;main: done&quot;</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">&lt;&lt;</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> std</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify">endl</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br>=C2=A0 </span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">}</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"><br>=C2=A0 </span><span style=3D"color: #008;" class=3D"sty=
led-by-prettify">catch</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">(...)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><b=
r>=C2=A0 </span><span style=3D"color: #660;" class=3D"styled-by-prettify">{=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> <br>=C2=
=A0 =C2=A0 eptr </span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
std</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify">current_excepti=
on</span><span style=3D"color: #660;" class=3D"styled-by-prettify">();</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> <br>=C2=A0 </s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span></div=
></code></div><br>but how we can workaround this if don&#39;t support excep=
tions catching?<br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/0705083b-2e6f-46e9-b624-26ca0b9894ea%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/0705083b-2e6f-46e9-b624-26ca0b9894ea=
%40isocpp.org</a>.<br />

------=_Part_1590_934975069.1488369564097--

------=_Part_1589_791877005.1488369564096--

.

------=_Part_1560_396439029.1488369797468
Content-Type: multipart/alternative;
 boundary="----=_Part_1561_91757737.1488369797469"

------=_Part_1561_91757737.1488369797469
Content-Type: text/plain; charset=UTF-8

On Wednesday, March 1, 2017 at 11:59:24 AM UTC, Oleg Ageev wrote:
>
> yes exception leaked if thrown by destructor
>

you have the same issue if the lambda moves the continuation to a local
variable, takes it by value instead of reference, or pass it to another
function by value, etc....

-- gpd


--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/7bad6d77-7385-462d-9d10-4774bf97ae88%40isocpp.org.

------=_Part_1561_91757737.1488369797469
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wednesday, March 1, 2017 at 11:59:24 AM UTC, Oleg Ageev=
 wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.=
8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">yes ex=
ception leaked if thrown by destructor<br></div></blockquote><div><br>you h=
ave the same issue if the lambda moves the continuation to a local variable=
, takes it by value instead of reference, or pass it to another function by=
 value, etc....<br><br>-- gpd<br></div><br><br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/7bad6d77-7385-462d-9d10-4774bf97ae88%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/7bad6d77-7385-462d-9d10-4774bf97ae88=
%40isocpp.org</a>.<br />

------=_Part_1561_91757737.1488369797469--

------=_Part_1560_396439029.1488369797468--

.

------=_Part_1568_879670364.1488370136945
Content-Type: multipart/alternative;
 boundary="----=_Part_1569_1457906088.1488370136945"

------=_Part_1569_1457906088.1488370136945
Content-Type: text/plain; charset=UTF-8



On Wednesday, March 1, 2017 at 3:03:17 PM UTC+3, Giovanni Piero Deretta
wrote:
>
> you have the same issue if the lambda moves the continuation to a local
> variable, takes it by value instead of reference, or pass it to another
> function by value, etc....
>
continuation is movable only object, how it can be taked by value?


--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/a880928c-208a-4f30-8967-bf29fac87bf2%40isocpp.org.

------=_Part_1569_1457906088.1488370136945
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Wednesday, March 1, 2017 at 3:03:17 PM UTC+3, G=
iovanni Piero Deretta wrote:<blockquote class=3D"gmail_quote" style=3D"marg=
in: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><d=
iv dir=3D"ltr">you have the same issue if the lambda moves the continuation=
 to a local variable, takes it by value instead of reference, or pass it to=
 another function by value, etc....<br></div></blockquote><div>continuation=
 is movable only object, how it can be taked by value?<br>=C2=A0</div></div=
>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/a880928c-208a-4f30-8967-bf29fac87bf2%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a880928c-208a-4f30-8967-bf29fac87bf2=
%40isocpp.org</a>.<br />

------=_Part_1569_1457906088.1488370136945--

------=_Part_1568_879670364.1488370136945--

.

------=_Part_1568_1144460027.1488370395022
Content-Type: multipart/alternative;
 boundary="----=_Part_1569_406868850.1488370395022"

------=_Part_1569_406868850.1488370395022
Content-Type: text/plain; charset=UTF-8

and also I got such warning

warning C4297:
'main::<lambda_47e6b9d8c7d076365105bb6276e58c85>::()::BAD::~BAD': function
assumed not to throw an exception but does
note: destructor or deallocator has a (possibly implicit) non-throwing
exception specification

destructor should be noexcept, and I see no other way to break exceptions
catching

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/d3d21e98-38be-4a5d-8f3e-becc5e80a908%40isocpp.org.

------=_Part_1569_406868850.1488370395022
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">and also I got such warning<br><br><div style=3D"backgroun=
d-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style=
: solid; border-width: 1px; overflow-wrap: break-word;" class=3D"prettyprin=
t"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D=
"color: #000;" class=3D"styled-by-prettify">warning C4297</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">:</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #080;" =
class=3D"styled-by-prettify">&#39;main::&lt;lambda_47e6b9d8c7d076365105bb62=
76e58c85&gt;::()::BAD::~BAD&#39;</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">:</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-pret=
tify">function</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> assumed </span><span style=3D"color: #008;" class=3D"styled-by-prettif=
y">not</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> to =
</span><span style=3D"color: #008;" class=3D"styled-by-prettify">throw</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> an exception b=
ut does<br>note</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">:</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> des=
tructor </span><span style=3D"color: #008;" class=3D"styled-by-prettify">or=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> deallocat=
or has a </span><span style=3D"color: #660;" class=3D"styled-by-prettify">(=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify">possibly <=
/span><span style=3D"color: #008;" class=3D"styled-by-prettify">implicit</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">)</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"> non</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">-</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify">throwing exception specification</spa=
n></div></code></div><br>destructor should be noexcept, <span id=3D"result_=
box" class=3D"" lang=3D"en"><span class=3D"">and I see no</span> <span clas=
s=3D"">other way to</span> <span>break</span> <span></span><span class=3D""=
>exceptions catching<br></span></span></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/d3d21e98-38be-4a5d-8f3e-becc5e80a908%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/d3d21e98-38be-4a5d-8f3e-becc5e80a908=
%40isocpp.org</a>.<br />

------=_Part_1569_406868850.1488370395022--

------=_Part_1568_1144460027.1488370395022--

.

--001a11479308be05580549aa4218
Content-Type: text/plain; charset=UTF-8

On 1 Mar 2017 12:08 pm, "'Oleg Ageev' via ISO C++ Standard - Future
Proposals" <std-proposals@isocpp.org> wrote:



On Wednesday, March 1, 2017 at 3:03:17 PM UTC+3, Giovanni Piero Deretta
wrote:
>
> you have the same issue if the lambda moves the continuation to a local
> variable, takes it by value instead of reference, or pass it to another
> function by value, etc....
>
continuation is movable only object, how it can be taked by value?



One does not exclude the other:
 Continuation x;
[](Continuation c) {....} (std::move(x)); //look ma, no copies!

--
You received this message because you are subscribed to a topic in the
Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit https://groups.google.com/a/
isocpp.org/d/topic/std-proposals/F-8aMUBPMzc/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/
isocpp.org/d/msgid/std-proposals/a880928c-208a-4f30-
8967-bf29fac87bf2%40isocpp.org
<https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/a880928c-208a-4f30-8967-bf29fac87bf2%40isocpp.org?utm_medium=email&utm_source=footer>
..

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAL52Aas%2BLakw%2Bk71%3DP6o5SedAMpmDTk30szNeozayfj71NJJuw%40mail.gmail.com.

--001a11479308be05580549aa4218
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div><br><div class=3D"gmail_extra"><br><div class=3D"gma=
il_quote">On 1 Mar 2017 12:08 pm, &quot;&#39;Oleg Ageev&#39; via ISO C++ St=
andard - Future Proposals&quot; &lt;<a href=3D"mailto:std-proposals@isocpp.=
org">std-proposals@isocpp.org</a>&gt; wrote:<br type=3D"attribution"><block=
quote class=3D"quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid=
;padding-left:1ex"><div dir=3D"ltr"><div class=3D"quoted-text"><br><br>On W=
ednesday, March 1, 2017 at 3:03:17 PM UTC+3, Giovanni Piero Deretta wrote:<=
blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border=
-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">you have the same i=
ssue if the lambda moves the continuation to a local variable, takes it by =
value instead of reference, or pass it to another function by value, etc...=
..<br></div></blockquote></div><div>continuation is movable only object, how=
 it can be taked by value?<br>=C2=A0</div></div></blockquote></div></div></=
div><div dir=3D"auto"><br></div><div dir=3D"auto">One does not exclude the =
other:</div><div dir=3D"auto">=C2=A0Continuation x;</div><div dir=3D"auto">=
[](Continuation c) {....} (std::move(x)); //look ma, no copies!</div><div d=
ir=3D"auto"><br></div><div dir=3D"auto"><div class=3D"gmail_extra"><div cla=
ss=3D"gmail_quote"><blockquote class=3D"quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div class=3D"quoted-text">

<p></p>

-- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/F-8aMUBPMzc/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/<wbr>isocpp.org/d/topic/std-<wbr>proposals/F=
-8aMUBPMzc/<wbr>unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br></div>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/a880928c-208a-4f30-8967-bf29fac87bf2%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/a880=
928c-208a-4f30-<wbr>8967-bf29fac87bf2%40isocpp.org</a><wbr>.<br>
</blockquote></div><br></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAL52Aas%2BLakw%2Bk71%3DP6o5SedAMpmDT=
k30szNeozayfj71NJJuw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAL52Aas%2B=
Lakw%2Bk71%3DP6o5SedAMpmDTk30szNeozayfj71NJJuw%40mail.gmail.com</a>.<br />

--001a11479308be05580549aa4218--

.

------=_Part_140_96015022.1488371704584
Content-Type: multipart/alternative;
 boundary="----=_Part_141_759716703.1488371704585"

------=_Part_141_759716703.1488371704585
Content-Type: text/plain; charset=UTF-8



On Wednesday, March 1, 2017 at 3:14:59 PM UTC+3, Giovanni Piero Deretta
wrote:

Did you talk about that?
  std::exception_ptr eptr;
  try
  {
    auto C = Continuation<void, void>::callcc([](auto && yield)
    {
      int counter = 0;
      do
      {
        if (counter == 10) throw std::bad_function_call();
        counter++;
      } while (yield = yield());
      return std::move(yield);
    });

    auto B = Continuation<void, int>::callcc([C=std::move(C)](auto && yield)
mutable
    {
      int ret = 0;
      do
      {
        if (!(C = C())) break;
      } while (yield = yield(ret++));
      return std::move(yield);
    });

    int ent = 0;
    while (B = B())
    {
      auto ret = B.get();
      if (ret >= 100) break;
    }

    std::cout << "main: done" << std::endl;
  }
  catch (...)
  {
    eptr = std::current_exception();
  }

but in such case exception catched and rethrown correctly

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b420b720-71e2-48ca-8a0f-288c1d76e607%40isocpp.org.

------=_Part_141_759716703.1488371704585
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Wednesday, March 1, 2017 at 3:14:59 PM UTC+3, G=
iovanni Piero Deretta wrote:<br><br>Did you talk about that?<br><div style=
=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187);=
 border-style: solid; border-width: 1px; overflow-wrap: break-word;" class=
=3D"prettyprint"><code class=3D"prettyprint"><div class=3D"subprettyprint">=
<span style=3D"color: #000;" class=3D"styled-by-prettify">=C2=A0 std</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify">exception_ptr eptr</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 </span><span st=
yle=3D"color: #008;" class=3D"styled-by-prettify">try</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 </span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"=
color: #008;" class=3D"styled-by-prettify">auto</span><span style=3D"color:=
 #000;" class=3D"styled-by-prettify"> C </span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"style=
d-by-prettify">Continuation</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">&lt;</span><span style=3D"color: #008;" class=3D"styled-by=
-prettify">void</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </s=
pan><span style=3D"color: #008;" class=3D"styled-by-prettify">void</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">&gt;::</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify">callcc</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">([](</span><span style=3D"c=
olor: #008;" class=3D"styled-by-prettify">auto</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">&amp;&amp;</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"st=
yled-by-prettify">yield</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">)</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"><br>=C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"st=
yled-by-prettify">int</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> counter </span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: #066;" class=3D"styled-by-prettify">0</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0=
 </span><span style=3D"color: #008;" class=3D"styled-by-prettify">do</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0=
 =C2=A0 </span><span style=3D"color: #660;" class=3D"styled-by-prettify">{<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =
=C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by=
-prettify">if</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify">counter </span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">=3D=3D</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #066;" class=3D"styled-by-prettify">10</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">)</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D=
"styled-by-prettify">throw</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> std</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">::</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
">bad_function_call</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">();</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 counter</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">++;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 </span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">}</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D=
"styled-by-prettify">while</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">(</span><span style=3D"color: #008;" class=3D"styled-by-prettify">yi=
eld</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"=
color: #008;" class=3D"styled-by-prettify">yield</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">());</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">return</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> std</span><span style=3D"color:=
 #660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify">move</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">(</span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">yield</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">);</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">});</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"><br><br>=C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">auto</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> B </span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span style=3D"color: #606;" class=3D"styled-by-prettify">Continuation</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><=
span style=3D"color: #008;" class=3D"styled-by-prettify">void</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">int</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">&gt;::</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">callcc</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">([</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify">C</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify">std<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify">move</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify">C</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">)](</span><span style=3D"color: #008;" clas=
s=3D"styled-by-prettify">auto</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">&amp;&amp;</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify"=
>yield</span><span style=3D"color: #660;" class=3D"styled-by-prettify">)</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span=
 style=3D"color: #008;" class=3D"styled-by-prettify">mutable</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 <=
/span><span style=3D"color: #008;" class=3D"styled-by-prettify">int</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> ret </span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #066;" class=3D"styled-by-prettify">0</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color: #=
008;" class=3D"styled-by-prettify">do</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 </span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><sp=
an style=3D"color: #008;" class=3D"styled-by-prettify">if</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">(!(</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify">C </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> C</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">()))</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">break<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =
=C2=A0 </span><span style=3D"color: #660;" class=3D"styled-by-prettify">}</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><spa=
n style=3D"color: #008;" class=3D"styled-by-prettify">while</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #008;=
" class=3D"styled-by-prettify">yield</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify"=
>yield</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify">ret</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">++));</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> =C2=A0 =C2=A0 =C2=A0<br>=
=C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by=
-prettify">return</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> std</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">move</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span=
 style=3D"color: #008;" class=3D"styled-by-prettify">yield</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">);</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">});</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"><br><br>=C2=A0 =C2=A0 </span><span=
 style=3D"color: #008;" class=3D"styled-by-prettify">int</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> ent </span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #066;" cla=
ss=3D"styled-by-prettify">0</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"styl=
ed-by-prettify">while</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">B </spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"> B</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">())</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 </span><spa=
n style=3D"color: #008;" class=3D"styled-by-prettify">auto</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> ret </span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> B</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">.</span><span style=3D"color: #008;" class=3D"s=
tyled-by-prettify">get</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">();</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"><br>=C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"=
styled-by-prettify">if</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">ret </=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;=3D</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span s=
tyle=3D"color: #066;" class=3D"styled-by-prettify">100</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">)</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" cla=
ss=3D"styled-by-prettify">break</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">}</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"><br>=C2=A0 =C2=A0 =C2=A0 <br>=C2=A0 =C2=A0 std</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify">cout </span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">&lt;&lt;</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> </span><span style=3D"color: #080;" class=
=3D"styled-by-prettify">&quot;main: done&quot;</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">&lt;&lt;</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> std</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">::</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify">endl</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
=C2=A0 </span><span style=3D"color: #660;" class=3D"styled-by-prettify">}</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 <=
/span><span style=3D"color: #008;" class=3D"styled-by-prettify">catch</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">(...)</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 </span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> <br>=C2=A0 =C2=A0 eptr </span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> std</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify">current_exception</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">();</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> <br>=C2=A0 </span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">}</span></div></code></div><br>but in su=
ch case exception catched and rethrown correctly<br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/b420b720-71e2-48ca-8a0f-288c1d76e607%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/b420b720-71e2-48ca-8a0f-288c1d76e607=
%40isocpp.org</a>.<br />

------=_Part_141_759716703.1488371704585--

------=_Part_140_96015022.1488371704584--

.

--001a114aba5eed55730549aa9612
Content-Type: text/plain; charset=UTF-8

s/auto&& yield/auto yield/ and see if things still work properly.

On 1 Mar 2017 12:35 pm, "'Oleg Ageev' via ISO C++ Standard - Future
Proposals" <std-proposals@isocpp.org> wrote:

>
>
> On Wednesday, March 1, 2017 at 3:14:59 PM UTC+3, Giovanni Piero Deretta
> wrote:
>
> Did you talk about that?
>   std::exception_ptr eptr;
>   try
>   {
>     auto C = Continuation<void, void>::callcc([](auto && yield)
>     {
>       int counter = 0;
>       do
>       {
>         if (counter == 10) throw std::bad_function_call();
>         counter++;
>       } while (yield = yield());
>       return std::move(yield);
>     });
>
>     auto B = Continuation<void, int>::callcc([C=std::move(C)](auto &&
> yield) mutable
>     {
>       int ret = 0;
>       do
>       {
>         if (!(C = C())) break;
>       } while (yield = yield(ret++));
>       return std::move(yield);
>     });
>
>     int ent = 0;
>     while (B = B())
>     {
>       auto ret = B.get();
>       if (ret >= 100) break;
>     }
>
>     std::cout << "main: done" << std::endl;
>   }
>   catch (...)
>   {
>     eptr = std::current_exception();
>   }
>
> but in such case exception catched and rethrown correctly
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit https://groups.google.com/a/
> isocpp.org/d/topic/std-proposals/F-8aMUBPMzc/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> To view this discussion on the web visit https://groups.google.com/a/
> isocpp.org/d/msgid/std-proposals/b420b720-71e2-48ca-
> 8a0f-288c1d76e607%40isocpp.org
> <https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b420b720-71e2-48ca-8a0f-288c1d76e607%40isocpp.org?utm_medium=email&utm_source=footer>
> .
>

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAL52Aauw653kq5j1LFxMKXVtiaBq0HQn3pnKn%2B9Ch2E%2Bsj1xkQ%40mail.gmail.com.

--001a114aba5eed55730549aa9612
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto">s/auto&amp;&amp; yield/auto yield/ and see if things stil=
l work properly.</div><div class=3D"gmail_extra"><br><div class=3D"gmail_qu=
ote">On 1 Mar 2017 12:35 pm, &quot;&#39;Oleg Ageev&#39; via ISO C++ Standar=
d - Future Proposals&quot; &lt;<a href=3D"mailto:std-proposals@isocpp.org">=
std-proposals@isocpp.org</a>&gt; wrote:<br type=3D"attribution"><blockquote=
 class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli=
d;padding-left:1ex"><div dir=3D"ltr"><br><br>On Wednesday, March 1, 2017 at=
 3:14:59 PM UTC+3, Giovanni Piero Deretta wrote:<br><br>Did you talk about =
that?<br><div style=3D"background-color:rgb(250,250,250);border-color:rgb(1=
87,187,187);border-style:solid;border-width:1px" class=3D"m_907869571578530=
2059prettyprint"><code class=3D"m_9078695715785302059prettyprint"><div clas=
s=3D"m_9078695715785302059subprettyprint"><span style=3D"color:#000" class=
=3D"m_9078695715785302059styled-by-prettify">=C2=A0 std</span><span style=
=3D"color:#660" class=3D"m_9078695715785302059styled-by-prettify">::</span>=
<span style=3D"color:#000" class=3D"m_9078695715785302059styled-by-prettify=
">exception_ptr eptr</span><span style=3D"color:#660" class=3D"m_9078695715=
785302059styled-by-prettify">;</span><span style=3D"color:#000" class=3D"m_=
9078695715785302059styled-by-prettify"><br>=C2=A0 </span><span style=3D"col=
or:#008" class=3D"m_9078695715785302059styled-by-prettify">try</span><span =
style=3D"color:#000" class=3D"m_9078695715785302059styled-by-prettify"><br>=
=C2=A0 </span><span style=3D"color:#660" class=3D"m_9078695715785302059styl=
ed-by-prettify">{</span><span style=3D"color:#000" class=3D"m_9078695715785=
302059styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color:#00=
8" class=3D"m_9078695715785302059styled-by-prettify">auto</span><span style=
=3D"color:#000" class=3D"m_9078695715785302059styled-by-prettify"> C </span=
><span style=3D"color:#660" class=3D"m_9078695715785302059styled-by-prettif=
y">=3D</span><span style=3D"color:#000" class=3D"m_9078695715785302059style=
d-by-prettify"> </span><span style=3D"color:#606" class=3D"m_90786957157853=
02059styled-by-prettify">Continuation</span><span style=3D"color:#660" clas=
s=3D"m_9078695715785302059styled-by-prettify">&lt;</span><span style=3D"col=
or:#008" class=3D"m_9078695715785302059styled-by-prettify">void</span><span=
 style=3D"color:#660" class=3D"m_9078695715785302059styled-by-prettify">,</=
span><span style=3D"color:#000" class=3D"m_9078695715785302059styled-by-pre=
ttify"> </span><span style=3D"color:#008" class=3D"m_9078695715785302059sty=
led-by-prettify">void</span><span style=3D"color:#660" class=3D"m_907869571=
5785302059styled-by-prettify">&gt;::</span><span style=3D"color:#000" class=
=3D"m_9078695715785302059styled-by-prettify">callcc</span><span style=3D"co=
lor:#660" class=3D"m_9078695715785302059styled-by-prettify">([](</span><spa=
n style=3D"color:#008" class=3D"m_9078695715785302059styled-by-prettify">au=
to</span><span style=3D"color:#000" class=3D"m_9078695715785302059styled-by=
-prettify"> </span><span style=3D"color:#660" class=3D"m_907869571578530205=
9styled-by-prettify">&amp;&amp;</span><span style=3D"color:#000" class=3D"m=
_9078695715785302059styled-by-prettify"> </span><span style=3D"color:#008" =
class=3D"m_9078695715785302059styled-by-prettify">yield</span><span style=
=3D"color:#660" class=3D"m_9078695715785302059styled-by-prettify">)</span><=
span style=3D"color:#000" class=3D"m_9078695715785302059styled-by-prettify"=
><br>=C2=A0 =C2=A0 </span><span style=3D"color:#660" class=3D"m_90786957157=
85302059styled-by-prettify">{</span><span style=3D"color:#000" class=3D"m_9=
078695715785302059styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 </span><span=
 style=3D"color:#008" class=3D"m_9078695715785302059styled-by-prettify">int=
</span><span style=3D"color:#000" class=3D"m_9078695715785302059styled-by-p=
rettify"> counter </span><span style=3D"color:#660" class=3D"m_907869571578=
5302059styled-by-prettify">=3D</span><span style=3D"color:#000" class=3D"m_=
9078695715785302059styled-by-prettify"> </span><span style=3D"color:#066" c=
lass=3D"m_9078695715785302059styled-by-prettify">0</span><span style=3D"col=
or:#660" class=3D"m_9078695715785302059styled-by-prettify">;</span><span st=
yle=3D"color:#000" class=3D"m_9078695715785302059styled-by-prettify"><br>=
=C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color:#008" class=3D"m_907869571=
5785302059styled-by-prettify">do</span><span style=3D"color:#000" class=3D"=
m_9078695715785302059styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 </span><s=
pan style=3D"color:#660" class=3D"m_9078695715785302059styled-by-prettify">=
{</span><span style=3D"color:#000" class=3D"m_9078695715785302059styled-by-=
prettify"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color:#008"=
 class=3D"m_9078695715785302059styled-by-prettify">if</span><span style=3D"=
color:#000" class=3D"m_9078695715785302059styled-by-prettify"> </span><span=
 style=3D"color:#660" class=3D"m_9078695715785302059styled-by-prettify">(</=
span><span style=3D"color:#000" class=3D"m_9078695715785302059styled-by-pre=
ttify">counter </span><span style=3D"color:#660" class=3D"m_907869571578530=
2059styled-by-prettify">=3D=3D</span><span style=3D"color:#000" class=3D"m_=
9078695715785302059styled-by-prettify"> </span><span style=3D"color:#066" c=
lass=3D"m_9078695715785302059styled-by-prettify">10</span><span style=3D"co=
lor:#660" class=3D"m_9078695715785302059styled-by-prettify">)</span><span s=
tyle=3D"color:#000" class=3D"m_9078695715785302059styled-by-prettify"> </sp=
an><span style=3D"color:#008" class=3D"m_9078695715785302059styled-by-prett=
ify">throw</span><span style=3D"color:#000" class=3D"m_9078695715785302059s=
tyled-by-prettify"> std</span><span style=3D"color:#660" class=3D"m_9078695=
715785302059styled-by-prettify">::</span><span style=3D"color:#000" class=
=3D"m_9078695715785302059styled-by-prettify">bad_function_call</span><span =
style=3D"color:#660" class=3D"m_9078695715785302059styled-by-prettify">();<=
/span><span style=3D"color:#000" class=3D"m_9078695715785302059styled-by-pr=
ettify"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 counter</span><span style=3D"color:=
#660" class=3D"m_9078695715785302059styled-by-prettify">++;</span><span sty=
le=3D"color:#000" class=3D"m_9078695715785302059styled-by-prettify"><br>=C2=
=A0 =C2=A0 =C2=A0 </span><span style=3D"color:#660" class=3D"m_907869571578=
5302059styled-by-prettify">}</span><span style=3D"color:#000" class=3D"m_90=
78695715785302059styled-by-prettify"> </span><span style=3D"color:#008" cla=
ss=3D"m_9078695715785302059styled-by-prettify">while</span><span style=3D"c=
olor:#000" class=3D"m_9078695715785302059styled-by-prettify"> </span><span =
style=3D"color:#660" class=3D"m_9078695715785302059styled-by-prettify">(</s=
pan><span style=3D"color:#008" class=3D"m_9078695715785302059styled-by-pret=
tify">yield</span><span style=3D"color:#000" class=3D"m_9078695715785302059=
styled-by-prettify"> </span><span style=3D"color:#660" class=3D"m_907869571=
5785302059styled-by-prettify">=3D</span><span style=3D"color:#000" class=3D=
"m_9078695715785302059styled-by-prettify"> </span><span style=3D"color:#008=
" class=3D"m_9078695715785302059styled-by-prettify">yield</span><span style=
=3D"color:#660" class=3D"m_9078695715785302059styled-by-prettify">());</spa=
n><span style=3D"color:#000" class=3D"m_9078695715785302059styled-by-pretti=
fy"><br>=C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color:#008" class=3D"m_9=
078695715785302059styled-by-prettify">return</span><span style=3D"color:#00=
0" class=3D"m_9078695715785302059styled-by-prettify"> std</span><span style=
=3D"color:#660" class=3D"m_9078695715785302059styled-by-prettify">::</span>=
<span style=3D"color:#000" class=3D"m_9078695715785302059styled-by-prettify=
">move</span><span style=3D"color:#660" class=3D"m_9078695715785302059style=
d-by-prettify">(</span><span style=3D"color:#008" class=3D"m_90786957157853=
02059styled-by-prettify">yield</span><span style=3D"color:#660" class=3D"m_=
9078695715785302059styled-by-prettify">);</span><span style=3D"color:#000" =
class=3D"m_9078695715785302059styled-by-prettify"><br>=C2=A0 =C2=A0 </span>=
<span style=3D"color:#660" class=3D"m_9078695715785302059styled-by-prettify=
">});</span><span style=3D"color:#000" class=3D"m_9078695715785302059styled=
-by-prettify"><br><br>=C2=A0 =C2=A0 </span><span style=3D"color:#008" class=
=3D"m_9078695715785302059styled-by-prettify">auto</span><span style=3D"colo=
r:#000" class=3D"m_9078695715785302059styled-by-prettify"> B </span><span s=
tyle=3D"color:#660" class=3D"m_9078695715785302059styled-by-prettify">=3D</=
span><span style=3D"color:#000" class=3D"m_9078695715785302059styled-by-pre=
ttify"> </span><span style=3D"color:#606" class=3D"m_9078695715785302059sty=
led-by-prettify">Continuation</span><span style=3D"color:#660" class=3D"m_9=
078695715785302059styled-by-prettify">&lt;</span><span style=3D"color:#008"=
 class=3D"m_9078695715785302059styled-by-prettify">void</span><span style=
=3D"color:#660" class=3D"m_9078695715785302059styled-by-prettify">,</span><=
span style=3D"color:#000" class=3D"m_9078695715785302059styled-by-prettify"=
> </span><span style=3D"color:#008" class=3D"m_9078695715785302059styled-by=
-prettify">int</span><span style=3D"color:#660" class=3D"m_9078695715785302=
059styled-by-prettify">&gt;::</span><span style=3D"color:#000" class=3D"m_9=
078695715785302059styled-by-prettify">callcc</span><span style=3D"color:#66=
0" class=3D"m_9078695715785302059styled-by-prettify">([</span><span style=
=3D"color:#000" class=3D"m_9078695715785302059styled-by-prettify">C</span><=
span style=3D"color:#660" class=3D"m_9078695715785302059styled-by-prettify"=
>=3D</span><span style=3D"color:#000" class=3D"m_9078695715785302059styled-=
by-prettify">std</span><span style=3D"color:#660" class=3D"m_90786957157853=
02059styled-by-prettify">::</span><span style=3D"color:#000" class=3D"m_907=
8695715785302059styled-by-prettify">move</span><span style=3D"color:#660" c=
lass=3D"m_9078695715785302059styled-by-prettify">(</span><span style=3D"col=
or:#000" class=3D"m_9078695715785302059styled-by-prettify">C</span><span st=
yle=3D"color:#660" class=3D"m_9078695715785302059styled-by-prettify">)](</s=
pan><span style=3D"color:#008" class=3D"m_9078695715785302059styled-by-pret=
tify"><wbr>auto</span><span style=3D"color:#000" class=3D"m_907869571578530=
2059styled-by-prettify"> </span><span style=3D"color:#660" class=3D"m_90786=
95715785302059styled-by-prettify">&amp;&amp;</span><span style=3D"color:#00=
0" class=3D"m_9078695715785302059styled-by-prettify"> </span><span style=3D=
"color:#008" class=3D"m_9078695715785302059styled-by-prettify">yield</span>=
<span style=3D"color:#660" class=3D"m_9078695715785302059styled-by-prettify=
">)</span><span style=3D"color:#000" class=3D"m_9078695715785302059styled-b=
y-prettify"> </span><span style=3D"color:#008" class=3D"m_90786957157853020=
59styled-by-prettify">mutable</span><span style=3D"color:#000" class=3D"m_9=
078695715785302059styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=
=3D"color:#660" class=3D"m_9078695715785302059styled-by-prettify">{</span><=
span style=3D"color:#000" class=3D"m_9078695715785302059styled-by-prettify"=
><br>=C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color:#008" class=3D"m_9078=
695715785302059styled-by-prettify">int</span><span style=3D"color:#000" cla=
ss=3D"m_9078695715785302059styled-by-prettify"> ret </span><span style=3D"c=
olor:#660" class=3D"m_9078695715785302059styled-by-prettify">=3D</span><spa=
n style=3D"color:#000" class=3D"m_9078695715785302059styled-by-prettify"> <=
/span><span style=3D"color:#066" class=3D"m_9078695715785302059styled-by-pr=
ettify">0</span><span style=3D"color:#660" class=3D"m_9078695715785302059st=
yled-by-prettify">;</span><span style=3D"color:#000" class=3D"m_90786957157=
85302059styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 </span><span style=3D"=
color:#008" class=3D"m_9078695715785302059styled-by-prettify">do</span><spa=
n style=3D"color:#000" class=3D"m_9078695715785302059styled-by-prettify"><b=
r>=C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color:#660" class=3D"m_9078695=
715785302059styled-by-prettify">{</span><span style=3D"color:#000" class=3D=
"m_9078695715785302059styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 <=
/span><span style=3D"color:#008" class=3D"m_9078695715785302059styled-by-pr=
ettify">if</span><span style=3D"color:#000" class=3D"m_9078695715785302059s=
tyled-by-prettify"> </span><span style=3D"color:#660" class=3D"m_9078695715=
785302059styled-by-prettify">(!(</span><span style=3D"color:#000" class=3D"=
m_9078695715785302059styled-by-prettify">C </span><span style=3D"color:#660=
" class=3D"m_9078695715785302059styled-by-prettify">=3D</span><span style=
=3D"color:#000" class=3D"m_9078695715785302059styled-by-prettify"> C</span>=
<span style=3D"color:#660" class=3D"m_9078695715785302059styled-by-prettify=
">()))</span><span style=3D"color:#000" class=3D"m_9078695715785302059style=
d-by-prettify"> </span><span style=3D"color:#008" class=3D"m_90786957157853=
02059styled-by-prettify">break</span><span style=3D"color:#660" class=3D"m_=
9078695715785302059styled-by-prettify">;</span><span style=3D"color:#000" c=
lass=3D"m_9078695715785302059styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 <=
/span><span style=3D"color:#660" class=3D"m_9078695715785302059styled-by-pr=
ettify">}</span><span style=3D"color:#000" class=3D"m_9078695715785302059st=
yled-by-prettify"> </span><span style=3D"color:#008" class=3D"m_90786957157=
85302059styled-by-prettify">while</span><span style=3D"color:#000" class=3D=
"m_9078695715785302059styled-by-prettify"> </span><span style=3D"color:#660=
" class=3D"m_9078695715785302059styled-by-prettify">(</span><span style=3D"=
color:#008" class=3D"m_9078695715785302059styled-by-prettify">yield</span><=
span style=3D"color:#000" class=3D"m_9078695715785302059styled-by-prettify"=
> </span><span style=3D"color:#660" class=3D"m_9078695715785302059styled-by=
-prettify">=3D</span><span style=3D"color:#000" class=3D"m_9078695715785302=
059styled-by-prettify"> </span><span style=3D"color:#008" class=3D"m_907869=
5715785302059styled-by-prettify">yield</span><span style=3D"color:#660" cla=
ss=3D"m_9078695715785302059styled-by-prettify">(</span><span style=3D"color=
:#000" class=3D"m_9078695715785302059styled-by-prettify">ret</span><span st=
yle=3D"color:#660" class=3D"m_9078695715785302059styled-by-prettify">++));<=
/span><span style=3D"color:#000" class=3D"m_9078695715785302059styled-by-pr=
ettify"> =C2=A0 =C2=A0 =C2=A0<br>=C2=A0 =C2=A0 =C2=A0 </span><span style=3D=
"color:#008" class=3D"m_9078695715785302059styled-by-prettify">return</span=
><span style=3D"color:#000" class=3D"m_9078695715785302059styled-by-prettif=
y"> std</span><span style=3D"color:#660" class=3D"m_9078695715785302059styl=
ed-by-prettify">::</span><span style=3D"color:#000" class=3D"m_907869571578=
5302059styled-by-prettify">move</span><span style=3D"color:#660" class=3D"m=
_9078695715785302059styled-by-prettify">(</span><span style=3D"color:#008" =
class=3D"m_9078695715785302059styled-by-prettify">yield</span><span style=
=3D"color:#660" class=3D"m_9078695715785302059styled-by-prettify">);</span>=
<span style=3D"color:#000" class=3D"m_9078695715785302059styled-by-prettify=
"><br>=C2=A0 =C2=A0 </span><span style=3D"color:#660" class=3D"m_9078695715=
785302059styled-by-prettify">});</span><span style=3D"color:#000" class=3D"=
m_9078695715785302059styled-by-prettify"><br><br>=C2=A0 =C2=A0 </span><span=
 style=3D"color:#008" class=3D"m_9078695715785302059styled-by-prettify">int=
</span><span style=3D"color:#000" class=3D"m_9078695715785302059styled-by-p=
rettify"> ent </span><span style=3D"color:#660" class=3D"m_9078695715785302=
059styled-by-prettify">=3D</span><span style=3D"color:#000" class=3D"m_9078=
695715785302059styled-by-prettify"> </span><span style=3D"color:#066" class=
=3D"m_9078695715785302059styled-by-prettify">0</span><span style=3D"color:#=
660" class=3D"m_9078695715785302059styled-by-prettify">;</span><span style=
=3D"color:#000" class=3D"m_9078695715785302059styled-by-prettify"><br>=C2=
=A0 =C2=A0 </span><span style=3D"color:#008" class=3D"m_9078695715785302059=
styled-by-prettify">while</span><span style=3D"color:#000" class=3D"m_90786=
95715785302059styled-by-prettify"> </span><span style=3D"color:#660" class=
=3D"m_9078695715785302059styled-by-prettify">(</span><span style=3D"color:#=
000" class=3D"m_9078695715785302059styled-by-prettify">B </span><span style=
=3D"color:#660" class=3D"m_9078695715785302059styled-by-prettify">=3D</span=
><span style=3D"color:#000" class=3D"m_9078695715785302059styled-by-prettif=
y"> B</span><span style=3D"color:#660" class=3D"m_9078695715785302059styled=
-by-prettify">())</span><span style=3D"color:#000" class=3D"m_9078695715785=
302059styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color:#66=
0" class=3D"m_9078695715785302059styled-by-prettify">{</span><span style=3D=
"color:#000" class=3D"m_9078695715785302059styled-by-prettify"><br>=C2=A0 =
=C2=A0 =C2=A0 </span><span style=3D"color:#008" class=3D"m_9078695715785302=
059styled-by-prettify">auto</span><span style=3D"color:#000" class=3D"m_907=
8695715785302059styled-by-prettify"> ret </span><span style=3D"color:#660" =
class=3D"m_9078695715785302059styled-by-prettify">=3D</span><span style=3D"=
color:#000" class=3D"m_9078695715785302059styled-by-prettify"> B</span><spa=
n style=3D"color:#660" class=3D"m_9078695715785302059styled-by-prettify">.<=
/span><span style=3D"color:#008" class=3D"m_9078695715785302059styled-by-pr=
ettify">get</span><span style=3D"color:#660" class=3D"m_9078695715785302059=
styled-by-prettify">();</span><span style=3D"color:#000" class=3D"m_9078695=
715785302059styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 </span><span style=
=3D"color:#008" class=3D"m_9078695715785302059styled-by-prettify">if</span>=
<span style=3D"color:#000" class=3D"m_9078695715785302059styled-by-prettify=
"> </span><span style=3D"color:#660" class=3D"m_9078695715785302059styled-b=
y-prettify">(</span><span style=3D"color:#000" class=3D"m_90786957157853020=
59styled-by-prettify">ret </span><span style=3D"color:#660" class=3D"m_9078=
695715785302059styled-by-prettify">&gt;=3D</span><span style=3D"color:#000"=
 class=3D"m_9078695715785302059styled-by-prettify"> </span><span style=3D"c=
olor:#066" class=3D"m_9078695715785302059styled-by-prettify">100</span><spa=
n style=3D"color:#660" class=3D"m_9078695715785302059styled-by-prettify">)<=
/span><span style=3D"color:#000" class=3D"m_9078695715785302059styled-by-pr=
ettify"> </span><span style=3D"color:#008" class=3D"m_9078695715785302059st=
yled-by-prettify">break</span><span style=3D"color:#660" class=3D"m_9078695=
715785302059styled-by-prettify">;</span><span style=3D"color:#000" class=3D=
"m_9078695715785302059styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span st=
yle=3D"color:#660" class=3D"m_9078695715785302059styled-by-prettify">}</spa=
n><span style=3D"color:#000" class=3D"m_9078695715785302059styled-by-pretti=
fy"><br>=C2=A0 =C2=A0 =C2=A0 <br>=C2=A0 =C2=A0 std</span><span style=3D"col=
or:#660" class=3D"m_9078695715785302059styled-by-prettify">::</span><span s=
tyle=3D"color:#000" class=3D"m_9078695715785302059styled-by-prettify">cout =
</span><span style=3D"color:#660" class=3D"m_9078695715785302059styled-by-p=
rettify">&lt;&lt;</span><span style=3D"color:#000" class=3D"m_9078695715785=
302059styled-by-prettify"> </span><span style=3D"color:#080" class=3D"m_907=
8695715785302059styled-by-prettify">&quot;main: done&quot;</span><span styl=
e=3D"color:#000" class=3D"m_9078695715785302059styled-by-prettify"> </span>=
<span style=3D"color:#660" class=3D"m_9078695715785302059styled-by-prettify=
">&lt;&lt;</span><span style=3D"color:#000" class=3D"m_9078695715785302059s=
tyled-by-prettify"> std</span><span style=3D"color:#660" class=3D"m_9078695=
715785302059styled-by-prettify">::</span><span style=3D"color:#000" class=
=3D"m_9078695715785302059styled-by-prettify">endl</span><span style=3D"colo=
r:#660" class=3D"m_9078695715785302059styled-by-prettify">;</span><span sty=
le=3D"color:#000" class=3D"m_9078695715785302059styled-by-prettify"><br>=C2=
=A0 </span><span style=3D"color:#660" class=3D"m_9078695715785302059styled-=
by-prettify">}</span><span style=3D"color:#000" class=3D"m_9078695715785302=
059styled-by-prettify"><br>=C2=A0 </span><span style=3D"color:#008" class=
=3D"m_9078695715785302059styled-by-prettify">catch</span><span style=3D"col=
or:#000" class=3D"m_9078695715785302059styled-by-prettify"> </span><span st=
yle=3D"color:#660" class=3D"m_9078695715785302059styled-by-prettify">(...)<=
/span><span style=3D"color:#000" class=3D"m_9078695715785302059styled-by-pr=
ettify"><br>=C2=A0 </span><span style=3D"color:#660" class=3D"m_90786957157=
85302059styled-by-prettify">{</span><span style=3D"color:#000" class=3D"m_9=
078695715785302059styled-by-prettify"> <br>=C2=A0 =C2=A0 eptr </span><span =
style=3D"color:#660" class=3D"m_9078695715785302059styled-by-prettify">=3D<=
/span><span style=3D"color:#000" class=3D"m_9078695715785302059styled-by-pr=
ettify"> std</span><span style=3D"color:#660" class=3D"m_907869571578530205=
9styled-by-prettify">::</span><span style=3D"color:#000" class=3D"m_9078695=
715785302059styled-by-prettify">current_exception</span><span style=3D"colo=
r:#660" class=3D"m_9078695715785302059styled-by-prettify">();</span><span s=
tyle=3D"color:#000" class=3D"m_9078695715785302059styled-by-prettify"> <br>=
=C2=A0 </span><span style=3D"color:#660" class=3D"m_9078695715785302059styl=
ed-by-prettify">}</span></div></code></div><br>but in such case exception c=
atched and rethrown correctly<br></div>

<p></p>

-- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/F-8aMUBPMzc/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/<wbr>isocpp.org/d/topic/std-<wbr>proposals/F=
-8aMUBPMzc/<wbr>unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+unsubscribe@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/b420b720-71e2-48ca-8a0f-288c1d76e607%=
40isocpp.org?utm_medium=3Demail&amp;utm_source=3Dfooter" target=3D"_blank">=
https://groups.google.com/a/<wbr>isocpp.org/d/msgid/std-<wbr>proposals/b420=
b720-71e2-48ca-<wbr>8a0f-288c1d76e607%40isocpp.org</a><wbr>.<br>
</blockquote></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAL52Aauw653kq5j1LFxMKXVtiaBq0HQn3pnK=
n%2B9Ch2E%2Bsj1xkQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAL52Aauw653k=
q5j1LFxMKXVtiaBq0HQn3pnKn%2B9Ch2E%2Bsj1xkQ%40mail.gmail.com</a>.<br />

--001a114aba5eed55730549aa9612--

.

------=_Part_1590_160592828.1488372425347
Content-Type: multipart/alternative;
 boundary="----=_Part_1591_1290424331.1488372425347"

------=_Part_1591_1290424331.1488372425347
Content-Type: text/plain; charset=UTF-8

Also... about yield from continuation without value...
I understand it's need to terminate, but we can just return from
continuation in any place, and continuation will be terminated, but we
don't need any value for that.
What else needed for termination of coroutine?
Also in initialization state we can not call continuation.
I try to write kind of coroutine based on my version of continuations

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/4f51a2b1-a7c9-4dae-8db2-b57d13dcaeac%40isocpp.org.

------=_Part_1591_1290424331.1488372425347
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Also... about yield from continuation without value...<br>=
I understand it&#39;s need to terminate, but we can just return from contin=
uation in any place, and continuation will be terminated, but we don&#39;t =
need any value for that.<br>What else needed for termination of coroutine?<=
br>Also in initialization state we can not call continuation.<br>I try to w=
rite kind of coroutine based on my version of continuations</div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/4f51a2b1-a7c9-4dae-8db2-b57d13dcaeac%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/4f51a2b1-a7c9-4dae-8db2-b57d13dcaeac=
%40isocpp.org</a>.<br />

------=_Part_1591_1290424331.1488372425347--

------=_Part_1590_160592828.1488372425347--

.

--94eb2c1989ee15c5880549aac68b
Content-Type: text/plain; charset=UTF-8

    Transfer run(Transfer t)
    {
      Ctx from{ t };
      auto recovery = from.t.fctx;
      try
      {
        Ctx cc = std::invoke(f, std::move(from));
        return { std::exchange(cc.t.fctx, nullptr), nullptr };
      }
      catch (ForcedUnwind const&)
      { throw; }
      catch (...)
      {
        except = std::current_exception();
        return { recovery, nullptr };
      }
    }

no matter what the code will not work - you have no guarantee that
'recovery' is still valid in the catch clause
as I explained the stack 'recovery' is pointing to might be invalidated
during execution of 'f'

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2Bwfc190izx%2BMhdq0QnHXt2YfcGjMTGA8mHFAN%3DTigC0UXcdUQ%40mail.gmail.com.

--94eb2c1989ee15c5880549aac68b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div><span id=3D"gmail-m_-4274184064257848844result_b=
ox" lang=3D"en"><span><code class=3D"gmail-m_-4274184064257848844prettyprin=
t"><span class=3D"gmail-m_-4274184064257848844styled-by-prettify" style=3D"=
color:rgb(102,0,102)">=C2=A0=C2=A0=C2=A0 Transfer</span><span class=3D"gmai=
l-m_-4274184064257848844styled-by-prettify" style=3D"color:rgb(0,0,0)"> run=
</span><span class=3D"gmail-m_-4274184064257848844styled-by-prettify" style=
=3D"color:rgb(102,102,0)">(</span><span class=3D"gmail-m_-42741840642578488=
44styled-by-prettify" style=3D"color:rgb(102,0,102)">Transfer</span><span c=
lass=3D"gmail-m_-4274184064257848844styled-by-prettify" style=3D"color:rgb(=
0,0,0)"> t</span><span class=3D"gmail-m_-4274184064257848844styled-by-prett=
ify" style=3D"color:rgb(102,102,0)">)</span><span class=3D"gmail-m_-4274184=
064257848844styled-by-prettify" style=3D"color:rgb(0,0,0)"><br>=C2=A0 =C2=
=A0 </span><span class=3D"gmail-m_-4274184064257848844styled-by-prettify" s=
tyle=3D"color:rgb(102,102,0)">{</span><span class=3D"gmail-m_-4274184064257=
848844styled-by-prettify" style=3D"color:rgb(0,0,0)"><br>=C2=A0 =C2=A0 =C2=
=A0 </span><span class=3D"gmail-m_-4274184064257848844styled-by-prettify" s=
tyle=3D"color:rgb(102,0,102)">Ctx</span><span class=3D"gmail-m_-42741840642=
57848844styled-by-prettify" style=3D"color:rgb(0,0,0)"> </span><span class=
=3D"gmail-m_-4274184064257848844styled-by-prettify" style=3D"color:rgb(0,0,=
136)">from</span><span class=3D"gmail-m_-4274184064257848844styled-by-prett=
ify" style=3D"color:rgb(102,102,0)">{</span><span class=3D"gmail-m_-4274184=
064257848844styled-by-prettify" style=3D"color:rgb(0,0,0)"> t </span><span =
class=3D"gmail-m_-4274184064257848844styled-by-prettify" style=3D"color:rgb=
(102,102,0)">};</span><span class=3D"gmail-m_-4274184064257848844styled-by-=
prettify" style=3D"color:rgb(0,0,0)"><br>=C2=A0 =C2=A0 =C2=A0 </span><span =
class=3D"gmail-m_-4274184064257848844styled-by-prettify" style=3D"color:rgb=
(0,0,136)">auto</span><span class=3D"gmail-m_-4274184064257848844styled-by-=
prettify" style=3D"color:rgb(0,0,0)"> recovery </span><span class=3D"gmail-=
m_-4274184064257848844styled-by-prettify" style=3D"color:rgb(102,102,0)">=
=3D</span><span class=3D"gmail-m_-4274184064257848844styled-by-prettify" st=
yle=3D"color:rgb(0,0,0)"> </span><span class=3D"gmail-m_-427418406425784884=
4styled-by-prettify" style=3D"color:rgb(0,0,136)">from</span><span class=3D=
"gmail-m_-4274184064257848844styled-by-prettify" style=3D"color:rgb(102,102=
,0)">.</span><span class=3D"gmail-m_-4274184064257848844styled-by-prettify"=
 style=3D"color:rgb(0,0,0)">t</span><span class=3D"gmail-m_-427418406425784=
8844styled-by-prettify" style=3D"color:rgb(102,102,0)">.</span><span class=
=3D"gmail-m_-4274184064257848844styled-by-prettify" style=3D"color:rgb(0,0,=
0)">fctx</span><span class=3D"gmail-m_-4274184064257848844styled-by-prettif=
y" style=3D"color:rgb(102,102,0)">;</span><span class=3D"gmail-m_-427418406=
4257848844styled-by-prettify" style=3D"color:rgb(0,0,0)"><br>=C2=A0 =C2=A0 =
=C2=A0 </span><span class=3D"gmail-m_-4274184064257848844styled-by-prettify=
" style=3D"color:rgb(0,0,136)">try</span><span class=3D"gmail-m_-4274184064=
257848844styled-by-prettify" style=3D"color:rgb(0,0,0)"><br>=C2=A0 =C2=A0 =
=C2=A0 </span><span class=3D"gmail-m_-4274184064257848844styled-by-prettify=
" style=3D"color:rgb(102,102,0)">{</span><span class=3D"gmail-m_-4274184064=
257848844styled-by-prettify" style=3D"color:rgb(0,0,0)"><br>=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 </span><span class=3D"gmail-m_-4274184064257848844styled-by-p=
rettify" style=3D"color:rgb(102,0,102)">Ctx</span><span class=3D"gmail-m_-4=
274184064257848844styled-by-prettify" style=3D"color:rgb(0,0,0)"> cc </span=
><span class=3D"gmail-m_-4274184064257848844styled-by-prettify" style=3D"co=
lor:rgb(102,102,0)">=3D</span><span class=3D"gmail-m_-4274184064257848844st=
yled-by-prettify" style=3D"color:rgb(0,0,0)"> std</span><span class=3D"gmai=
l-m_-4274184064257848844styled-by-prettify" style=3D"color:rgb(102,102,0)">=
::</span><span class=3D"gmail-m_-4274184064257848844styled-by-prettify" sty=
le=3D"color:rgb(0,0,0)">invoke</span><span class=3D"gmail-m_-42741840642578=
48844styled-by-prettify" style=3D"color:rgb(102,102,0)">(</span><span class=
=3D"gmail-m_-4274184064257848844styled-by-prettify" style=3D"color:rgb(0,0,=
0)">f</span><span class=3D"gmail-m_-4274184064257848844styled-by-prettify" =
style=3D"color:rgb(102,102,0)">,</span><span class=3D"gmail-m_-427418406425=
7848844styled-by-prettify" style=3D"color:rgb(0,0,0)"> std</span><span clas=
s=3D"gmail-m_-4274184064257848844styled-by-prettify" style=3D"color:rgb(102=
,102,0)">::</span><span class=3D"gmail-m_-4274184064257848844styled-by-pret=
tify" style=3D"color:rgb(0,0,0)">move</span><span class=3D"gmail-m_-4274184=
064257848844styled-by-prettify" style=3D"color:rgb(102,102,0)">(</span><spa=
n class=3D"gmail-m_-4274184064257848844styled-by-prettify" style=3D"color:r=
gb(0,0,136)">from</span><span class=3D"gmail-m_-4274184064257848844styled-b=
y-prettify" style=3D"color:rgb(102,102,0)">));</span><span class=3D"gmail-m=
_-4274184064257848844styled-by-prettify" style=3D"color:rgb(0,0,0)"><br>=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 </span><span class=3D"gmail-m_-4274184064257848844=
styled-by-prettify" style=3D"color:rgb(0,0,136)">return</span><span class=
=3D"gmail-m_-4274184064257848844styled-by-prettify" style=3D"color:rgb(0,0,=
0)"> </span><span class=3D"gmail-m_-4274184064257848844styled-by-prettify" =
style=3D"color:rgb(102,102,0)">{</span><span class=3D"gmail-m_-427418406425=
7848844styled-by-prettify" style=3D"color:rgb(0,0,0)"> std</span><span clas=
s=3D"gmail-m_-4274184064257848844styled-by-prettify" style=3D"color:rgb(102=
,102,0)">::</span><span class=3D"gmail-m_-4274184064257848844styled-by-pret=
tify" style=3D"color:rgb(0,0,0)">exchange</span><span class=3D"gmail-m_-427=
4184064257848844styled-by-prettify" style=3D"color:rgb(102,102,0)">(</span>=
<span class=3D"gmail-m_-4274184064257848844styled-by-prettify" style=3D"col=
or:rgb(0,0,0)">cc</span><span class=3D"gmail-m_-4274184064257848844styled-b=
y-prettify" style=3D"color:rgb(102,102,0)">.</span><span class=3D"gmail-m_-=
4274184064257848844styled-by-prettify" style=3D"color:rgb(0,0,0)">t</span><=
span class=3D"gmail-m_-4274184064257848844styled-by-prettify" style=3D"colo=
r:rgb(102,102,0)">.</span><span class=3D"gmail-m_-4274184064257848844styled=
-by-prettify" style=3D"color:rgb(0,0,0)">fctx</span><span class=3D"gmail-m_=
-4274184064257848844styled-by-prettify" style=3D"color:rgb(102,102,0)">,</s=
pan><span class=3D"gmail-m_-4274184064257848844styled-by-prettify" style=3D=
"color:rgb(0,0,0)"> </span><span class=3D"gmail-m_-4274184064257848844style=
d-by-prettify" style=3D"color:rgb(0,0,136)">nullptr</span><span class=3D"gm=
ail-m_-4274184064257848844styled-by-prettify" style=3D"color:rgb(102,102,0)=
">),</span><span class=3D"gmail-m_-4274184064257848844styled-by-prettify" s=
tyle=3D"color:rgb(0,0,0)"> </span><span class=3D"gmail-m_-42741840642578488=
44styled-by-prettify" style=3D"color:rgb(0,0,136)">nullptr</span><span clas=
s=3D"gmail-m_-4274184064257848844styled-by-prettify" style=3D"color:rgb(0,0=
,0)"> </span><span class=3D"gmail-m_-4274184064257848844styled-by-prettify"=
 style=3D"color:rgb(102,102,0)">};</span><span class=3D"gmail-m_-4274184064=
257848844styled-by-prettify" style=3D"color:rgb(0,0,0)"><br>=C2=A0 =C2=A0 =
=C2=A0 </span><span class=3D"gmail-m_-4274184064257848844styled-by-prettify=
" style=3D"color:rgb(102,102,0)">}</span><span class=3D"gmail-m_-4274184064=
257848844styled-by-prettify" style=3D"color:rgb(0,0,0)"><br>=C2=A0 =C2=A0 =
=C2=A0 </span><span class=3D"gmail-m_-4274184064257848844styled-by-prettify=
" style=3D"color:rgb(0,0,136)">catch</span><span class=3D"gmail-m_-42741840=
64257848844styled-by-prettify" style=3D"color:rgb(0,0,0)"> </span><span cla=
ss=3D"gmail-m_-4274184064257848844styled-by-prettify" style=3D"color:rgb(10=
2,102,0)">(</span><span class=3D"gmail-m_-4274184064257848844styled-by-pret=
tify" style=3D"color:rgb(102,0,102)">ForcedUnwind</span><span class=3D"gmai=
l-m_-4274184064257848844styled-by-prettify" style=3D"color:rgb(0,0,0)"> </s=
pan><span class=3D"gmail-m_-4274184064257848844styled-by-prettify" style=3D=
"color:rgb(0,0,136)">const</span><span class=3D"gmail-m_-427418406425784884=
4styled-by-prettify" style=3D"color:rgb(102,102,0)">&amp;)</span><span clas=
s=3D"gmail-m_-4274184064257848844styled-by-prettify" style=3D"color:rgb(0,0=
,0)"><br>=C2=A0 =C2=A0 =C2=A0 </span><span class=3D"gmail-m_-42741840642578=
48844styled-by-prettify" style=3D"color:rgb(102,102,0)">{</span><span class=
=3D"gmail-m_-4274184064257848844styled-by-prettify" style=3D"color:rgb(0,0,=
0)"> </span><span class=3D"gmail-m_-4274184064257848844styled-by-prettify" =
style=3D"color:rgb(0,0,136)">throw</span><span class=3D"gmail-m_-4274184064=
257848844styled-by-prettify" style=3D"color:rgb(102,102,0)">;</span><span c=
lass=3D"gmail-m_-4274184064257848844styled-by-prettify" style=3D"color:rgb(=
0,0,0)"> </span><span class=3D"gmail-m_-4274184064257848844styled-by-pretti=
fy" style=3D"color:rgb(102,102,0)">}</span><span class=3D"gmail-m_-42741840=
64257848844styled-by-prettify" style=3D"color:rgb(0,0,0)"><br>=C2=A0 =C2=A0=
 =C2=A0 </span><span class=3D"gmail-m_-4274184064257848844styled-by-prettif=
y" style=3D"color:rgb(0,0,136)">catch</span><span class=3D"gmail-m_-4274184=
064257848844styled-by-prettify" style=3D"color:rgb(0,0,0)"> </span><span cl=
ass=3D"gmail-m_-4274184064257848844styled-by-prettify" style=3D"color:rgb(1=
02,102,0)">(...)</span><span class=3D"gmail-m_-4274184064257848844styled-by=
-prettify" style=3D"color:rgb(0,0,0)"><br>=C2=A0 =C2=A0 =C2=A0 </span><span=
 class=3D"gmail-m_-4274184064257848844styled-by-prettify" style=3D"color:rg=
b(102,102,0)">{</span><span class=3D"gmail-m_-4274184064257848844styled-by-=
prettify" style=3D"color:rgb(0,0,0)"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span=
><span class=3D"gmail-m_-4274184064257848844styled-by-prettify" style=3D"co=
lor:rgb(0,0,136)">except</span><span class=3D"gmail-m_-4274184064257848844s=
tyled-by-prettify" style=3D"color:rgb(0,0,0)"> </span><span class=3D"gmail-=
m_-4274184064257848844styled-by-prettify" style=3D"color:rgb(102,102,0)">=
=3D</span><span class=3D"gmail-m_-4274184064257848844styled-by-prettify" st=
yle=3D"color:rgb(0,0,0)"> std</span><span class=3D"gmail-m_-427418406425784=
8844styled-by-prettify" style=3D"color:rgb(102,102,0)">::</span><span class=
=3D"gmail-m_-4274184064257848844styled-by-prettify" style=3D"color:rgb(0,0,=
0)">current_exception</span><span class=3D"gmail-m_-4274184064257848844styl=
ed-by-prettify" style=3D"color:rgb(102,102,0)">();</span><span class=3D"gma=
il-m_-4274184064257848844styled-by-prettify" style=3D"color:rgb(0,0,0)"><br=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span class=3D"gmail-m_-427418406425784=
8844styled-by-prettify" style=3D"color:rgb(0,0,136)">return</span><span cla=
ss=3D"gmail-m_-4274184064257848844styled-by-prettify" style=3D"color:rgb(0,=
0,0)"> </span><span class=3D"gmail-m_-4274184064257848844styled-by-prettify=
" style=3D"color:rgb(102,102,0)">{</span><span class=3D"gmail-m_-4274184064=
257848844styled-by-prettify" style=3D"color:rgb(0,0,0)"> recovery</span><sp=
an class=3D"gmail-m_-4274184064257848844styled-by-prettify" style=3D"color:=
rgb(102,102,0)">,</span><span class=3D"gmail-m_-4274184064257848844styled-b=
y-prettify" style=3D"color:rgb(0,0,0)"> </span><span class=3D"gmail-m_-4274=
184064257848844styled-by-prettify" style=3D"color:rgb(0,0,136)">nullptr</sp=
an><span class=3D"gmail-m_-4274184064257848844styled-by-prettify" style=3D"=
color:rgb(0,0,0)"> </span><span class=3D"gmail-m_-4274184064257848844styled=
-by-prettify" style=3D"color:rgb(102,102,0)">};</span><span class=3D"gmail-=
m_-4274184064257848844styled-by-prettify" style=3D"color:rgb(0,0,0)"><br>=
=C2=A0 =C2=A0 =C2=A0 </span><span class=3D"gmail-m_-4274184064257848844styl=
ed-by-prettify" style=3D"color:rgb(102,102,0)">}</span><span class=3D"gmail=
-m_-4274184064257848844styled-by-prettify" style=3D"color:rgb(0,0,0)"><br>=
=C2=A0 =C2=A0 </span><span class=3D"gmail-m_-4274184064257848844styled-by-p=
rettify" style=3D"color:rgb(102,102,0)">}<br><br></span></code></span></spa=
n></div><span id=3D"gmail-m_-4274184064257848844result_box" lang=3D"en"><sp=
an><code class=3D"gmail-m_-4274184064257848844prettyprint"><span class=3D"g=
mail-m_-4274184064257848844styled-by-prettify" style=3D"color:rgb(102,102,0=
)">no matter what the code will not work - you have no guarantee that</span=
></code></span></span><span id=3D"gmail-m_-4274184064257848844result_box" l=
ang=3D"en"><span><code class=3D"gmail-m_-4274184064257848844prettyprint"><s=
pan class=3D"gmail-m_-4274184064257848844styled-by-prettify" style=3D"color=
:rgb(102,102,0)"> &#39;recovery&#39; is still valid in the catch clause<br>=
</span></code></span></span></div><div><span id=3D"gmail-m_-427418406425784=
8844result_box" lang=3D"en"><span><code class=3D"gmail-m_-42741840642578488=
44prettyprint"><span class=3D"gmail-m_-4274184064257848844styled-by-prettif=
y" style=3D"color:rgb(102,102,0)">as I explained the stack &#39;recovery&#3=
9; is pointing to might be invalidated during execution of &#39;f&#39;<br><=
/span></code></span></span></div><div><span id=3D"gmail-m_-4274184064257848=
844result_box" lang=3D"en"><span><code class=3D"gmail-m_-427418406425784884=
4prettyprint"><span class=3D"gmail-m_-4274184064257848844styled-by-prettify=
" style=3D"color:rgb(102,102,0)"><br></span></code></span></span><span id=
=3D"gmail-m_-4274184064257848844result_box" lang=3D"en"><span><code class=
=3D"gmail-m_-4274184064257848844prettyprint"><span class=3D"gmail-m_-427418=
4064257848844styled-by-prettify" style=3D"color:rgb(102,102,0)"></span></co=
de></span></span></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CA%2Bwfc190izx%2BMhdq0QnHXt2YfcGjMTGA=
8mHFAN%3DTigC0UXcdUQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoote=
r">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2Bwfc190=
izx%2BMhdq0QnHXt2YfcGjMTGA8mHFAN%3DTigC0UXcdUQ%40mail.gmail.com</a>.<br />

--94eb2c1989ee15c5880549aac68b--

.

------=_Part_10372_935153282.1488382693011
Content-Type: multipart/alternative;
 boundary="----=_Part_10373_438720183.1488382693011"

------=_Part_10373_438720183.1488382693011
Content-Type: text/plain; charset=UTF-8

On Wednesday, March 1, 2017 at 6:39:18 AM UTC-5, Giovanni Piero Deretta
wrote:
>
> On Wednesday, March 1, 2017 at 3:01:25 AM UTC, Nicol Bolas wrote:
>
>>
>> On Tuesday, February 28, 2017 at 9:24:38 PM UTC-5, Oleg Ageev wrote:
>>>
>>> Hello,
>>>
>>> I have some questions about call/cc in proposed implementation
>>>
>>> I think possibility put any arguments in continuation and access to them
>>> through template function it is lack of type safety, and isn't good idea to
>>> propose it in standard.
>>> Why not specialize continuation with type of input and type of output?
>>>
>>
>> Because:
>>
>> 1) That would limit what you can do with continuations. As currently
>> proposed, you can pass different parameters to different parts of
>> continuations. Your idea fixes the interface at call/cc time.
>>
>> 2) P0534 is intended to be as low level as possible while still being
>> functional. By specializing types, it would be higher level than strictly
>> *necessary*.
>>
>
> FWIW, I strongly disagree. Getting continuation correctly typed is
> important and any help the compiler can give when using such a mind-bending
> construct as a continuation is very welcome. In particular getting the
> typing of something like invoke_on_top is non trivial (it certainly took me
> a few tries).
>

A type-safe version of the data passing API is important and should be
shipped with this system. The reason being that the system can implement it
more efficiently than the user can.

For example, the current system could gain reasonable type safety by
passing everything via `std::any`. However, doing so brings with it some
baggage. `any` can only be used with copyable types, which is an
unnecessary restriction for our needs. If the `T` is somewhat large, `any`
will dynamically allocate memory for it, whereas the unsafe API always uses
the continuation's stack for the object.

Now of course, one can implement safe typing by wrapping `callcc` and
`continuation` by implementing the guts of an `any`. Essentially, each
numbered parameter would be 2 actual parameters: the value itself and its
`type_index`. And when you cast it back, if the index you ask for doesn't
match the one used by the parameter, an exception is thrown or whatever.

The problem is, as always with low-level tools, inter-operability. If you
don't provide higher-level tools at the same time as lower-level ones, you
encourage fragmentation. My `safe_callcc/safe_continuation` can't work with
someone else's `safe_callcc/safe_continuation`, even if they're doing the
same thing.

So we need the safe mechanism, and we need it shipped with the system. But
that should not be the *only* way; the lower-level form should still exist.

Now, maybe the type-safe version should be the *default*, so that if you
want the lower-level, unsafe API, we can clearly see that safety is being
sacrificed. So `callcc/continuation` would naturally be type-safe, with
`unsafe_callcc/unsafe_continuation` being not type safe.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/312d04a6-8b20-4bf5-8357-507ba9938e84%40isocpp.org.

------=_Part_10373_438720183.1488382693011
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wednesday, March 1, 2017 at 6:39:18 AM UTC-5, Giovanni =
Piero Deretta wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr">On Wednesday, March 1, 2017 at 3:01:25 AM UTC, Nicol Bolas wrote:<=
br><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br>On Tuesday,=
 February 28, 2017 at 9:24:38 PM UTC-5, Oleg Ageev wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr">Hello,<br><br>I have some questions=
 about call/cc in proposed implementation<br><br>I think possibility put an=
y arguments in continuation and access to them through template function it=
 is lack of type safety, and isn&#39;t good idea to propose it in standard.=
<br>Why not specialize continuation with type of input and type of output?<=
br></div></blockquote><div><br>Because:<br><br>1) That would limit what you=
 can do with continuations. As currently proposed, you can pass different p=
arameters to different parts of continuations. Your idea fixes the interfac=
e at call/cc time.<br><br>2) P0534 is intended to be as low level as possib=
le while still being functional. By specializing types, it would be higher =
level than strictly <i>necessary</i>.<br></div></div></blockquote><div><br>=
FWIW, I strongly disagree. Getting continuation correctly typed is importan=
t and any help the compiler can give when using such a mind-bending constru=
ct as a continuation is very welcome. In particular getting the typing of s=
omething like invoke_on_top is non trivial (it certainly took me a few trie=
s).<br></div></div></blockquote><div><br>A type-safe version of the data pa=
ssing API is important and should be shipped with this system. The reason b=
eing that the system can implement it more efficiently than the user can.<b=
r><br>For example, the current system could gain reasonable type safety by =
passing everything via `std::any`. However, doing so brings with it some ba=
ggage. `any` can only be used with copyable types, which is an unnecessary =
restriction for our needs. If the `T` is somewhat large, `any` will dynamic=
ally allocate memory for it, whereas the unsafe API always uses the continu=
ation&#39;s stack for the object.<br><br>Now of course, one can implement s=
afe typing by wrapping `callcc` and `continuation` by implementing the guts=
 of an `any`. Essentially, each numbered parameter would be 2 actual parame=
ters: the value itself and its `type_index`. And when you cast it back, if =
the index you ask for doesn&#39;t match the one used by the parameter, an e=
xception is thrown or whatever.<br><br>The problem is, as always with low-l=
evel tools, inter-operability. If you don&#39;t provide higher-level tools =
at the same time as lower-level ones, you encourage fragmentation. My `safe=
_callcc/safe_continuation` can&#39;t work with someone else&#39;s `safe_cal=
lcc/safe_continuation`, even if they&#39;re doing the same thing.<br><br>So=
 we need the safe mechanism, and we need it shipped with the system. But th=
at should not be the <i>only</i> way; the lower-level form should still exi=
st.<br><br>Now, maybe the type-safe version should be the <i>default</i>, s=
o that if you want the lower-level, unsafe API, we can clearly see that saf=
ety is being sacrificed. So `callcc/continuation` would naturally be type-s=
afe, with `unsafe_callcc/unsafe_continuation` being not type safe.<br></div=
></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/312d04a6-8b20-4bf5-8357-507ba9938e84%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/312d04a6-8b20-4bf5-8357-507ba9938e84=
%40isocpp.org</a>.<br />

------=_Part_10373_438720183.1488382693011--

------=_Part_10372_935153282.1488382693011--

.

------=_Part_1530_250009922.1488383319962
Content-Type: multipart/alternative;
 boundary="----=_Part_1531_1149064119.1488383319963"

------=_Part_1531_1149064119.1488383319963
Content-Type: text/plain; charset=UTF-8

On Wednesday, March 1, 2017 at 3:38:13 PM UTC, Nicol Bolas wrote:
[...]

>
> So we need the safe mechanism, and we need it shipped with the system. But
> that should not be the *only* way; the lower-level form should still
> exist.
>
> Now, maybe the type-safe version should be the *default*, so that if you
> want the lower-level, unsafe API, we can clearly see that safety is being
> sacrificed. So `callcc/continuation` would naturally be type-safe, with
> `unsafe_callcc/unsafe_continuation` being not type safe.
>

we are in agreement then, I just want to point out that, given a type safe
std::continuation<T> implementation, the unsafe variant would simply be
std::continuation<void*>, while the dynamic variant would be
continuation<std::any_ptr>, given a suitable implementation of any_ptr.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/a3c76a9f-ef02-4ea7-a754-66ee5a95b38f%40isocpp.org.

------=_Part_1531_1149064119.1488383319963
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wednesday, March 1, 2017 at 3:38:13 PM UTC, Nicol Bolas=
 wrote:<br>[...]<br><blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><br><div>So we need the safe mechanism, and we need it shipped wit=
h the system. But that should not be the <i>only</i> way; the lower-level f=
orm should still exist.<br><br>Now, maybe the type-safe version should be t=
he <i>default</i>, so that if you want the lower-level, unsafe API, we can =
clearly see that safety is being sacrificed. So `callcc/continuation` would=
 naturally be type-safe, with `unsafe_callcc/unsafe_<wbr>continuation` bein=
g not type safe.<br></div></div></blockquote><div><br>we are in agreement t=
hen, I just want to point out that, given a type safe std::continuation&lt;=
T&gt; implementation, the unsafe variant would simply be std::continuation&=
lt;void*&gt;, while the dynamic variant would be continuation&lt;std::any_p=
tr&gt;, given a suitable implementation of any_ptr.<br><br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/a3c76a9f-ef02-4ea7-a754-66ee5a95b38f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a3c76a9f-ef02-4ea7-a754-66ee5a95b38f=
%40isocpp.org</a>.<br />

------=_Part_1531_1149064119.1488383319963--

------=_Part_1530_250009922.1488383319962--

.

------=_Part_1723_1934979828.1488384356279
Content-Type: multipart/alternative;
 boundary="----=_Part_1724_1462759686.1488384356280"

------=_Part_1724_1462759686.1488384356280
Content-Type: text/plain; charset=UTF-8

On Wednesday, March 1, 2017 at 3:51:41 PM UTC+3, Oliver Kowalke wrote:
>
> no matter what the code will not work - you have no guarantee that
> 'recovery' is still valid in the catch clause
> as I explained the stack 'recovery' is pointing to might be invalidated
> during execution of 'f'
>
I don't understand, Ok, exception handling will not work in that place, but
exception handling implemented in boost.coroutine2, why such mechanism
can't be implemented on top of any continuation?

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f6de6edb-f0ff-419b-8633-e8b931eaba34%40isocpp.org.

------=_Part_1724_1462759686.1488384356280
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wednesday, March 1, 2017 at 3:51:41 PM UTC+3, Oliver Ko=
walke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><=
div><span lang=3D"en"><span><code><span style=3D"color:rgb(102,102,0)">no m=
atter what the code will not work - you have no guarantee that</span></code=
></span></span><span lang=3D"en"><span><code><span style=3D"color:rgb(102,1=
02,0)"> &#39;recovery&#39; is still valid in the catch clause<br></span></c=
ode></span></span></div><div><span lang=3D"en"><span><code><span style=3D"c=
olor:rgb(102,102,0)">as I explained the stack &#39;recovery&#39; is pointin=
g to might be invalidated during execution of &#39;f&#39;<br></span></code>=
</span></span></div></div></blockquote><div>I don&#39;t understand, Ok, exc=
eption handling will not work in that place, but exception handling impleme=
nted in boost.coroutine2, why such mechanism can&#39;t be implemented on to=
p of any continuation?<br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/f6de6edb-f0ff-419b-8633-e8b931eaba34%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f6de6edb-f0ff-419b-8633-e8b931eaba34=
%40isocpp.org</a>.<br />

------=_Part_1724_1462759686.1488384356280--

------=_Part_1723_1934979828.1488384356279--

.

--94eb2c1476ea01527d0549ada83f
Content-Type: text/plain; charset=UTF-8

2017-03-01 17:05 GMT+01:00 'Oleg Ageev' via ISO C++ Standard - Future
Proposals <std-proposals@isocpp.org>:

> On Wednesday, March 1, 2017 at 3:51:41 PM UTC+3, Oliver Kowalke wrote:
>>
>> no matter what the code will not work - you have no guarantee that
>> 'recovery' is still valid in the catch clause
>> as I explained the stack 'recovery' is pointing to might be invalidated
>> during execution of 'f'
>>
> I don't understand, Ok, exception handling will not work in that place,
> but exception handling implemented in boost.coroutine2, why such mechanism
> can't be implemented on top of any continuation?
>

bosot.coroutine2 is based on call/cc - but in contrast to call/cc the
coroutiens provided by bosot.coroutine2 are asymmetric
asymmetric means that caller and callee are tighly coupled -> caller can
only jump to callee and the callee can only jump to its caller
call/cc from P0534 is symmetric - that enables asymmetric coroutines (as
boost.coroutine2 provides) as well someting like fibers (boost.fiber is
based on callcc too). fibers are not stronly coupled (a fiber can switch to
any other abritrary fiber)

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2Bwfc1__-bi9b9JYY8VQuRPgDzmSL%3DyBdYHJj23xWC-xTUOD3A%40mail.gmail.com.

--94eb2c1476ea01527d0549ada83f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">2017=
-03-01 17:05 GMT+01:00 &#39;Oleg Ageev&#39; via ISO C++ Standard - Future P=
roposals <span dir=3D"ltr">&lt;<a href=3D"mailto:std-proposals@isocpp.org" =
target=3D"_blank">std-proposals@isocpp.org</a>&gt;</span>:<br><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex"><div dir=3D"ltr"><span class=3D"">On Wednesday, March 1, =
2017 at 3:51:41 PM UTC+3, Oliver Kowalke wrote:<blockquote class=3D"gmail_q=
uote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;paddin=
g-left:1ex"><div dir=3D"ltr"><div><span lang=3D"en"><span><code><span style=
=3D"color:rgb(102,102,0)">no matter what the code will not work - you have =
no guarantee that</span></code></span></span><span lang=3D"en"><span><code>=
<span style=3D"color:rgb(102,102,0)"> &#39;recovery&#39; is still valid in =
the catch clause<br></span></code></span></span></div><div><span lang=3D"en=
"><span><code><span style=3D"color:rgb(102,102,0)">as I explained the stack=
 &#39;recovery&#39; is pointing to might be invalidated during execution of=
 &#39;f&#39;<br></span></code></span></span></div></div></blockquote></span=
><div>I don&#39;t understand, Ok, exception handling will not work in that =
place, but exception handling implemented in boost.coroutine2, why such mec=
hanism can&#39;t be implemented on top of any continuation?<br></div></div>=
</blockquote></div><br></div><div class=3D"gmail_extra">bosot.coroutine2 is=
 based on call/cc - but in contrast to call/cc the coroutiens provided by b=
osot.coroutine2 are asymmetric<br></div><div class=3D"gmail_extra">asymmetr=
ic means that caller and callee are tighly coupled -&gt; caller can only ju=
mp to callee and the callee can only jump to its caller<br></div><div class=
=3D"gmail_extra">call/cc from P0534 is symmetric - that enables asymmetric =
coroutines (as boost.coroutine2 provides) as well someting like fibers (boo=
st.fiber is based on callcc too). fibers are not stronly coupled (a fiber c=
an switch to any other abritrary fiber)<br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CA%2Bwfc1__-bi9b9JYY8VQuRPgDzmSL%3DyB=
dYHJj23xWC-xTUOD3A%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2Bwfc1__-b=
i9b9JYY8VQuRPgDzmSL%3DyBdYHJj23xWC-xTUOD3A%40mail.gmail.com</a>.<br />

--94eb2c1476ea01527d0549ada83f--

.

--001a11c03ed87582a50549adc592
Content-Type: text/plain; charset=UTF-8

2017-03-01 16:48 GMT+01:00 Giovanni Piero Deretta <gpderetta@gmail.com>:

> On Wednesday, March 1, 2017 at 3:38:13 PM UTC, Nicol Bolas wrote:
> [...]
>
>>
>> So we need the safe mechanism, and we need it shipped with the system.
>> But that should not be the *only* way; the lower-level form should still
>> exist.
>>
>> Now, maybe the type-safe version should be the *default*, so that if you
>> want the lower-level, unsafe API, we can clearly see that safety is being
>> sacrificed. So `callcc/continuation` would naturally be type-safe, with
>> `unsafe_callcc/unsafe_continuation` being not type safe.
>>
>
> we are in agreement then, I just want to point out that, given a type safe
> std::continuation<T> implementation, the unsafe variant would simply be
> std::continuation<void*>
>

and this would require std::continuation<void> too - so we end up in three
specialisations of std::continuation<>

I prefer a template-less std::continuation - it's more flexible.
For instance the implementation of P0534 (continuation not a template)  is
used to implement boost.coroutine2 (higher-level abstraction) which is
type-safe.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2Bwfc1-9VTCADr2E_QgJbYLVdBeAGO6MnrYydoAn%2BxYwbMuUyQ%40mail.gmail.com.

--001a11c03ed87582a50549adc592
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">2017=
-03-01 16:48 GMT+01:00 Giovanni <span class=3D"" style=3D"" id=3D":12b.25" =
tabindex=3D"-1">Piero</span> <span class=3D"" style=3D"" id=3D":12b.26" tab=
index=3D"-1">Deretta</span> <span dir=3D"ltr">&lt;<a href=3D"mailto:gpderet=
ta@gmail.com" target=3D"_blank"><span class=3D"" style=3D"" id=3D":12b.27" =
tabindex=3D"-1">gpderetta</span>@gmail.com</a>&gt;</span>:<br><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex"><div dir=3D"ltr">On Wednesday, March 1, 2017 at 3:38:13 P=
M UTC, Nicol Bolas wrote:<br>[...]<span class=3D""><br><blockquote class=3D=
"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc soli=
d;padding-left:1ex"><div dir=3D"ltr"><br><div>So we need the safe mechanism=
, and we need it shipped with the system. But that should not be the <i>onl=
y</i> way; the lower-level form should still exist.<br><br>Now, maybe the t=
ype-safe version should be the <i>default</i>, so that if you want the lowe=
r-level, unsafe API, we can clearly see that safety is being sacrificed. So=
 `callcc/continuation` would naturally be type-safe, with `unsafe_callcc/un=
safe_continua<wbr>tion` being not type safe.<br></div></div></blockquote></=
span><div><br>we are in agreement then, I just want to point out that, give=
n a type safe std::continuation&lt;T&gt; implementation, the unsafe variant=
 would simply be std::continuation&lt;void*&gt;<br></div></div></blockquote=
><div><br></div><div>and this would require std::continuation&lt;void&gt; t=
oo - so we end up in three specialisations of std::continuation&lt;&gt;<br>=
<br></div><div>I prefer a template-less std::continuation - it&#39;s more f=
lexible.<br></div><div>For instance the implementation of P0534 (continuati=
on not a template)=C2=A0 is used to implement boost.coroutine2 (higher-leve=
l abstraction) which is type-safe.<br><br></div></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CA%2Bwfc1-9VTCADr2E_QgJbYLVdBeAGO6Mnr=
YydoAn%2BxYwbMuUyQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2Bwfc1-9VT=
CADr2E_QgJbYLVdBeAGO6MnrYydoAn%2BxYwbMuUyQ%40mail.gmail.com</a>.<br />

--001a11c03ed87582a50549adc592--

.

------=_Part_1595_1176689288.1488386420257
Content-Type: multipart/alternative;
 boundary="----=_Part_1596_1187765739.1488386420257"

------=_Part_1596_1187765739.1488386420257
Content-Type: text/plain; charset=UTF-8

On Wednesday, March 1, 2017 at 4:26:16 PM UTC, Oliver Kowalke wrote:
>
> 2017-03-01 16:48 GMT+01:00 Giovanni Piero Deretta <gpderetta@gmail.com
> <javascript:>>:
>
>> On Wednesday, March 1, 2017 at 3:38:13 PM UTC, Nicol Bolas wrote:
>> [...]
>>
>>>
>>> So we need the safe mechanism, and we need it shipped with the system.
>>> But that should not be the *only* way; the lower-level form should
>>> still exist.
>>>
>>> Now, maybe the type-safe version should be the *default*, so that if
>>> you want the lower-level, unsafe API, we can clearly see that safety is
>>> being sacrificed. So `callcc/continuation` would naturally be type-safe,
>>> with `unsafe_callcc/unsafe_continuation` being not type safe.
>>>
>>
>> we are in agreement then, I just want to point out that, given a type
>> safe std::continuation<T> implementation, the unsafe variant would simply
>> be std::continuation<void*>
>>
>
> and this would require std::continuation<void> too - so we end up in three
> specialisations of std::continuation<>
>
>
My preference for a low level design would be a std::countinuation<T1,T2>
(the in and out parameters need not be the same), that only allows
forwarding pointers to T1, T2 (that what continuation would do internally
anyway). The empty case is handled simply by passing nullptr. There is no
need for any specialization this way.



> I prefer a template-less std::continuation - it's more flexible.
>

If you want to provide a template less std::continuation, then you should
drop the typed get_data<T> and simply have a void* get_data().


--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/3df02165-897f-4655-9cfb-4f55c0234b7b%40isocpp.org.

------=_Part_1596_1187765739.1488386420257
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wednesday, March 1, 2017 at 4:26:16 PM UTC, Oliver Kowa=
lke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><di=
v><div class=3D"gmail_quote">2017-03-01 16:48 GMT+01:00 Giovanni <span>Pier=
o</span> <span>Deretta</span> <span dir=3D"ltr">&lt;<a href=3D"javascript:"=
 target=3D"_blank" gdf-obfuscated-mailto=3D"sdrO0U22CQAJ" rel=3D"nofollow" =
onmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"t=
his.href=3D&#39;javascript:&#39;;return true;"><span>gpderetta</span>@gmail=
..com</a>&gt;</span>:<br><blockquote class=3D"gmail_quote" style=3D"margin:0=
 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On =
Wednesday, March 1, 2017 at 3:38:13 PM UTC, Nicol Bolas wrote:<br>[...]<spa=
n><br><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><div>So =
we need the safe mechanism, and we need it shipped with the system. But tha=
t should not be the <i>only</i> way; the lower-level form should still exis=
t.<br><br>Now, maybe the type-safe version should be the <i>default</i>, so=
 that if you want the lower-level, unsafe API, we can clearly see that safe=
ty is being sacrificed. So `callcc/continuation` would naturally be type-sa=
fe, with `unsafe_callcc/unsafe_<wbr>continuation` being not type safe.<br><=
/div></div></blockquote></span><div><br>we are in agreement then, I just wa=
nt to point out that, given a type safe std::continuation&lt;T&gt; implemen=
tation, the unsafe variant would simply be std::continuation&lt;void*&gt;<b=
r></div></div></blockquote><div><br></div><div>and this would require std::=
continuation&lt;void&gt; too - so we end up in three specialisations of std=
::continuation&lt;&gt;<br><br></div></div></div></div></blockquote><div><br=
>My preference for a low level design would be a std::countinuation&lt;T1,T=
2&gt; (the in and out parameters need not be the same), that only allows fo=
rwarding pointers to T1, T2 (that what continuation would do internally any=
way). The empty case is handled simply by passing nullptr. There is no need=
 for any specialization this way.<br><br>=C2=A0</div><blockquote class=3D"g=
mail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc sol=
id;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><di=
v></div><div>I prefer a template-less std::continuation - it&#39;s more fle=
xible.<br></div></div></div></div></blockquote><div><br>If you want to prov=
ide a template less std::continuation, then you should drop the typed get_d=
ata&lt;T&gt; and simply have a void* get_data(). <br><br><br></div><blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left=
: 1px #ccc solid;padding-left: 1ex;">
</blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/3df02165-897f-4655-9cfb-4f55c0234b7b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/3df02165-897f-4655-9cfb-4f55c0234b7b=
%40isocpp.org</a>.<br />

------=_Part_1596_1187765739.1488386420257--

------=_Part_1595_1176689288.1488386420257--

.

------=_Part_10812_899290570.1488387046389
Content-Type: multipart/alternative;
 boundary="----=_Part_10813_823472932.1488387046389"

------=_Part_10813_823472932.1488387046389
Content-Type: text/plain; charset=UTF-8



On Wednesday, March 1, 2017 at 10:48:40 AM UTC-5, Giovanni Piero Deretta
wrote:
>
> On Wednesday, March 1, 2017 at 3:38:13 PM UTC, Nicol Bolas wrote:
> [...]
>
>>
>> So we need the safe mechanism, and we need it shipped with the system.
>> But that should not be the *only* way; the lower-level form should still
>> exist.
>>
>> Now, maybe the type-safe version should be the *default*, so that if you
>> want the lower-level, unsafe API, we can clearly see that safety is being
>> sacrificed. So `callcc/continuation` would naturally be type-safe, with
>> `unsafe_callcc/unsafe_continuation` being not type safe.
>>
>
> we are in agreement then, I just want to point out that, given a type safe
> std::continuation<T> implementation, the unsafe variant would simply be
> std::continuation<void*>, while the dynamic variant would be
> continuation<std::any_ptr>, given a suitable implementation of any_ptr.
>

I don't think you understood what I meant when I said "type safe". I
specifically *don't* mean that the continuation has a static and typed set
of parameters. What I mean is that getting the parameter back is
type-checked and therefore safe. But it's a *runtime* check, not a
compile-time check.

This prevents compile-time tight coupling while still having safety on the
receiving end.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/762243ed-0c31-461d-b6fd-fdb8759857b2%40isocpp.org.

------=_Part_10813_823472932.1488387046389
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Wednesday, March 1, 2017 at 10:48:40 AM UTC-5, =
Giovanni Piero Deretta wrote:<blockquote class=3D"gmail_quote" style=3D"mar=
gin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><=
div dir=3D"ltr">On Wednesday, March 1, 2017 at 3:38:13 PM UTC, Nicol Bolas =
wrote:<br>[...]<br><blockquote class=3D"gmail_quote" style=3D"margin:0;marg=
in-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"=
><br><div>So we need the safe mechanism, and we need it shipped with the sy=
stem. But that should not be the <i>only</i> way; the lower-level form shou=
ld still exist.<br><br>Now, maybe the type-safe version should be the <i>de=
fault</i>, so that if you want the lower-level, unsafe API, we can clearly =
see that safety is being sacrificed. So `callcc/continuation` would natural=
ly be type-safe, with `unsafe_callcc/unsafe_<wbr>continuation` being not ty=
pe safe.<br></div></div></blockquote><div><br>we are in agreement then, I j=
ust want to point out that, given a type safe std::continuation&lt;T&gt; im=
plementation, the unsafe variant would simply be std::continuation&lt;void*=
&gt;, while the dynamic variant would be continuation&lt;std::any_ptr&gt;, =
given a suitable implementation of any_ptr.<br></div></div></blockquote><di=
v><br>I don&#39;t think you understood what I meant when I said &quot;type =
safe&quot;. I specifically <i>don&#39;t</i> mean that the continuation has =
a static and typed set of parameters. What I mean is that getting the param=
eter back is type-checked and therefore safe. But it&#39;s a <i>runtime</i>=
 check, not a compile-time check.<br><br>This prevents compile-time tight c=
oupling while still having safety on the receiving end.<br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/762243ed-0c31-461d-b6fd-fdb8759857b2%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/762243ed-0c31-461d-b6fd-fdb8759857b2=
%40isocpp.org</a>.<br />

------=_Part_10813_823472932.1488387046389--

------=_Part_10812_899290570.1488387046389--

.

------=_Part_1898_289746571.1488388687074
Content-Type: multipart/alternative;
 boundary="----=_Part_1899_298338664.1488388687075"

------=_Part_1899_298338664.1488388687075
Content-Type: text/plain; charset=UTF-8

On Wednesday, March 1, 2017 at 4:50:46 PM UTC, Nicol Bolas wrote:
>
>
>
> On Wednesday, March 1, 2017 at 10:48:40 AM UTC-5, Giovanni Piero Deretta
> wrote:
>>
>> On Wednesday, March 1, 2017 at 3:38:13 PM UTC, Nicol Bolas wrote:
>> [...]
>>
>>>
>>> So we need the safe mechanism, and we need it shipped with the system.
>>> But that should not be the *only* way; the lower-level form should
>>> still exist.
>>>
>>> Now, maybe the type-safe version should be the *default*, so that if
>>> you want the lower-level, unsafe API, we can clearly see that safety is
>>> being sacrificed. So `callcc/continuation` would naturally be type-safe,
>>> with `unsafe_callcc/unsafe_continuation` being not type safe.
>>>
>>
>> we are in agreement then, I just want to point out that, given a type
>> safe std::continuation<T> implementation, the unsafe variant would simply
>> be std::continuation<void*>, while the dynamic variant would be
>> continuation<std::any_ptr>, given a suitable implementation of any_ptr.
>>
>
> I don't think you understood what I meant when I said "type safe". I
> specifically *don't* mean that the continuation has a static and typed
> set of parameters. What I mean is that getting the parameter back is
> type-checked and therefore safe. But it's a *runtime* check, not a
> compile-time check.
>
> This prevents compile-time tight coupling while still having safety on the
> receiving end.
>

Hum, but this means that those that want statically check type safety (a
very common use case, think generators), are left in the cold and need to
roll their own continuation type on top of the unsafe one. I still don't
see the need for a dynamically checked continuation type.

For example, std::function is a vocabulary type designed for
interoperability and decoupling, but it still check the signature a compile
time. A runtime checked std::function is possible, but not desirable
(incidentally Qt slot types used to be only dynamically checked and it was
a pain). I don't see why continuation would be different (in fact there is
a very strong affinity between continuations and functions).


--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f8a573b1-c4ff-48a2-8a6f-51433732ab26%40isocpp.org.

------=_Part_1899_298338664.1488388687075
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wednesday, March 1, 2017 at 4:50:46 PM UTC, Nicol Bolas=
 wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.=
8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><br><b=
r>On Wednesday, March 1, 2017 at 10:48:40 AM UTC-5, Giovanni Piero Deretta =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Wednesday=
, March 1, 2017 at 3:38:13 PM UTC, Nicol Bolas wrote:<br>[...]<br><blockquo=
te class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><div>So we need the saf=
e mechanism, and we need it shipped with the system. But that should not be=
 the <i>only</i> way; the lower-level form should still exist.<br><br>Now, =
maybe the type-safe version should be the <i>default</i>, so that if you wa=
nt the lower-level, unsafe API, we can clearly see that safety is being sac=
rificed. So `callcc/continuation` would naturally be type-safe, with `unsaf=
e_callcc/unsafe_<wbr>continuation` being not type safe.<br></div></div></bl=
ockquote><div><br>we are in agreement then, I just want to point out that, =
given a type safe std::continuation&lt;T&gt; implementation, the unsafe var=
iant would simply be std::continuation&lt;void*&gt;, while the dynamic vari=
ant would be continuation&lt;std::any_ptr&gt;, given a suitable implementat=
ion of any_ptr.<br></div></div></blockquote><div><br>I don&#39;t think you =
understood what I meant when I said &quot;type safe&quot;. I specifically <=
i>don&#39;t</i> mean that the continuation has a static and typed set of pa=
rameters. What I mean is that getting the parameter back is type-checked an=
d therefore safe. But it&#39;s a <i>runtime</i> check, not a compile-time c=
heck.<br><br>This prevents compile-time tight coupling while still having s=
afety on the receiving end.<br></div></div></blockquote><div><br>Hum, but t=
his means that those that want statically check type safety (a very common =
use case, think generators), are left in the cold and need to roll their ow=
n continuation type on top of the unsafe one. I still don&#39;t see the nee=
d for a dynamically checked continuation type. <br><br>For example, std::fu=
nction is a vocabulary type designed for interoperability and decoupling, b=
ut it still check the signature a compile time. A runtime checked std::func=
tion is possible, but not desirable (incidentally Qt slot types used to be =
only dynamically checked and it was a pain). I don&#39;t see why continuati=
on would be different (in fact there is a very strong affinity between cont=
inuations and functions).<br>=C2=A0</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/f8a573b1-c4ff-48a2-8a6f-51433732ab26%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f8a573b1-c4ff-48a2-8a6f-51433732ab26=
%40isocpp.org</a>.<br />

------=_Part_1899_298338664.1488388687075--

------=_Part_1898_289746571.1488388687074--

.

------=_Part_1979_805564204.1488399721170
Content-Type: multipart/alternative;
 boundary="----=_Part_1980_941472134.1488399721170"

------=_Part_1980_941472134.1488399721170
Content-Type: text/plain; charset=UTF-8



On Wednesday, March 1, 2017 at 12:18:07 PM UTC-5, Giovanni Piero Deretta
wrote:
>
> On Wednesday, March 1, 2017 at 4:50:46 PM UTC, Nicol Bolas wrote:
>>
>>
>>
>> On Wednesday, March 1, 2017 at 10:48:40 AM UTC-5, Giovanni Piero Deretta
>> wrote:
>>>
>>> On Wednesday, March 1, 2017 at 3:38:13 PM UTC, Nicol Bolas wrote:
>>> [...]
>>>
>>>>
>>>> So we need the safe mechanism, and we need it shipped with the system.
>>>> But that should not be the *only* way; the lower-level form should
>>>> still exist.
>>>>
>>>> Now, maybe the type-safe version should be the *default*, so that if
>>>> you want the lower-level, unsafe API, we can clearly see that safety is
>>>> being sacrificed. So `callcc/continuation` would naturally be type-safe,
>>>> with `unsafe_callcc/unsafe_continuation` being not type safe.
>>>>
>>>
>>> we are in agreement then, I just want to point out that, given a type
>>> safe std::continuation<T> implementation, the unsafe variant would simply
>>> be std::continuation<void*>, while the dynamic variant would be
>>> continuation<std::any_ptr>, given a suitable implementation of any_ptr.
>>>
>>
>> I don't think you understood what I meant when I said "type safe". I
>> specifically *don't* mean that the continuation has a static and typed
>> set of parameters. What I mean is that getting the parameter back is
>> type-checked and therefore safe. But it's a *runtime* check, not a
>> compile-time check.
>>
>> This prevents compile-time tight coupling while still having safety on
>> the receiving end.
>>
>
> Hum, but this means that those that want statically check type safety (a
> very common use case, think generators), are left in the cold and need to
> roll their own continuation type on top of the unsafe one. I still don't
> see the need for a dynamically checked continuation type.
>
> For example, std::function is a vocabulary type designed for
> interoperability and decoupling, but it still check the signature a compile
> time. A runtime checked std::function is possible, but not desirable
> (incidentally Qt slot types used to be only dynamically checked and it was
> a pain). I don't see why continuation would be different (in fact there is
> a very strong affinity between continuations and functions).
>

Static checking between the parameters to `callcc` and the parameters to
the function being invoked is one thing. But static checking between the
parameters to `continuation::operator()` and to the receiving code is quite
something else. It is perfectly reasonable to initiate a `callcc` with one
set of parameters, but provide different parameters of different types at
continuation time.

Also, it's important to recognize that the function which began the
`callcc` operation may be doing generic boilerplate stuff: storing a
promise, building a channel, etc. Its return value will in many cases be
irrelevant. So it doesn't make sense to have `callcc` statically assume
that the return value of that function is meaningful to the caller.

The fundamental difference between `std::function` and a continuation is
that the former is intended to be a go-between and the latter is not. The
former is just a value type for storing and invoking any C++ callable.
`callcc` has nothing to do with that; it's creating new functionality. And
that new functionality has its own needs.

For example, guaranteed elision should still work through a `std::function`
call, for both parameters and return values. But there's no way to make it
work through a continuation; there has to be a copy/move of parameters into
the continuation's stack, and a copy/move of return values from the
continuation's stack.

So clearly, we're talking about two very different things here.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/aecc5a06-78cc-4071-8cce-b2e731439463%40isocpp.org.

------=_Part_1980_941472134.1488399721170
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Wednesday, March 1, 2017 at 12:18:07 PM UTC-5, =
Giovanni Piero Deretta wrote:<blockquote class=3D"gmail_quote" style=3D"mar=
gin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><=
div dir=3D"ltr">On Wednesday, March 1, 2017 at 4:50:46 PM UTC, Nicol Bolas =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br><br>On W=
ednesday, March 1, 2017 at 10:48:40 AM UTC-5, Giovanni Piero Deretta wrote:=
<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Wednesday, Marc=
h 1, 2017 at 3:38:13 PM UTC, Nicol Bolas wrote:<br>[...]<br><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc=
 solid;padding-left:1ex"><div dir=3D"ltr"><br><div>So we need the safe mech=
anism, and we need it shipped with the system. But that should not be the <=
i>only</i> way; the lower-level form should still exist.<br><br>Now, maybe =
the type-safe version should be the <i>default</i>, so that if you want the=
 lower-level, unsafe API, we can clearly see that safety is being sacrifice=
d. So `callcc/continuation` would naturally be type-safe, with `unsafe_call=
cc/unsafe_<wbr>continuation` being not type safe.<br></div></div></blockquo=
te><div><br>we are in agreement then, I just want to point out that, given =
a type safe std::continuation&lt;T&gt; implementation, the unsafe variant w=
ould simply be std::continuation&lt;void*&gt;, while the dynamic variant wo=
uld be continuation&lt;std::any_ptr&gt;, given a suitable implementation of=
 any_ptr.<br></div></div></blockquote><div><br>I don&#39;t think you unders=
tood what I meant when I said &quot;type safe&quot;. I specifically <i>don&=
#39;t</i> mean that the continuation has a static and typed set of paramete=
rs. What I mean is that getting the parameter back is type-checked and ther=
efore safe. But it&#39;s a <i>runtime</i> check, not a compile-time check.<=
br><br>This prevents compile-time tight coupling while still having safety =
on the receiving end.<br></div></div></blockquote><div><br>Hum, but this me=
ans that those that want statically check type safety (a very common use ca=
se, think generators), are left in the cold and need to roll their own cont=
inuation type on top of the unsafe one. I still don&#39;t see the need for =
a dynamically checked continuation type. <br><br>For example, std::function=
 is a vocabulary type designed for interoperability and decoupling, but it =
still check the signature a compile time. A runtime checked std::function i=
s possible, but not desirable (incidentally Qt slot types used to be only d=
ynamically checked and it was a pain). I don&#39;t see why continuation wou=
ld be different (in fact there is a very strong affinity between continuati=
ons and functions).</div></div></blockquote><div><br>Static checking betwee=
n the parameters to `callcc` and the parameters to the function being invok=
ed is one thing. But static checking between the parameters to `continuatio=
n::operator()` and to the receiving code is quite something else. It is per=
fectly reasonable to initiate a `callcc` with one set of parameters, but pr=
ovide different parameters of different types at continuation time.<br><br>=
Also, it&#39;s important to recognize that the function which began the `ca=
llcc` operation may be doing generic boilerplate stuff: storing a promise, =
building a channel, etc. Its return value will in many cases be irrelevant.=
 So it doesn&#39;t make sense to have `callcc` statically assume that the r=
eturn value of that function is meaningful to the caller.<br><br>The fundam=
ental difference between `std::function` and a continuation is that the for=
mer is intended to be a go-between and the latter is not. The former is jus=
t a value type for storing and invoking any C++ callable. `callcc` has noth=
ing to do with that; it&#39;s creating new functionality. And that new func=
tionality has its own needs.<br><br>For example, guaranteed elision should =
still work through a `std::function` call, for both parameters and return v=
alues. But there&#39;s no way to make it work through a continuation; there=
 has to be a copy/move of parameters into the continuation&#39;s stack, and=
 a copy/move of return values from the continuation&#39;s stack.<br><br>So =
clearly, we&#39;re talking about two very different things here.<br></div><=
/div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/aecc5a06-78cc-4071-8cce-b2e731439463%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/aecc5a06-78cc-4071-8cce-b2e731439463=
%40isocpp.org</a>.<br />

------=_Part_1980_941472134.1488399721170--

------=_Part_1979_805564204.1488399721170--

.

------=_Part_114_91318243.1488447810101
Content-Type: multipart/alternative;
 boundary="----=_Part_115_840712513.1488447810101"

------=_Part_115_840712513.1488447810101
Content-Type: text/plain; charset=UTF-8

Hi.

I do really like the general idea of callcc and continuation class. But I
don't understand the need of data transfer at this low abstraction level.
After all, these are not threads, so there is no asynchronism to think
about. To prove this point I implemented the classical generator pattern
without using continuation's data transfer possibilities (see attached
file). Sure enough, when the generator lambda calls yield(value) it stops
processing until the main program calls operator++ again. So all this time
the parameter to yield is valid on the generator's stack and available by
reference to the main program. So while there are obviously needs to send
data both ways for different patterns I fail to see why it must be a
feature of the lowest level abstraction.

When I wrote the code for generator.h I also saw that the pattern
`mContinuation = mContinuation()` seems to be mandatory. If you forget the
assignment you loose the ability to continue the next time. While there may
be cases where you want to assign the continuation returned from operator()
to some other std::continuation object, wouldn't it be more appropriate to
make simple things simple by letting operator() return void and
automatically update its `this` to the new state before returning and then
applications which really do need to move the continuation object elsewhere
can do so afterwards. Again there are no threading issues so it should be
safe. In the back of my head I think there is some exception safety issue
at play here, but if so it needs to be explained more clearly.

A comment on the invoke_on_top_t functionality. Why add a special tag type
just to be able to overload operator() to do another task when there is the
possibility to add a regular method:
std::continuation::invoke_on_top(args...). Also it would be interesting to
know when this rather strange functionality is useful.

An issue I stumbled upon during implementation was not being able to do
callcc() on a method. I think an overload of callcc specifically for method
pointers (in parallel with the std::function constructor set) will be
needed. This is as the std::continuation&& parameter gets prepended to the
args of callcc when calling the provided function. If the provided function
is a std::function wrapping a method pointer its operator() will expect to
get the 'this' of the object to call and instead it will get the
std::continuation prepended by callcc!

// Example:

class MyClass {
    void fun(std::continuation&& cont);
};

MyClass myObj;

callcc(&MyClass::fun, myObj);    // This is what you want to write, but
callcc does not take method pointers.

// So you may try this:

callcc(std::function<void(MyClass&, std::continuation&&)>(&MyClass::fun),
myObj);   // Mismatched types as callcc gets the order wrong.

// Instead you have to conjure up a lambda:

callcc([&](std::continuation&& cont) { myObj.fun(std::move(cont); });



While the lambda solution works I think it is quite weak not to allow the
first version.


--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/bc17b8b0-6e62-4e75-b271-7a744c57ea04%40isocpp.org.

------=_Part_115_840712513.1488447810101
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi.<div><br></div><div>I do really like the general idea o=
f callcc and continuation class. But I don&#39;t understand the need of dat=
a transfer at this low abstraction level. After all, these are not threads,=
 so there is no asynchronism to think about. To prove this point I implemen=
ted the classical generator pattern without using continuation&#39;s data t=
ransfer possibilities (see attached file). Sure enough, when the generator =
lambda calls yield(value) it stops processing until the main program calls =
operator++ again. So all this time the parameter to yield is valid on the g=
enerator&#39;s stack and available by reference to the main program. So whi=
le there are obviously needs to send data both ways for different patterns =
I fail to see why it must be a feature of the lowest level abstraction.</di=
v><div><br></div><div>When I wrote the code for generator.h I also saw that=
 the pattern `mContinuation =3D mContinuation()` seems to be mandatory. If =
you forget the assignment you loose the ability to continue the next time. =
While there may be cases where you want to assign the continuation returned=
 from operator() to some other std::continuation object, wouldn&#39;t it be=
 more appropriate to make simple things simple by letting operator() return=
 void and automatically update its `this` to the new state before returning=
 and then applications which really do need to move the continuation object=
 elsewhere can do so afterwards. Again there are no threading issues so it =
should be safe. In the back of my head I think there is some exception safe=
ty issue at play here, but if so it needs to be explained more clearly.</di=
v><div><br></div><div>A comment on the invoke_on_top_t functionality. Why a=
dd a special tag type just to be able to overload operator() to do another =
task when there is the possibility to add a regular method: std::continuati=
on::invoke_on_top(args...). Also it would be interesting to know when this =
rather strange functionality is useful.</div><div><br></div><div>An issue I=
 stumbled upon during implementation was not being able to do callcc() on a=
 method. I think an overload of callcc specifically for method pointers (in=
 parallel with the std::function constructor set) will be needed. This is a=
s the std::continuation&amp;&amp; parameter gets prepended to the args of c=
allcc when calling the provided function. If the provided function is a std=
::function wrapping a method pointer its operator() will expect to get the =
&#39;this&#39; of the object to call and instead it will get the std::conti=
nuation prepended by callcc!</div><div><br></div><blockquote style=3D"margi=
n: 0 0 0 40px; border: none; padding: 0px;"><div>// Example:</div><div><br>=
</div><div>class MyClass {</div><div>=C2=A0 =C2=A0 void fun(std::continuati=
on&amp;&amp; cont);</div><div>};</div><div><br></div><div>MyClass myObj;</d=
iv><div><br></div><div>callcc(&amp;MyClass::fun, myObj); =C2=A0 =C2=A0// Th=
is is what you want to write, but callcc does not take method pointers.</di=
v><div><br></div><div>// So you may try this:</div><div><br></div><div>call=
cc(std::function&lt;void(MyClass&amp;, std::continuation&amp;&amp;)&gt;(&am=
p;MyClass::fun), myObj); =C2=A0 // Mismatched types as callcc gets the orde=
r wrong.</div><div><br></div><div>// Instead you have to conjure up a lambd=
a:</div><div><br></div><div>callcc([&amp;](std::continuation&amp;&amp; cont=
) { myObj.fun(std::move(cont); });</div></blockquote><div><br></div><div><b=
r></div><div>While the lambda solution works I think it is quite weak not t=
o allow the first version.</div><div><br></div><div><br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/bc17b8b0-6e62-4e75-b271-7a744c57ea04%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/bc17b8b0-6e62-4e75-b271-7a744c57ea04=
%40isocpp.org</a>.<br />

------=_Part_115_840712513.1488447810101--

------=_Part_114_91318243.1488447810101
Content-Type: text/x-chdr; charset=US-ASCII; name=generator.h
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename=generator.h
X-Attachment-Id: b2042efd-c8b8-4733-8c81-329923d11939
Content-ID: <b2042efd-c8b8-4733-8c81-329923d11939>




#include <fstream>
#include <functional>

// Stubs
namespace std {
class continuation {
public:
 continuation operator()() { return *this; }  // Fake!
 bool operator!=(const continuation& rhs) const { return false; }
};

template<typename F, typename... Args> continuation callcc(F&& fn, Args&&... args)
{
 return continuation();  // Fake!
}
}

// Yielder is a helper object that gets passed to the function parameter of Generator constructor
template<typename T> class Yielder {
public:
 void operator()(T& value) {
  mValue = &value;
  mContinuation = mContinuation();  // Transfer control to main program
 }

 void SetContinuation(std::continuation&& cont) { mContinuation = std::move(cont); }

 T& GetValue() { return *mValue; }
private:
 T *mValue;
 std::continuation mContinuation;   // This is the context of the main program
};


// A generator is the object you create a temporary instance of in the for loop head.
template<typename T> class Generator {
public:
 class iterator {
 public:
  iterator() = default;   // Sets mContinuation in a disengaged state.
  iterator(const std::function<void(Yielder<T>&)>& func) {
   mContinuation = callcc([](std::continuation&& cont, const std::function<void(Yielder<T>&)>& func, Yielder<T>& yielder) {
         yielder.SetContinuation(std::move(cont));
         func(yielder);
        }, func, mYielder);
  }

  T& operator*() {
   return mYielder.GetValue();
  }
  void operator++() {
   mContinuation = mContinuation();  // Transfer control to generator lambda. If lambda returns instead of yields sets mContinuation unengaged.
  }

  bool operator==(const iterator& rhs) const { return mContinuation == rhs.mContinuation; } // Returns true only when generator lambda has returned
  bool operator!=(const iterator& rhs) const { return mContinuation != rhs.mContinuation; } // Returns true only when generator lambda has returned

 private:
  Yielder<T> mYielder;
  std::continuation mContinuation;   // This is the context of the generator lambda
 };

 Generator(const std::function<void(Yielder<T>&)>& func) : mFunction(func) {}
 Generator(std::function<void(Yielder<T>&)>&& func) : mFunction(std::move(func)) {}

 iterator begin() { return iterator(mFunction); }
 iterator end() { return iterator(); }

private:
 std::function<void(Yielder<T>&)> mFunction;
};


void test()
{
 for (int i : Generator<int>([](Yielder<int>& yield) {
  int a = 0;
  int b = 0;
  while (a < 10000) {
   yield(a);
   b = a;
   a = b + a;
  }
 }))
  std::cout << i << std::endl;
}


------=_Part_114_91318243.1488447810101--

.

------=_Part_153_1034785371.1488449467845
Content-Type: multipart/alternative;
 boundary="----=_Part_154_2084467805.1488449467845"

------=_Part_154_2084467805.1488449467845
Content-Type: text/plain; charset=UTF-8

On Thursday, March 2, 2017 at 9:43:30 AM UTC, Bengt Gustafsson wrote:
>
> Hi.
>
> I do really like the general idea of callcc and continuation class. But I
> don't understand the need of data transfer at this low abstraction level.
>

You can of course arrange to have both sides of the continuation share a
memory location, but it is cumbersome (especially when the two sides can
switch freely like with symmetric coroutines) and potentially inefficient
(The parameter passing can be made literally free in the low level
assembler switching function by simply not saving and restoring a specific
register). The implementation will need to pass parameters through anyway
(to implement execute_on_top or exception transport, so it makes sense to
expose the functionality to the user. Although I would prefer the
functionality to be properly typed, I would settle for a single void*
parameter as typing can be implemented on top of it with no cost.



> After all, these are not threads, so there is no asynchronism to think
> about. To prove this point I implemented the classical generator pattern
> without using continuation's data transfer possibilities (see attached
> file). Sure enough, when the generator lambda calls yield(value) it stops
> processing until the main program calls operator++ again. So all this time
> the parameter to yield is valid on the generator's stack and available by
> reference to the main program. So while there are obviously needs to send
> data both ways for different patterns I fail to see why it must be a
> feature of the lowest level abstraction.
>

well, yes the functionality is normally implemented by simply passing to
the next continuation a pointer to the parameter on the stack.


>
> When I wrote the code for generator.h I also saw that the pattern
> `mContinuation = mContinuation()` seems to be mandatory. If you forget the
> assignment you loose the ability to continue the next time. While there may
> be cases where you want to assign the continuation returned from operator()
> to some other std::continuation object, wouldn't it be more appropriate to
> make simple things simple by letting operator() return void and
> automatically update its `this` to the new state before returning and then
> applications which really do need to move the continuation object elsewhere
> can do so afterwards. Again there are no threading issues so it should be
> safe. In the back of my head I think there is some exception safety issue
> at play here, but if so it needs to be explained more clearly.
>

My own implementation updates this, but I don't have a strong opinion, and
the explicit assignment makes it more obvious that the new continuation has
potentially no relation to the one just consumed.


>
> A comment on the invoke_on_top_t functionality. Why add a special tag type
> just to be able to overload operator() to do another task when there is the
> possibility to add a regular method:
> std::continuation::invoke_on_top(args...).
>

A possibility is dropping operator() and using callcc for everything. The
full callcc signature woud be like this:

   callcc(cont, fn, arg)

Which is the same as cont(invoke_on_top, fn, args)

A new continuation can be created with:

  callcc(make_empty_continuation(), fn, arg)

(where make_empty_continuation just creates a continuation that will exit
immediately upon invocation)
Switching is just:

  callcc(cont, identity, arg);

This closely mimics callcc behaviour in other languages. In fact
make_empty_continuation() and callcc are really the only two primitives you
need.

Of course overloads and default parameters would make use of the library
more straightforward (and, in the case of context switching, more
efficient).

Also it would be interesting to know when this rather strange functionality
> is useful.
>

The functionality is actually not strange at all if you think of the
underlying CPS transformation, and it simplifies the implementation of
continuation itself, as it can be directly used to implement continuation
creation (just invoke on top of an empty continuation), exit (invoke on top
of next and cleanup source), exception throwing (invoke on top then throw).
It also greatly simplifies more complex uses of continuation (handy to
implement scheduling, waiting, etc).


> An issue I stumbled upon during implementation was not being able to do
> callcc() on a method. I think an overload of callcc specifically for method
> pointers (in parallel with the std::function constructor set) will be
> needed. This is as the std::continuation&& parameter gets prepended to the
> args of callcc when calling the provided function. If the provided function
> is a std::function wrapping a method pointer its operator() will expect to
> get the 'this' of the object to call and instead it will get the
> std::continuation prepended by callcc!
>
> // Example:
>
> class MyClass {
>     void fun(std::continuation&& cont);
> };
>
> MyClass myObj;
>
> callcc(&MyClass::fun, myObj);    // This is what you want to write, but
> callcc does not take method pointers.
>
> // So you may try this:
>
> callcc(std::function<void(MyClass&, std::continuation&&)>(&MyClass::fun),
> myObj);   // Mismatched types as callcc gets the order wrong.
>
> // Instead you have to conjure up a lambda:
>
> callcc([&](std::continuation&& cont) { myObj.fun(std::move(cont); });
>
>
>
> While the lambda solution works I think it is quite weak not to allow the
> first version.
>
> I think a fully fledged implementation would have full INVOKE like
semantics, but as it is very straightforward, probably implementing the
feature is not very high in Oliver's priorities.


--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/a3cae110-2522-4364-9354-d9d87037b012%40isocpp.org.

------=_Part_154_2084467805.1488449467845
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Thursday, March 2, 2017 at 9:43:30 AM UTC, Bengt Gustaf=
sson wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left=
: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">Hi=
..<div><br></div><div>I do really like the general idea of callcc and contin=
uation class. But I don&#39;t understand the need of data transfer at this =
low abstraction level.</div></div></blockquote><div><br>You can of course a=
rrange to have both sides of the continuation share a memory location, but =
it is cumbersome (especially when the two sides can switch freely like with=
 symmetric coroutines) and potentially inefficient (The parameter passing c=
an be made literally free in the low level assembler switching function by =
simply not saving and restoring a specific register). The implementation wi=
ll need to pass parameters through anyway (to implement execute_on_top or e=
xception transport, so it makes sense to expose the functionality to the us=
er. Although I would prefer the functionality to be properly typed, I would=
 settle for a single void* parameter as typing can be implemented on top of=
 it with no cost.<br><br>=C2=A0</div><blockquote class=3D"gmail_quote" styl=
e=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left:=
 1ex;"><div dir=3D"ltr"><div> After all, these are not threads, so there is=
 no asynchronism to think about. To prove this point I implemented the clas=
sical generator pattern without using continuation&#39;s data transfer poss=
ibilities (see attached file). Sure enough, when the generator lambda calls=
 yield(value) it stops processing until the main program calls operator++ a=
gain. So all this time the parameter to yield is valid on the generator&#39=
;s stack and available by reference to the main program. So while there are=
 obviously needs to send data both ways for different patterns I fail to se=
e why it must be a feature of the lowest level abstraction.</div></div></bl=
ockquote><div><br>well, yes the functionality is normally implemented by si=
mply passing to the next continuation a pointer to the parameter on the sta=
ck.<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D=
"ltr"><div><br></div><div>When I wrote the code for generator.h I also saw =
that the pattern `mContinuation =3D mContinuation()` seems to be mandatory.=
 If you forget the assignment you loose the ability to continue the next ti=
me. While there may be cases where you want to assign the continuation retu=
rned from operator() to some other std::continuation object, wouldn&#39;t i=
t be more appropriate to make simple things simple by letting operator() re=
turn void and automatically update its `this` to the new state before retur=
ning and then applications which really do need to move the continuation ob=
ject elsewhere can do so afterwards. Again there are no threading issues so=
 it should be safe. In the back of my head I think there is some exception =
safety issue at play here, but if so it needs to be explained more clearly.=
</div></div></blockquote><div><br>My own implementation updates this, but I=
 don&#39;t have a strong opinion, and the explicit assignment makes it more=
 obvious that the new continuation has potentially no relation to the one j=
ust consumed.<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"mar=
gin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><=
div dir=3D"ltr"><div><br></div><div>A comment on the invoke_on_top_t functi=
onality. Why add a special tag type just to be able to overload operator() =
to do another task when there is the possibility to add a regular method: s=
td::continuation::invoke_on_<wbr>top(args...). </div></div></blockquote><di=
v><br>A possibility is dropping operator() and using callcc for everything.=
 The full callcc signature woud be like this:<br><br>=C2=A0=C2=A0 callcc(co=
nt, fn, arg)<br><br>Which is the same as cont(invoke_on_top, fn, args) <br>=
<br>A new continuation can be created with:<br><br>=C2=A0 callcc(make_empty=
_continuation(), fn, arg)<br><br>(where make_empty_continuation just create=
s a continuation that will exit immediately upon invocation)<br>Switching i=
s just:<br><br>=C2=A0 callcc(cont, identity, arg);<br><br>This closely mimi=
cs callcc behaviour in other languages. In fact make_empty_continuation() a=
nd callcc are really the only two primitives you need.<br><br>Of course ove=
rloads and default parameters would make use of the library more straightfo=
rward (and, in the case of context switching, more efficient).<br><br></div=
><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bo=
rder-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>Also it=
 would be interesting to know when this rather strange functionality is use=
ful.</div></div></blockquote><div><br>The functionality is actually not str=
ange at all if you think of the underlying CPS transformation, and it simpl=
ifies the implementation of continuation itself, as it can be directly used=
 to implement continuation creation (just invoke on top of an empty continu=
ation), exit (invoke on top of next and cleanup source), exception throwing=
 (invoke on top then throw). It also greatly simplifies more complex uses o=
f continuation (handy to implement scheduling, waiting, etc).<br>=C2=A0</di=
v><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;b=
order-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div></div>=
<div>An issue I stumbled upon during implementation was not being able to d=
o callcc() on a method. I think an overload of callcc specifically for meth=
od pointers (in parallel with the std::function constructor set) will be ne=
eded. This is as the std::continuation&amp;&amp; parameter gets prepended t=
o the args of callcc when calling the provided function. If the provided fu=
nction is a std::function wrapping a method pointer its operator() will exp=
ect to get the &#39;this&#39; of the object to call and instead it will get=
 the std::continuation prepended by callcc!</div><div><br></div><blockquote=
 style=3D"margin:0 0 0 40px;border:none;padding:0px"><div>// Example:</div>=
<div><br></div><div>class MyClass {</div><div>=C2=A0 =C2=A0 void fun(std::c=
ontinuation&amp;&amp; cont);</div><div>};</div><div><br></div><div>MyClass =
myObj;</div><div><br></div><div>callcc(&amp;MyClass::fun, myObj); =C2=A0 =
=C2=A0// This is what you want to write, but callcc does not take method po=
inters.</div><div><br></div><div>// So you may try this:</div><div><br></di=
v><div>callcc(std::function&lt;void(<wbr>MyClass&amp;, std::continuation&am=
p;&amp;)&gt;(&amp;<wbr>MyClass::fun), myObj); =C2=A0 // Mismatched types as=
 callcc gets the order wrong.</div><div><br></div><div>// Instead you have =
to conjure up a lambda:</div><div><br></div><div>callcc([&amp;](std::contin=
uation&amp;&amp; cont) { myObj.fun(std::move(cont); });</div></blockquote><=
div><br></div><div><br></div><div>While the lambda solution works I think i=
t is quite weak not to allow the first version.</div><div><br></div></div><=
/blockquote><div>I think a fully fledged implementation would have full INV=
OKE like semantics, but as it is very straightforward, probably implementin=
g the feature is not very high in Oliver&#39;s priorities.<br>=C2=A0</div><=
/div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/a3cae110-2522-4364-9354-d9d87037b012%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a3cae110-2522-4364-9354-d9d87037b012=
%40isocpp.org</a>.<br />

------=_Part_154_2084467805.1488449467845--

------=_Part_153_1034785371.1488449467845--

.

------=_Part_167_1370632866.1488451963542
Content-Type: multipart/alternative;
 boundary="----=_Part_168_825494097.1488451963542"

------=_Part_168_825494097.1488451963542
Content-Type: text/plain; charset=UTF-8

On Wednesday, March 1, 2017 at 8:22:01 PM UTC, Nicol Bolas wrote:
>
> [...]
>


> Static checking between the parameters to `callcc` and the parameters to
> the function being invoked is one thing. But static checking between the
> parameters to `continuation::operator()` and to the receiving code is quite
> something else. It is perfectly reasonable to initiate a `callcc` with one
> set of parameters, but provide different parameters of different types at
> continuation time.
>
>

> Also, it's important to recognize that the function which began the
> `callcc` operation may be doing generic boilerplate stuff: storing a
> promise, building a channel, etc. Its return value will in many cases be
> irrelevant. So it doesn't make sense to have `callcc` statically assume
> that the return value of that function is meaningful to the caller.
>

You are taking my parallel to std::funciton too literally.  There is no
expectation that the parameters passed to the function object on context
creation to match the continuation return and receive type (and the
function object must always return a continuation, so there is no freedom
there). My request is that the continuation encodes the types of the
parameter passed through and received from and enforce it statically, the
same way that std::function enforces them.


>
> The fundamental difference between `std::function` and a continuation is
> that the former is intended to be a go-between and the latter is not.
>

It very much is. it is a communication channel between two arbitrary thread
of executions. In fact delimited continuations [1] are really
indistinguishable from functions from the outside, but that's beside the
point.


> The former is just a value type for storing and invoking any C++ callable.
> `callcc` has nothing to do with that; it's creating new functionality. And
> that new functionality has its own needs.
>
> For example, guaranteed elision should still work through a
> `std::function` call, for both parameters and return values. But there's no
> way to make it work through a continuation; there has to be a copy/move of
> parameters into the continuation's stack, and a copy/move of return values
> from the continuation's stack.
>

Apart from the fact that cross coroutine parameter copy elision is very
much feasible with compiler help, you are taking the parallel too literally.

[1] contrary to what P0534 claims, it describes delimited continuations;
I'm not even sure you can have undelimited continuations when you have
one-shot semantics.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/f67a3b9d-3fec-40c5-95a2-576acf88b6f9%40isocpp.org.

------=_Part_168_825494097.1488451963542
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Wednesday, March 1, 2017 at 8:22:01 PM UTC, Nicol Bolas=
 wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.=
8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">[...]<=
/div></blockquote><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;"><div>Static checking between the parameters to `callcc` and the param=
eters to the function being invoked is one thing. But static checking betwe=
en the parameters to `continuation::operator()` and to the receiving code i=
s quite something else. It is perfectly reasonable to initiate a `callcc` w=
ith one set of parameters, but provide different parameters of different ty=
pes at continuation time.<br>=C2=A0</div></blockquote><blockquote class=3D"=
gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc so=
lid;padding-left: 1ex;"><div dir=3D"ltr"><div><br>Also, it&#39;s important =
to recognize that the function which began the `callcc` operation may be do=
ing generic boilerplate stuff: storing a promise, building a channel, etc. =
Its return value will in many cases be irrelevant. So it doesn&#39;t make s=
ense to have `callcc` statically assume that the return value of that funct=
ion is meaningful to the caller.<br></div></div></blockquote><div><br>You a=
re taking my parallel to std::funciton too literally.=C2=A0 There is no exp=
ectation that the parameters passed to the function object on context creat=
ion to match the continuation return and receive type (and the function obj=
ect must always return a continuation, so there is no freedom there). My re=
quest is that the continuation encodes the types of the parameter passed th=
rough and received from and enforce it statically, the same way that std::f=
unction enforces them.<br>=C2=A0</div><blockquote class=3D"gmail_quote" sty=
le=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left=
: 1ex;"><div dir=3D"ltr"><div><br>The fundamental difference between `std::=
function` and a continuation is that the former is intended to be a go-betw=
een and the latter is not. </div></div></blockquote><div><br>It very much i=
s. it is a communication channel between two arbitrary thread of executions=
.. In fact delimited continuations [1] are really indistinguishable from fun=
ctions from the outside, but that&#39;s beside the point.<br>=C2=A0</div><b=
lockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;borde=
r-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>The former=
 is just a value type for storing and invoking any C++ callable. `callcc` h=
as nothing to do with that; it&#39;s creating new functionality. And that n=
ew functionality has its own needs.<br><br>For example, guaranteed elision =
should still work through a `std::function` call, for both parameters and r=
eturn values. But there&#39;s no way to make it work through a continuation=
; there has to be a copy/move of parameters into the continuation&#39;s sta=
ck, and a copy/move of return values from the continuation&#39;s stack.<br>=
</div></div></blockquote><div><br>Apart from the fact that cross coroutine =
parameter copy elision is very much feasible with compiler help, you are ta=
king the parallel too literally.<br></div><div><br>[1] contrary to what P05=
34 claims, it describes delimited continuations; I&#39;m not even sure you =
can have undelimited continuations when you have one-shot semantics.<br></d=
iv></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/f67a3b9d-3fec-40c5-95a2-576acf88b6f9%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/f67a3b9d-3fec-40c5-95a2-576acf88b6f9=
%40isocpp.org</a>.<br />

------=_Part_168_825494097.1488451963542--

------=_Part_167_1370632866.1488451963542--

.

--001a114f1076976be90549bd77db
Content-Type: text/plain; charset=UTF-8

2017-03-02 11:52 GMT+01:00 Giovanni Piero Deretta <gpderetta@gmail.com>:

>
> [1] contrary to what P0534 claims, it describes delimited continuations;
> I'm not even sure you can have undelimited continuations when you have
> one-shot semantics.
>

undelimited continuations == no delimiter that tells you where the
continuatio nends, e.g. if you call callcc() from main(), it is undelimited

int main() {
   ....
   callcc(); // reifies continuation
   ... // all the code behind callcc() belong s to the reified continuation
}


delimited continuations == you doe definie in the code till which point the
reified continuation goes (reset-op),

int main() {
    ...
     reset { // delimites the continuation
         shift {...}   / reifies the continuation
     }  // continuation ends here
   ... // code here does not belong to the reified continuation
}

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2Bwfc1-fGEOGVP6--YexgjWgkZy6h1-o3QmK0a6SLnSChfeq%2Bg%40mail.gmail.com.

--001a114f1076976be90549bd77db
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">2017=
-03-02 11:52 GMT+01:00 Giovanni Piero Deretta <span dir=3D"ltr">&lt;<a href=
=3D"mailto:gpderetta@gmail.com" target=3D"_blank">gpderetta@gmail.com</a>&g=
t;</span>:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span class=
=3D""></span><div><br>[1] contrary to what P0534 claims, it describes delim=
ited continuations; I&#39;m not even sure you can have undelimited continua=
tions when you have one-shot semantics.<br></div></div></blockquote></div><=
br></div><div class=3D"gmail_extra">undelimited continuations =3D=3D no del=
imiter that tells you where the continuatio nends, e.g. if you call callcc(=
) from main(), it is undelimited <br><br></div><div class=3D"gmail_extra">i=
nt main() {<br>=C2=A0=C2=A0 ....<br></div><div class=3D"gmail_extra">=C2=A0=
=C2=A0 callcc(); // reifies continuation<br></div><div class=3D"gmail_extra=
">=C2=A0=C2=A0 ... // all the code behind callcc() belong s to the reified =
continuation<br></div><div class=3D"gmail_extra">}<br></div><div class=3D"g=
mail_extra"><br><br></div><div class=3D"gmail_extra">delimited continuation=
s =3D=3D you doe definie in the code till which point the reified continuat=
ion goes (reset-op),<br><br></div><div class=3D"gmail_extra">int main() {<b=
r>=C2=A0=C2=A0=C2=A0 ...<br></div><div class=3D"gmail_extra">=C2=A0=C2=A0=
=C2=A0=C2=A0 reset { // delimites the continuation<br></div><div class=3D"g=
mail_extra">=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 shift {...}=C2=
=A0=C2=A0 / reifies the continuation<br></div><div class=3D"gmail_extra">=
=C2=A0=C2=A0=C2=A0=C2=A0 }=C2=A0 // continuation ends here<br></div><div cl=
ass=3D"gmail_extra">=C2=A0=C2=A0 ... // code here does not belong to the re=
ified continuation<br>}<br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CA%2Bwfc1-fGEOGVP6--YexgjWgkZy6h1-o3Q=
mK0a6SLnSChfeq%2Bg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2Bwfc1-fGE=
OGVP6--YexgjWgkZy6h1-o3QmK0a6SLnSChfeq%2Bg%40mail.gmail.com</a>.<br />

--001a114f1076976be90549bd77db--

.

------=_Part_118_329297088.1488454174790
Content-Type: multipart/alternative;
 boundary="----=_Part_119_1951193406.1488454174790"

------=_Part_119_1951193406.1488454174790
Content-Type: text/plain; charset=UTF-8

On Thursday, March 2, 2017 at 11:09:49 AM UTC, Oliver Kowalke wrote:
>
> 2017-03-02 11:52 GMT+01:00 Giovanni Piero Deretta <gpde...@gmail.com
> <javascript:>>:
>
>>
>> [1] contrary to what P0534 claims, it describes delimited continuations;
>> I'm not even sure you can have undelimited continuations when you have
>> one-shot semantics.
>>
>
> undelimited continuations == no delimiter that tells you where the
> continuatio nends, e.g. if you call callcc() from main(), it is undelimited
>

there are a whole family of delimited continuations semantics each with
slightly different delimiter/invoker semantics. shift/reset is just one of
them.

With undelimted continuation you can return from call/cc and fall back in
the original continuation, while still holding the captured continuation,
allowing returning 'twice'. This is of course not possible with oneshot
continuation, and callcc (and yield), in a way, do inserts a prompt. Now,
if I understand correctly, with shift/reset, shift finds the closest
dynamically scoped reset in the callstack, while with callcc and yield,
there is not a clear distinction between the prompt and the shift point as
they are both continuations and they are statically scoped (on the other
hand, asymmetric coroutines with an explicit thread local parent pointer
more closely match shift/reset model).

Regarding main, the continuation is implicitly delimited as you can't fall
further than that and return to the os instead. Oleg Kiselyov (which has
done a lot of work on the topic) in fact claims that undelimited
continuations do not really exist, as a delimiter always exists, it might
just be outside of the programmer control.

Anyway, I don't pretend to understand fully the formal semantics of
continuations, so I might be mistaken. It doesn't really matter that much
for us C++ programmers though .

-- gpd

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/5d94e416-e8bf-41e1-98f3-eee6133c9b64%40isocpp.org.

------=_Part_119_1951193406.1488454174790
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Thursday, March 2, 2017 at 11:09:49 AM UTC, Oliver Kowa=
lke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><di=
v><div class=3D"gmail_quote">2017-03-02 11:52 GMT+01:00 Giovanni Piero Dere=
tta <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obf=
uscated-mailto=3D"uiMMo53zCQAJ" rel=3D"nofollow" onmousedown=3D"this.href=
=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascri=
pt:&#39;;return true;">gpde...@gmail.com</a>&gt;</span>:<br><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa=
dding-left:1ex"><div dir=3D"ltr"><span></span><div><br>[1] contrary to what=
 P0534 claims, it describes delimited continuations; I&#39;m not even sure =
you can have undelimited continuations when you have one-shot semantics.<br=
></div></div></blockquote></div><br></div><div>undelimited continuations =
=3D=3D no delimiter that tells you where the continuatio nends, e.g. if you=
 call callcc() from main(), it is undelimited <br></div></div></blockquote>=
<div><br>there are a whole family of delimited continuations semantics each=
 with slightly different delimiter/invoker semantics. shift/reset is just o=
ne of them. <br><br>With undelimted continuation you can return from call/c=
c and fall back in the original continuation, while still holding the captu=
red continuation, allowing returning &#39;twice&#39;. This is of course not=
 possible with oneshot continuation, and callcc (and yield), in a way, do i=
nserts a prompt. Now, if I understand correctly, with shift/reset, shift fi=
nds the closest dynamically scoped reset in the callstack, while with callc=
c and yield, there is not a clear distinction between the prompt and the sh=
ift point as they are both continuations and they are statically scoped (on=
 the other hand, asymmetric coroutines with an explicit thread local parent=
 pointer more closely match shift/reset model).<br><br>Regarding main, the =
continuation is implicitly delimited as you can&#39;t fall further than tha=
t and return to the os instead. Oleg Kiselyov (which has done a lot of work=
 on the topic) in fact claims that undelimited continuations do not really =
exist, as a delimiter always exists, it might just be outside of the progra=
mmer control.<br><br>Anyway, I don&#39;t pretend to understand fully the fo=
rmal semantics of continuations, so I might be mistaken. It doesn&#39;t rea=
lly matter that much for us C++ programmers though . <br></div><br>-- gpd<b=
r></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/5d94e416-e8bf-41e1-98f3-eee6133c9b64%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5d94e416-e8bf-41e1-98f3-eee6133c9b64=
%40isocpp.org</a>.<br />

------=_Part_119_1951193406.1488454174790--

------=_Part_118_329297088.1488454174790--

.

------=_Part_121_739072570.1488454277674
Content-Type: multipart/alternative;
 boundary="----=_Part_122_1086015268.1488454277674"

------=_Part_122_1086015268.1488454277674
Content-Type: text/plain; charset=UTF-8

On Thursday, March 2, 2017 at 11:29:35 AM UTC, Giovanni Piero Deretta wrote:
[...]

> Now, if I understand correctly, with shift/reset, shift finds the closest
> dynamically scoped reset in the callstack, while with callcc and yield,
> there is not a clear distinction between the prompt and the shift point as
> they are both continuations and they are statically scoped (on the other
> hand, asymmetric coroutines with an explicit thread local parent pointer
> more closely match shift/reset model).
>

I meant lexically scoped, not statically scoped here, of course.

-- gpd

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/8095abf1-1b94-4dd6-b1b4-ea2606859d8c%40isocpp.org.

------=_Part_122_1086015268.1488454277674
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Thursday, March 2, 2017 at 11:29:35 AM UTC, Giovanni Pi=
ero Deretta wrote:<br>[...]<br><blockquote class=3D"gmail_quote" style=3D"m=
argin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"=
><div dir=3D"ltr">Now, if I understand correctly, with shift/reset, shift f=
inds the closest dynamically scoped reset in the callstack, while with call=
cc and yield, there is not a clear distinction between the prompt and the s=
hift point as they are both continuations and they are statically scoped (o=
n the other hand, asymmetric coroutines with an explicit thread local paren=
t pointer more closely match shift/reset model).<br></div></blockquote><div=
><br>I meant lexically scoped, not statically scoped here, of course.</div>=
<br>-- gpd<br></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/8095abf1-1b94-4dd6-b1b4-ea2606859d8c%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/8095abf1-1b94-4dd6-b1b4-ea2606859d8c=
%40isocpp.org</a>.<br />

------=_Part_122_1086015268.1488454277674--

------=_Part_121_739072570.1488454277674--

.

--f403045e61fcca0a1c0549be96cd
Content-Type: text/plain; charset=UTF-8

2017-03-02 10:43 GMT+01:00 Bengt Gustafsson <bengt.gustafsson@beamways.com>:

> But I don't understand the need of data transfer at this low abstraction
> level. After all, these are not threads, so there is no asynchronism to
> think about.
>

P0534 is symmetric context switching, e.g. no coupling between caller and
callee as it is for generators/coroutines



> When I wrote the code for generator.h I also saw that the pattern
> `mContinuation = mContinuation()` seems to be mandatory. If you forget the
> assignment you loose the ability to continue the next time. While there may
> be cases where you want to assign the continuation returned from operator()
> to some other std::continuation object, wouldn't it be more appropriate to
> make simple things simple by letting operator() return void and
> automatically update its `this` to the new state before returning and then
> applications which really do need to move the continuation object elsewhere
> can do so afterwards.
>

I've had several variations of callcc() implemented and I got into troubles
during the implementation of fibers (lightweight threads) using such a kind
of call/cc.
I would not consider to change the identity of a continuation while
invoking its operator() a good idea - you don't know to which context your
continuation points to (e.g. what it executes/does) after returning from
continuation::operator().



> A comment on the invoke_on_top_t functionality. Why add a special tag type
> just to be able to overload operator() to do another task when there is the
> possibility to add a regular method: std::continuation::invoke_on_
> top(args...).
>

both is possible : because apply-operator does the context switch I'd like
to use the same operator to do the context switch + invoking an function on
the resumed context



> Also it would be interesting to know when this rather strange
> functionality is useful.
>

described in P0534:
you can invoke a new function after resuming the context that throws an
exception
for instance you want abort and unwind the stack - instead to check for
abort each time the context is resumed you call invoke-ontop functionality
to execute the throwing abort function only at the time point you know you
want to abort the continuation/context



> An issue I stumbled upon during implementation was not being able to do
> callcc() on a method. I think an overload of callcc specifically for method
> pointers (in parallel with the std::function constructor set) will be
> needed. This is as the std::continuation&& parameter gets prepended to the
> args of callcc when calling the provided function. If the provided function
> is a std::function wrapping a method pointer its operator() will expect to
> get the 'this' of the object to call and instead it will get the
> std::continuation prepended by callcc!
>
> // Example:
>
> class MyClass {
>     void fun(std::continuation&& cont);
> };
>
> MyClass myObj;
>
> callcc(&MyClass::fun, myObj);    // This is what you want to write, but
> callcc does not take method pointers.
>
> // So you may try this:
>
> callcc(std::function<void(MyClass&, std::continuation&&)>(&MyClass::fun),
> myObj);   // Mismatched types as callcc gets the order wrong.
>
> // Instead you have to conjure up a lambda:
>
> callcc([&](std::continuation&& cont) { myObj.fun(std::move(cont); });
>
>
>
> While the lambda solution works I think it is quite weak not to allow the
> first version.
>

I'm too busy - so it didn't got the highest prio/keep in mind I do it at my
freetime

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2Bwfc1-Pd3iR%2BxBeqDc4AZ_BpPFJRJw5grusofJaY8UuUnvEcA%40mail.gmail.com.

--f403045e61fcca0a1c0549be96cd
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">2017=
-03-02 10:43 GMT+01:00 Bengt <span tabindex=3D"-1" id=3D":33s.1" style=3D""=
 class=3D"">Gustafsson</span> <span dir=3D"ltr">&lt;<a target=3D"_blank" hr=
ef=3D"mailto:bengt.gustafsson@beamways.com"><span tabindex=3D"-1" id=3D":33=
s.2" style=3D"" class=3D"">bengt</span>.<span tabindex=3D"-1" id=3D":33s.3"=
 style=3D"" class=3D"">gustafsson</span>@<span tabindex=3D"-1" id=3D":33s.4=
" style=3D"" class=3D"">beamways</span>.com</a>&gt;</span>:<br><blockquote =
style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pa=
dding-left:1ex" class=3D"gmail_quote"><div dir=3D"ltr">But I don&#39;t unde=
rstand the need of data transfer at this low abstraction level. After all, =
these are not threads, so there is no asynchronism to think about. <br></di=
v></blockquote><div><br></div><div>P0534 is symmetric context switching, e.=
g. no coupling between caller and <span tabindex=3D"-1" id=3D":33s.6" style=
=3D"" class=3D"">callee</span> as it is for generators/<span tabindex=3D"-1=
" id=3D":33s.7" style=3D"" class=3D"">coroutines</span><br></div><div><br>=
=C2=A0</div><blockquote style=3D"margin:0px 0px 0px 0.8ex;border-left:1px s=
olid rgb(204,204,204);padding-left:1ex" class=3D"gmail_quote"><div dir=3D"l=
tr"><div>When I wrote the code for generator.h I also saw that the pattern =
`mContinuation =3D mContinuation()` seems to be mandatory. If you forget th=
e assignment you loose the ability to continue the next time. While there m=
ay be cases where you want to assign the continuation returned from operato=
r() to some other std::continuation object, wouldn&#39;t it be more appropr=
iate to make simple things simple by letting operator() return void and aut=
omatically update its `this` to the new state before returning and then app=
lications which really do need to move the continuation object elsewhere ca=
n do so afterwards. <br></div></div></blockquote><div><br></div><div>I&#39;=
ve had several variations of <span tabindex=3D"-1" id=3D":33s.8" style=3D""=
 class=3D"">callcc</span>() implemented and I got into troubles during the =
implementation of fibers (lightweight threads) using such a kind of call/cc=
..<br></div><div>I would not consider to change the identity of a continuati=
on while invoking its operator() a good idea - you don&#39;t know to which =
context your continuation points to (e.g. what it executes/does) <span tabi=
ndex=3D"-1" id=3D":33s.11" style=3D"" class=3D"">aft</span>er returning fro=
m continuation::operator().<br></div><div><br>=C2=A0</div><blockquote style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex" class=3D"gmail_quote"><div dir=3D"ltr"><div></div><div></div><di=
v>A comment on the invoke_on_top_t functionality. Why add a special tag typ=
e just to be able to overload operator() to do another task when there is t=
he possibility to add a regular method: std::continuation::invoke_on_<wbr>t=
op(args...).</div></div></blockquote><div><br></div><div>both is possible :=
 because apply-operator does the context switch I&#39;d like to use the sam=
e operator to do the context switch + invoking an function on the resumed c=
ontext <br></div><div><br></div><div>=C2=A0</div><blockquote style=3D"margi=
n:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex=
" class=3D"gmail_quote"><div dir=3D"ltr"><div>Also it would be interesting =
to know when this rather strange functionality is useful.</div></div></bloc=
kquote><div><br></div><div>described in P0534:<br></div><div>you can invoke=
 a new function after resuming the context that throws an exception<br></di=
v><div>for instance you want abort <span tabindex=3D"-1" id=3D":33s.12" sty=
le=3D"" class=3D"">and</span> unwind the stack - instead to check for abort=
 each time the context is resumed you call invoke-<span tabindex=3D"-1" id=
=3D":33s.13" style=3D"" class=3D"">ontop</span> functionality to execute th=
e throwing abort function only at the time point you know you want to abort=
 the continuation/context<br></div><div><br>=C2=A0</div><blockquote style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex" class=3D"gmail_quote"><div dir=3D"ltr"><div>An issue I stumbled =
upon during implementation was not being able to do callcc() on a method. I=
 think an overload of callcc specifically for method pointers (in parallel =
with the std::function constructor set) will be needed. This is as the std:=
:continuation&amp;&amp; parameter gets prepended to the args of callcc when=
 calling the provided function. If the provided function is a std::function=
 wrapping a method pointer its operator() will expect to get the &#39;this&=
#39; of the object to call and instead it will get the std::continuation pr=
epended by callcc!</div><div><br></div><blockquote style=3D"margin:0px 0px =
0px 40px;border-width:medium;border-style:none;border-color:-moz-use-text-c=
olor;padding:0px"><div>// Example:</div><div><br></div><div>class MyClass {=
</div><div>=C2=A0 =C2=A0 void fun(std::continuation&amp;&amp; cont);</div><=
div>};</div><div><br></div><div>MyClass myObj;</div><div><br></div><div>cal=
lcc(&amp;MyClass::fun, myObj); =C2=A0 =C2=A0// This is what you want to wri=
te, but callcc does not take method pointers.</div><div><br></div><div>// S=
o you may try this:</div><div><br></div><div>callcc(std::function&lt;void(<=
wbr>MyClass&amp;, std::continuation&amp;&amp;)&gt;(&amp;<wbr>MyClass::fun),=
 myObj); =C2=A0 // Mismatched types as callcc gets the order wrong.</div><d=
iv><br></div><div>// Instead you have to conjure up a lambda:</div><div><br=
></div><div>callcc([&amp;](std::continuation&amp;&amp; cont) { myObj.fun(st=
d::move(cont); });</div></blockquote><div><br></div><div><br></div><div>Whi=
le the lambda solution works I think it is quite weak not to allow the firs=
t version.<br></div></div></blockquote></div><br></div><div class=3D"gmail_=
extra">I&#39;m too busy - so it didn&#39;t got the highest <span tabindex=
=3D"-1" id=3D":33s.15" style=3D"" class=3D"">prio</span>/keep in mind I do =
it at my <span tabindex=3D"-1" id=3D":33s.16" style=3D"" class=3D"">freetim=
e</span></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CA%2Bwfc1-Pd3iR%2BxBeqDc4AZ_BpPFJRJw5=
grusofJaY8UuUnvEcA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter"=
>https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2Bwfc1-Pd3=
iR%2BxBeqDc4AZ_BpPFJRJw5grusofJaY8UuUnvEcA%40mail.gmail.com</a>.<br />

--f403045e61fcca0a1c0549be96cd--

.

--001a114e6e7c2bc2cc0549c1a543
Content-Type: text/plain; charset=UTF-8

2017-03-02 13:29 GMT+01:00 Oliver Kowalke <oliver.kowalke@gmail.com>:


> An issue I stumbled upon during implementation was not being able to do
>> callcc() on a method. I think an overload of callcc specifically for method
>> pointers (in parallel with the std::function constructor set) will be
>> needed. This is as the std::continuation&& parameter gets prepended to the
>> args of callcc when calling the provided function. If the provided function
>> is a std::function wrapping a method pointer its operator() will expect to
>> get the 'this' of the object to call and instead it will get the
>> std::continuation prepended by callcc!
>>
>> // Example:
>>
>> class MyClass {
>>     void fun(std::continuation&& cont);
>> };
>>
>> MyClass myObj;
>>
>> callcc(&MyClass::fun, myObj);    // This is what you want to write, but
>> callcc does not take method pointers.
>>
>> // So you may try this:
>>
>> callcc(std::function<void(MyClass&, std::continuation&&)>(&MyClass::fun),
>> myObj);   // Mismatched types as callcc gets the order wrong.
>>
>> // Instead you have to conjure up a lambda:
>>
>> callcc([&](std::continuation&& cont) { myObj.fun(std::move(cont); });
>>
>>
>>
>> While the lambda solution works I think it is quite weak not to allow the
>> first version.
>>
>
> I'm too busy - so it didn't got the highest prio/keep in mind I do it at
> my freetime
>

I took a look into the implementation at boost.context - actually it is
already supported:

template< typename Fn, typename ... Arg
>

continuation callcc( Fn && fn, Arg ... arg);

Seams I was too busy and I forgot it to update the proposal.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2Bwfc19z6s7JN8S-wdHJhxby_di6KcQgUtjD9s77NeR-sm8_oA%40mail.gmail.com.

--001a114e6e7c2bc2cc0549c1a543
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">2017-03-02 13:29 GMT+01:00 Oliver Kowalke <span dir=3D"ltr">&lt;<a href=
=3D"mailto:oliver.kowalke@gmail.com" target=3D"_blank">oliver.kowalke@gmail=
..com</a>&gt;</span>:<br><div>=C2=A0</div><blockquote class=3D"gmail_quote" =
style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pa=
dding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"g=
mail_quote"><span class=3D"gmail-"><div> </div></span><span class=3D"gmail-=
"><blockquote style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(2=
04,204,204);padding-left:1ex" class=3D"gmail_quote"><div dir=3D"ltr"><div>A=
n issue I stumbled upon during implementation was not being able to do call=
cc() on a method. I think an overload of callcc specifically for method poi=
nters (in parallel with the std::function constructor set) will be needed. =
This is as the std::continuation&amp;&amp; parameter gets prepended to the =
args of callcc when calling the provided function. If the provided function=
 is a std::function wrapping a method pointer its operator() will expect to=
 get the &#39;this&#39; of the object to call and instead it will get the s=
td::continuation prepended by callcc!</div><div><br></div><blockquote style=
=3D"margin:0px 0px 0px 40px;border-width:medium;border-style:none;border-co=
lor:-moz-use-text-color;padding:0px"><div>// Example:</div><div><br></div><=
div>class MyClass {</div><div>=C2=A0 =C2=A0 void fun(std::continuation&amp;=
&amp; cont);</div><div>};</div><div><br></div><div>MyClass myObj;</div><div=
><br></div><div>callcc(&amp;MyClass::fun, myObj); =C2=A0 =C2=A0// This is w=
hat you want to write, but callcc does not take method pointers.</div><div>=
<br></div><div>// So you may try this:</div><div><br></div><div>callcc(std:=
:function&lt;void(MyCl<wbr>ass&amp;, std::continuation&amp;&amp;)&gt;(&amp;=
MyClass<wbr>::fun), myObj); =C2=A0 // Mismatched types as callcc gets the o=
rder wrong.</div><div><br></div><div>// Instead you have to conjure up a la=
mbda:</div><div><br></div><div>callcc([&amp;](std::continuation&amp;&amp; c=
ont) { myObj.fun(std::move(cont); });</div></blockquote><div><br></div><div=
><br></div><div>While the lambda solution works I think it is quite weak no=
t to allow the first version.<br></div></div></blockquote></span></div><br>=
</div><div class=3D"gmail_extra">I&#39;m too busy - so it didn&#39;t got th=
e highest <span id=3D"gmail-m_-5290868785267533718:33s.15">prio</span>/keep=
 in mind I do it at my <span id=3D"gmail-m_-5290868785267533718:33s.16">fre=
etime</span></div></div>
</blockquote></div><br></div><div class=3D"gmail_extra">I took a look into =
the implementation at boost.context - actually it is already supported:<br>=
<br>template&lt; typename Fn, typename ... Arg &gt;=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 <br>continuation callcc( Fn &amp;&amp; fn, Arg ... arg);<br><br>Seams I=
 was too busy and I forgot it to update the proposal.</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CA%2Bwfc19z6s7JN8S-wdHJhxby_di6KcQgUt=
jD9s77NeR-sm8_oA%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2Bwfc19z6s7J=
N8S-wdHJhxby_di6KcQgUtjD9s77NeR-sm8_oA%40mail.gmail.com</a>.<br />

--001a114e6e7c2bc2cc0549c1a543--

.

--Apple-Mail=_E8270D97-9EF4-4594-9397-D27C3C93C4E5
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8

On Thursday, March 2, 2017 at 4:43:30 AM UTC-5, Bengt Gustafsson wrote:
=E2=80=A6

A comment on the invoke_on_top_t functionality. Why add a special tag type =
just to be able to overload operator() to do another task when there is the=
 possibility to add a regular method: std::continuation::invoke_on_top(args=
....). Also it would be interesting to know when this rather strange functio=
nality is useful.

=E2=80=A6

     Just a small thought that I had while keeping tabs on this thread, eve=
n if only as a mailing-list lurker (for the most part, anyway;) but one use=
 case of something like `invoke_on_top_t` would be to implement a tail-recu=
rsive 'trampoline' function <https://en.wikipedia.org/wiki/Trampoline_(comp=
uting)>. =20

=E2=80=94=E2=80=89Bryce Glover
=E3=80=80=E2=80=89RandomDSdevel@gmail.com

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/26EDCD88-C4FB-47F3-BF21-38D980966CA8%40gmail.com=
..

--Apple-Mail=_E8270D97-9EF4-4594-9397-D27C3C93C4E5
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><span style=3D"col=
or: rgb(34, 34, 34); font-family: Arial, Helvetica, sans-serif; font-size: =
13px; background-color: rgb(255, 255, 255);" class=3D"">On Thursday, March =
2, 2017 at 4:43:30 AM UTC-5, Bengt Gustafsson wrote:</span><br style=3D"col=
or: rgb(34, 34, 34); font-family: Arial, Helvetica, sans-serif; font-size: =
13px;" class=3D""><blockquote class=3D"gmail_quote" style=3D"color: rgb(34,=
 34, 34); font-family: Arial, Helvetica, sans-serif; font-size: 13px; margi=
n: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 2=
04, 204); border-left-style: solid; padding-left: 1ex;"><div dir=3D"ltr" st=
yle=3D"margin: 0px; padding: 0px; border: 0px;" class=3D"">=E2=80=A6<br cla=
ss=3D""><div style=3D"margin: 0px; padding: 0px; border: 0px;" class=3D""><=
br class=3D""></div><div style=3D"margin: 0px; padding: 0px; border: 0px;" =
class=3D"">A comment on the invoke_on_top_t functionality. Why add a specia=
l tag type just to be able to overload operator() to do another task when t=
here is the possibility to add a regular method: std::continuation::invoke_=
on_<wbr class=3D"">top(args...). Also it would be interesting to know when =
this rather strange functionality is useful.</div><div style=3D"margin: 0px=
; padding: 0px; border: 0px;" class=3D""><br class=3D""></div><div style=3D=
"margin: 0px; padding: 0px; border: 0px;" class=3D"">=E2=80=A6</div></div><=
/blockquote><div style=3D"margin: 0px; padding: 0px; border: 0px; color: rg=
b(34, 34, 34); font-family: Arial, Helvetica, sans-serif; font-size: 13px;"=
 class=3D""><br class=3D""></div><div style=3D"margin: 0px; padding: 0px; b=
order: 0px; color: rgb(34, 34, 34); font-family: Arial, Helvetica, sans-ser=
if; font-size: 13px;" class=3D"">&nbsp; &nbsp; &nbsp;Just a small thought t=
hat I had while keeping tabs on this thread, even if only as a mailing-list=
 lurker (for the&nbsp;<i class=3D"">most</i>&nbsp;part, anyway;) but&nbsp;<=
i class=3D"">one</i>&nbsp;use case of something like `invoke_on_top_t` woul=
d be to implement a tail-recursive&nbsp;<a href=3D"https://en.wikipedia.org=
/wiki/Trampoline_(computing)" style=3D"margin: 0px; padding: 0px; border: 0=
px; text-decoration: none; color: rgb(102, 17, 204); cursor: text;" class=
=3D"">'trampoline' function</a>. &nbsp;</div><div style=3D"margin: 0px; pad=
ding: 0px; border: 0px; color: rgb(34, 34, 34); font-family: Arial, Helveti=
ca, sans-serif; font-size: 13px;" class=3D""><br class=3D""></div><div styl=
e=3D"margin: 0px; padding: 0px; border: 0px; color: rgb(34, 34, 34); font-f=
amily: Arial, Helvetica, sans-serif; font-size: 13px;" class=3D""><div styl=
e=3D"margin: 0px; padding: 0px; border: 0px;" class=3D"">=E2=80=94=E2=80=89=
Bryce Glover</div><div style=3D"margin: 0px; padding: 0px; border: 0px;" cl=
ass=3D"">=E3=80=80=E2=80=89<a href=3D"mailto:RandomDSdevel@gmail.com" class=
=3D"">RandomDSdevel@gmail.com</a></div></div></body></html>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/26EDCD88-C4FB-47F3-BF21-38D980966CA8%=
40gmail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/26EDCD88-C4FB-47F3-BF21-38D980966CA8%=
40gmail.com</a>.<br />

--Apple-Mail=_E8270D97-9EF4-4594-9397-D27C3C93C4E5--

.

------=_Part_1140_1877694992.1488637665754
Content-Type: multipart/alternative;
 boundary="----=_Part_1141_1224488377.1488637665754"

------=_Part_1141_1224488377.1488637665754
Content-Type: text/plain; charset=UTF-8


>
>
> But I don't understand the need of data transfer at this low abstraction
>> level. After all, these are not threads, so there is no asynchronism to
>> think about.
>>
>
> P0534 is symmetric context switching, e.g. no coupling between caller and
> callee as it is for generators/coroutines.
>
Exactly, that's why I asked why data transfer is needed _on the call/cc
level_. I showed in my example that you can do data transfer on top of this
(at the generator level) with essentially no overhead. Giovanni pointed out
that there may be the overhead of one register save/restore, and if this
the performance gain you are after I think the price of a scary "void*"
style interface (hidden behind an unsafe cast) is not worth it, and if the
access is to be tested the performance cost is definitely more than a
register save.


>
>
>
>
>> When I wrote the code for generator.h I also saw that the pattern
>> `mContinuation = mContinuation()` seems to be mandatory. If you forget the
>> assignment you loose the ability to continue the next time. While there may
>> be cases where you want to assign the continuation returned from operator()
>> to some other std::continuation object, wouldn't it be more appropriate to
>> make simple things simple by letting operator() return void and
>> automatically update its `this` to the new state before returning and then
>> applications which really do need to move the continuation object elsewhere
>> can do so afterwards.
>>
>
> I've had several variations of callcc() implemented and I got into
> troubles during the implementation of fibers (lightweight threads) using
> such a kind of call/cc.
> I would not consider to change the identity of a continuation while
> invoking its operator() a good idea - you don't know to which context your
> continuation points to (e.g. what it executes/does) after returning from
> continuation::operator().
>
And you don't know the identity of the continuation returned from
operator() in your case, what is the difference? The advantage of the in
situ version is however obvious: You can't forget doing the assignment, and
thereby leave the continuation object stale.

>
>
>
>> A comment on the invoke_on_top_t functionality. Why add a special tag
>> type just to be able to overload operator() to do another task when there
>> is the possibility to add a regular method:
>> std::continuation::invoke_on_top(args...).
>>
>
> both is possible : because apply-operator does the context switch I'd like
> to use the same operator to do the context switch + invoking an function on
> the resumed context
>

I find this a very weak reason to go through the hoops of creating and
using a specific tag class.

>
>
>
>> Also it would be interesting to know when this rather strange
>> functionality is useful.
>>
>
> described in P0534:
> you can invoke a new function after resuming the context that throws an
> exception
>

It is a bit hard to understsand this sentense. Do you mean to resume a
context after it has thrown an exception? If this is what you mean, there
could be two cases: a) the exception was not caught. In this case the stack
is completely unwound as if the function had returned, and what you are
doing is only to reuse the stack memory, right? b) the exception was caught
somewhere during unwindining and the continuation was invoked in a catch
clause. Now the invoke_on_top injects some code to be run inside the catch.
I still don't see what good this would do. Also, if there is a throw; below
the continuation invokation things would get messy if the injected code
throws (even if this exception is caught).


> for instance you want abort and unwind the stack - instead to check for
> abort each time the context is resumed you call invoke-ontop
> functionality to execute the throwing abort function only at the time point
> you know you want to abort the continuation/context
>
I think you may be saying that once in a while one party injects code that
throws if an abort flag is set into another piece of code on the other side
of the continuation. Or maybe you test the abort flag first and then
injects a function which just throws an exception. Well that would be a way
to get rid of the continuation and properly unwind its stack, but didn't
you have a specific way of doing that, such as desrtroying the continuation
object?

>
>
>
>> An issue I stumbled upon during implementation was not being able to do
>> callcc() on a method. I think an overload of callcc specifically for method
>> pointers (in parallel with the std::function constructor set) will be
>> needed. This is as the std::continuation&& parameter gets prepended to the
>> args of callcc when calling the provided function. If the provided function
>> is a std::function wrapping a method pointer its operator() will expect to
>> get the 'this' of the object to call and instead it will get the
>> std::continuation prepended by callcc!
>>
>> // Example:
>>
>> class MyClass {
>>     void fun(std::continuation&& cont);
>> };
>>
>> MyClass myObj;
>>
>> callcc(&MyClass::fun, myObj);    // This is what you want to write, but
>> callcc does not take method pointers.
>>
>> // So you may try this:
>>
>> callcc(std::function<void(MyClass&, std::continuation&&)>(&MyClass::fun),
>> myObj);   // Mismatched types as callcc gets the order wrong.
>>
>> // Instead you have to conjure up a lambda:
>>
>> callcc([&](std::continuation&& cont) { myObj.fun(std::move(cont); });
>>
>>
>>
>> While the lambda solution works I think it is quite weak not to allow the
>> first version.
>>
>
> I'm too busy - so it didn't got the highest prio/keep in mind I do it at
> my freetime
>
I do too, so we're in the same sitation there...

 In your next reply you again point at the _function_ based version of
callcc, which is what caused my concern in the first place. Maybe you just
pasted the wrong snippet? If not, here it is again: The problem is that as
callcc prepends the continuation to the parameter list of the provided Fn
there is a problem for a std::function encapsulating a method (which
mandates a compatible object as its first invoktion parameter).


--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/33bda80d-c83a-4cb9-a67f-5c7b2658e060%40isocpp.org.

------=_Part_1141_1224488377.1488637665754
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><div><div class=3D"gmail_quote"><br><blockquote style=3D"margin:0px 0px=
 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class=
=3D"gmail_quote"><div dir=3D"ltr">But I don&#39;t understand the need of da=
ta transfer at this low abstraction level. After all, these are not threads=
, so there is no asynchronism to think about. <br></div></blockquote><div><=
br></div><div>P0534 is symmetric context switching, e.g. no coupling betwee=
n caller and <span>callee</span> as it is for generators/<span>coroutines.<=
/span></div></div></div></div></blockquote><div>Exactly, that&#39;s why I a=
sked why data transfer is needed _on the call/cc level_. I showed in my exa=
mple that you can do data transfer on top of this (at the generator level) =
with essentially no overhead. Giovanni pointed out that there may be the ov=
erhead of one register save/restore, and if this the performance gain you a=
re after I think the price of a scary &quot;void*&quot; style interface (hi=
dden behind an unsafe cast) is not worth it, and if the access is to be tes=
ted the performance cost is definitely more than a register save.</div><div=
>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
<div><div class=3D"gmail_quote"><div><br></div><div><br>=C2=A0</div><blockq=
uote style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,20=
4);padding-left:1ex" class=3D"gmail_quote"><div dir=3D"ltr"><div>When I wro=
te the code for generator.h I also saw that the pattern `mContinuation =3D =
mContinuation()` seems to be mandatory. If you forget the assignment you lo=
ose the ability to continue the next time. While there may be cases where y=
ou want to assign the continuation returned from operator() to some other s=
td::continuation object, wouldn&#39;t it be more appropriate to make simple=
 things simple by letting operator() return void and automatically update i=
ts `this` to the new state before returning and then applications which rea=
lly do need to move the continuation object elsewhere can do so afterwards.=
 <br></div></div></blockquote><div><br></div><div>I&#39;ve had several vari=
ations of <span>callcc</span>() implemented and I got into troubles during =
the implementation of fibers (lightweight threads) using such a kind of cal=
l/cc.<br></div><div>I would not consider to change the identity of a contin=
uation while invoking its operator() a good idea - you don&#39;t know to wh=
ich context your continuation points to (e.g. what it executes/does) <span>=
aft</span>er returning from continuation::operator().<br></div></div></div>=
</div></blockquote><div>And you don&#39;t know the identity of the continua=
tion returned from operator() in your case, what is the difference? The adv=
antage of the in situ version is however obvious: You can&#39;t forget doin=
g the assignment, and thereby leave the continuation object stale.=C2=A0</d=
iv><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;=
border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div =
class=3D"gmail_quote"><div></div><div><br>=C2=A0</div><blockquote style=3D"=
margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-lef=
t:1ex" class=3D"gmail_quote"><div dir=3D"ltr"><div></div><div></div><div>A =
comment on the invoke_on_top_t functionality. Why add a special tag type ju=
st to be able to overload operator() to do another task when there is the p=
ossibility to add a regular method: std::continuation::invoke_on_<wbr>top(a=
rgs...).</div></div></blockquote><div><br></div><div>both is possible : bec=
ause apply-operator does the context switch I&#39;d like to use the same op=
erator to do the context switch + invoking an function on the resumed conte=
xt <br></div></div></div></div></blockquote><div><br></div><div>I find this=
 a very weak reason to go through the hoops of creating and using a specifi=
c tag class.=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div d=
ir=3D"ltr"><div><div class=3D"gmail_quote"><div></div><div><br></div><div>=
=C2=A0</div><blockquote style=3D"margin:0px 0px 0px 0.8ex;border-left:1px s=
olid rgb(204,204,204);padding-left:1ex" class=3D"gmail_quote"><div dir=3D"l=
tr"><div>Also it would be interesting to know when this rather strange func=
tionality is useful.</div></div></blockquote><div><br></div><div>described =
in P0534:<br></div><div>you can invoke a new function after resuming the co=
ntext that throws an exception<br></div></div></div></div></blockquote><div=
>=C2=A0</div><div>It is a bit hard to understsand this sentense. Do you mea=
n to resume a context after it has thrown an exception? If this is what you=
 mean, there could be two cases: a) the exception was not caught. In this c=
ase the stack is completely unwound as if the function had returned, and wh=
at you are doing is only to reuse the stack memory, right? b) the exception=
 was caught somewhere during unwindining and the continuation was invoked i=
n a catch clause. Now the invoke_on_top injects some code to be run inside =
the catch. I still don&#39;t see what good this would do. Also, if there is=
 a throw; below the continuation invokation things would get messy if the i=
njected code throws (even if this exception is caught).</div><div>=C2=A0</d=
iv><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;=
border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div =
class=3D"gmail_quote"><div></div><div>for instance you want abort <span>and=
</span> unwind the stack - instead to check for abort each time the context=
 is resumed you call invoke-<span>ontop</span> functionality to execute the=
 throwing abort function only at the time point you know you want to abort =
the continuation/context<br></div></div></div></div></blockquote><div>I thi=
nk you may be saying that once in a while one party injects code that throw=
s if an abort flag is set into another piece of code on the other side of t=
he continuation. Or maybe you test the abort flag first and then injects a =
function which just throws an exception. Well that would be a way to get ri=
d of the continuation and properly unwind its stack, but didn&#39;t you hav=
e a specific way of doing that, such as desrtroying the continuation object=
?</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.=
8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><=
div class=3D"gmail_quote"><div></div><div><br>=C2=A0</div><blockquote style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex" class=3D"gmail_quote"><div dir=3D"ltr"><div>An issue I stumbled =
upon during implementation was not being able to do callcc() on a method. I=
 think an overload of callcc specifically for method pointers (in parallel =
with the std::function constructor set) will be needed. This is as the std:=
:continuation&amp;&amp; parameter gets prepended to the args of callcc when=
 calling the provided function. If the provided function is a std::function=
 wrapping a method pointer its operator() will expect to get the &#39;this&=
#39; of the object to call and instead it will get the std::continuation pr=
epended by callcc!</div><div><br></div><blockquote style=3D"margin:0px 0px =
0px 40px;border-width:medium;border-style:none;border-color:-moz-use-text-c=
olor;padding:0px"><div>// Example:</div><div><br></div><div>class MyClass {=
</div><div>=C2=A0 =C2=A0 void fun(std::continuation&amp;&amp; cont);</div><=
div>};</div><div><br></div><div>MyClass myObj;</div><div><br></div><div>cal=
lcc(&amp;MyClass::fun, myObj); =C2=A0 =C2=A0// This is what you want to wri=
te, but callcc does not take method pointers.</div><div><br></div><div>// S=
o you may try this:</div><div><br></div><div>callcc(std::function&lt;void(<=
wbr>MyClass&amp;, std::continuation&amp;&amp;)&gt;(&amp;<wbr>MyClass::fun),=
 myObj); =C2=A0 // Mismatched types as callcc gets the order wrong.</div><d=
iv><br></div><div>// Instead you have to conjure up a lambda:</div><div><br=
></div><div>callcc([&amp;](std::continuation&amp;&amp; cont) { myObj.fun(st=
d::move(cont); });</div></blockquote><div><br></div><div><br></div><div>Whi=
le the lambda solution works I think it is quite weak not to allow the firs=
t version.<br></div></div></blockquote></div><br></div><div>I&#39;m too bus=
y - so it didn&#39;t got the highest <span>prio</span>/keep in mind I do it=
 at my <span>freetime</span></div></div></blockquote><div>I do too, so we&#=
39;re in the same sitation there...</div><div><br></div><div>=C2=A0In your =
next reply you again point at the _function_ based version of callcc, which=
 is what caused my concern in the first place. Maybe you just pasted the wr=
ong snippet? If not, here it is again: The problem is that as callcc prepen=
ds the continuation to the parameter list of the provided Fn there is a pro=
blem for a std::function encapsulating a method (which mandates a compatibl=
e object as its first invoktion parameter).</div><div>=C2=A0</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/33bda80d-c83a-4cb9-a67f-5c7b2658e060%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/33bda80d-c83a-4cb9-a67f-5c7b2658e060=
%40isocpp.org</a>.<br />

------=_Part_1141_1224488377.1488637665754--

------=_Part_1140_1877694992.1488637665754--

.

--f403045c60fa1503230549e9f4ab
Content-Type: text/plain; charset=UTF-8

2017-03-04 15:27 GMT+01:00 Bengt Gustafsson <bengt.gustafsson@beamways.com>:

>
>> But I don't understand the need of data transfer at this low abstraction
>>> level. After all, these are not threads, so there is no asynchronism to
>>> think about.
>>>
>>
>> P0534 is symmetric context switching, e.g. no coupling between caller and
>> callee as it is for generators/coroutines.
>>
> Exactly, that's why I asked why data transfer is needed _on the call/cc
> level_. I showed in my example that you can do data transfer on top of this
> (at the generator level) with essentially no overhead. Giovanni pointed out
> that there may be the overhead of one register save/restore, and if this
> the performance gain you are after I think the price of a scary "void*"
> style interface (hidden behind an unsafe cast) is not worth it, and if the
> access is to be tested the performance cost is definitely more than a
> register save.
>

I don't see your point - accessing a register if verry fast (1 CPU cycle I
guess).
The data transfer as proposed in P0534 (and used for coroutine and fiber
implementation) does provide some kind of type-safety and no overhead if no
data are transferred.


>  And you don't know the identity of the continuation returned from
> operator() in your case, what is the difference? The advantage of the in
> situ version is however obvious: You can't forget doing the assignment, and
> thereby leave the continuation object stale.
>

Suppose you have contoinuations c1, c2:

c1 = callcc( foo);
c2 = callcc( bar);

- in main() you resume c1: c1();
- c1 executes foo
- in foo you resume c2: c2()
- c2 executes bar
- in bar you jump to main()
- that means you return from c1() in main()
- if you call c1() in main() you do resume bar() instead of foo()



>
>>
>>
>>> Also it would be interesting to know when this rather strange
>>> functionality is useful.
>>>
>>
>> described in P0534:
>> you can invoke a new function after resuming the context that throws an
>> exception
>>
>
> It is a bit hard to understsand this sentense.
>

context switching is a bit mind twisiting


> Do you mean to resume a context after it has thrown an exception?
>

no - resume the context and then, if you are in the resumed context, create
a new stack frame and execute your supplied function (that might throw)


>
>
>> for instance you want abort and unwind the stack - instead to check for
>> abort each time the context is resumed you call invoke-ontop
>> functionality to execute the throwing abort function only at the time point
>> you know you want to abort the continuation/context
>>
> I think you may be saying that once in a while one party injects code that
> throws if an abort flag is set into another piece of code on the other side
> of the continuation.
>

yes


> Or maybe you test the abort flag first and then injects a function which
> just throws an exception. Well that would be a way to get rid of the
> continuation and properly unwind its stack, but didn't you have a specific
> way of doing that, such as desrtroying the continuation object?
>

throwing an exeception was only one use case - infact if a suspended
continuation has to be destroyed (instance goes out of scope) out of a deep
callstack - the current implementation executes a function ontop of those
continuation that throws a speciall exception that unwinds the stakc of the
continuation and jumps back to the caller.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2Bwfc1_jk4zFYjr4nrvFzhN6RY9XrfSipVPEwPfSRbY8hMQJzg%40mail.gmail.com.

--f403045c60fa1503230549e9f4ab
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">2017=
-03-04 15:27 GMT+01:00 Bengt Gustafsson <span dir=3D"ltr">&lt;<a href=3D"ma=
ilto:bengt.gustafsson@beamways.com" target=3D"_blank">bengt.gustafsson@beam=
ways.com</a>&gt;</span>:<br><blockquote class=3D"gmail_quote" style=3D"marg=
in:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1e=
x"><div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div =
dir=3D"ltr"><div><div class=3D"gmail_quote"><span class=3D"gmail-"><br><blo=
ckquote style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204=
,204);padding-left:1ex" class=3D"gmail_quote"><div dir=3D"ltr">But I don&#3=
9;t understand the need of data transfer at this low abstraction level. Aft=
er all, these are not threads, so there is no asynchronism to think about. =
<br></div></blockquote><div><br></div></span><div>P0534 is symmetric contex=
t switching, e.g. no coupling between caller and <span>callee</span> as it =
is for generators/<span>coroutines.</span></div></div></div></div></blockqu=
ote><div>Exactly, that&#39;s why I asked why data transfer is needed _on th=
e call/cc level_. I showed in my example that you can do data transfer on t=
op of this (at the generator level) with essentially no overhead. Giovanni =
pointed out that there may be the overhead of one register save/restore, an=
d if this the performance gain you are after I think the price of a scary &=
quot;void*&quot; style interface (hidden behind an unsafe cast) is not wort=
h it, and if the access is to be tested the performance cost is definitely =
more than a register save.</div></div></blockquote><div><br></div><div>I do=
n&#39;t see your point - accessing a register if verry fast (1 CPU cycle I =
guess).<br></div><div>The data transfer as proposed in P0534 (and used for =
coroutine and fiber implementation) does provide some kind of type-safety a=
nd no overhead if no data are transferred.</div><div>=C2=A0</div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px s=
olid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><span class=3D"gma=
il-"><div>=C2=A0And you don&#39;t know the identity of the continuation ret=
urned from operator() in your case, what is the difference? The advantage o=
f the in situ version is however obvious: You can&#39;t forget doing the as=
signment, and thereby leave the continuation object stale.=C2=A0</div></spa=
n></div></blockquote><div><br></div><div>Suppose you have contoinuations c1=
, c2:<br><br></div><div>c1 =3D callcc( foo);<br>c2 =3D callcc( bar);</div><=
div><br></div><div>- in main() you resume c1: c1();<br>- c1 executes foo<br=
></div><div>- in foo you resume c2: c2()<br></div><div>- c2 executes bar<br=
></div><div>- in bar you jump to main()<br></div><div>- that means you retu=
rn from c1() in main()<br></div><div>- if you call c1() in main() you do re=
sume bar() instead of foo()<br><br></div><div>=C2=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex"><div dir=3D"ltr"><span class=3D"gmail-"><b=
lockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-le=
ft:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div><div =
class=3D"gmail_quote"><div></div><div><br></div><div>=C2=A0</div><blockquot=
e style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);=
padding-left:1ex" class=3D"gmail_quote"><div dir=3D"ltr"><div>Also it would=
 be interesting to know when this rather strange functionality is useful.</=
div></div></blockquote><div><br></div><div>described in P0534:<br></div><di=
v>you can invoke a new function after resuming the context that throws an e=
xception<br></div></div></div></div></blockquote><div>=C2=A0</div></span><d=
iv>It is a bit hard to understsand this sentense. </div></div></blockquote>=
<div><br></div><div>context switching is a bit mind twisiting<br></div><div=
>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px =
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"=
ltr"><div>Do you mean to resume a context after it has thrown an exception?=
 </div></div></blockquote><div><br></div><div>no - resume the context and t=
hen, if you are in the resumed context, create a new stack frame and execut=
e your supplied function (that might throw) <br></div><div>=C2=A0</div><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><span class=
=3D"gmail-"><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1=
ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div></div><div>for in=
stance you want abort <span>and</span> unwind the stack - instead to check =
for abort each time the context is resumed you call invoke-<span>ontop</spa=
n> functionality to execute the throwing abort function only at the time po=
int you know you want to abort the continuation/context<br></div></div></di=
v></div></blockquote></span><div>I think you may be saying that once in a w=
hile one party injects code that throws if an abort flag is set into anothe=
r piece of code on the other side of the continuation. </div></div></blockq=
uote><div><br></div><div>yes<br></div><div>=C2=A0</div><blockquote class=3D=
"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(2=
04,204,204);padding-left:1ex"><div dir=3D"ltr"><div>Or maybe you test the a=
bort flag first and then injects a function which just throws an exception.=
 Well that would be a way to get rid of the continuation and properly unwin=
d its stack, but didn&#39;t you have a specific way of doing that, such as =
desrtroying the continuation object?</div></div></blockquote><div><br></div=
><div>throwing an exeception was only one use case - infact if a suspended =
continuation has to be destroyed (instance goes out of scope) out of a deep=
 callstack - the current implementation executes a function ontop of those =
continuation that throws a speciall exception that unwinds the stakc of the=
 continuation and jumps back to the caller.<br></div><div>=C2=A0<br></div><=
/div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CA%2Bwfc1_jk4zFYjr4nrvFzhN6RY9XrfSipV=
PEwPfSRbY8hMQJzg%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">h=
ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2Bwfc1_jk4zF=
Yjr4nrvFzhN6RY9XrfSipVPEwPfSRbY8hMQJzg%40mail.gmail.com</a>.<br />

--f403045c60fa1503230549e9f4ab--

.

------=_Part_1214_2074571044.1488654255895
Content-Type: multipart/alternative;
 boundary="----=_Part_1215_1050567901.1488654255896"

------=_Part_1215_1050567901.1488654255896
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



Den l=C3=B6rdag 4 mars 2017 kl. 17:14:18 UTC+1 skrev Oliver Kowalke:
>
> 2017-03-04 15:27 GMT+01:00 Bengt Gustafsson <bengt.gu...@beamways.com=20
> <javascript:>>:
>
>>
>>> But I don't understand the need of data transfer at this low abstractio=
n=20
>>>> level. After all, these are not threads, so there is no asynchronism t=
o=20
>>>> think about.=20
>>>>
>>>
>>> P0534 is symmetric context switching, e.g. no coupling between caller=
=20
>>> and callee as it is for generators/coroutines.
>>>
>> Exactly, that's why I asked why data transfer is needed _on the call/cc=
=20
>> level_. I showed in my example that you can do data transfer on top of t=
his=20
>> (at the generator level) with essentially no overhead. Giovanni pointed =
out=20
>> that there may be the overhead of one register save/restore, and if this=
=20
>> the performance gain you are after I think the price of a scary "void*"=
=20
>> style interface (hidden behind an unsafe cast) is not worth it, and if t=
he=20
>> access is to be tested the performance cost is definitely more than a=20
>> register save.
>>
>
> I don't see your point - accessing a register if verry fast (1 CPU cycle =
I=20
> guess).
>
The point is that if the feature does not have a large performance gain=20
compared to not having it, and if it does not avoid a complex=20
synchronization problem then why have it? I don't see that you have shown=
=20
any major performance or synchronization gain.

=20

> The data transfer as proposed in P0534 (and used for coroutine and fiber=
=20
> implementation) does provide some kind of type-safety and no overhead if =
no=20
> data are transferred.
>
While ideas in the direction of my Generator class offers compile time type=
=20
safety and negligable overhead even if used! Not to mention a smaller API.
=20

> =20
>
>>  And you don't know the identity of the continuation returned from=20
>> operator() in your case, what is the difference? The advantage of the in=
=20
>> situ version is however obvious: You can't forget doing the assignment, =
and=20
>> thereby leave the continuation object stale.=20
>>
>
> Suppose you have contoinuations c1, c2:
>
> c1 =3D callcc( foo);
> c2 =3D callcc( bar);
>
> - in main() you resume c1: c1();
>
This must mean that both foo and bar have transfered control back to main=
=20
which in some later code calls c1().

> - c1 executes foo
>
continuing foo after its first context switch.=20
=20
=20

> - in foo you resume c2: c2()
>
ok, a bit odd but doable.=20

- c2 executes bar
>
continuing bar after its first context switch.
=20

> - in bar you jump to main()
>
Unless you involve setjmp/longjmp I don't see a way fot this to happen...=
=20
and those guys are not C++ safe anyway. What can happen is that foo gives=
=20
bar access to its stored continuation and bar uses this to transfer control=
=20
to main after its c1() call.
And sure enough c1 now refers to bar after its second context switch. Yes=
=20
this seems to be what you refer to.
=20

> - that means you return from c1() in main()
> - if you call c1() in main() you do resume bar() instead of foo()
>
Yes. This can happen if you store the continuations in global variables=20
where other functions can reach them. Isn't this why we want to abstract=20
the continuation level into higher level abstractions which are easier to=
=20
understand and where these types of
oddities are easy to avoid.

The only gain with the assignment is as a reminder of "next time this=20
continuation will continue executing somewhere else". But as that always=20
happens and you can not make something else happen by NOT doing the=20
assignment (except dropping a valuable asset) it seems rather error prone..=
..


> =20
>
>>
>>> =20
>>>
>>>> Also it would be interesting to know when this rather strange=20
>>>> functionality is useful.
>>>>
>>>
>>> described in P0534:
>>> you can invoke a new function after resuming the context that throws an=
=20
>>> exception
>>>
>> =20
>> It is a bit hard to understsand this sentense.=20
>>
>
> context switching is a bit mind twisiting
> =20
>
>> Do you mean to resume a context after it has thrown an exception?=20
>>
>
> no - resume the context and then, if you are in the resumed context,=20
> create a new stack frame and execute your supplied function (that might=
=20
> throw)=20
>
OK, I understand what it does, my question was why this is useful.=20

> =20
>
>> =20
>>
>>> for instance you want abort and unwind the stack - instead to check for=
=20
>>> abort each time the context is resumed you call invoke-ontop=20
>>> functionality to execute the throwing abort function only at the time p=
oint=20
>>> you know you want to abort the continuation/context
>>>
>> I think you may be saying that once in a while one party injects code=20
>> that throws if an abort flag is set into another piece of code on the ot=
her=20
>> side of the continuation.=20
>>
>
> yes
> =20
>
>> Or maybe you test the abort flag first and then injects a function which=
=20
>> just throws an exception. Well that would be a way to get rid of the=20
>> continuation and properly unwind its stack, but didn't you have a specif=
ic=20
>> way of doing that, such as desrtroying the continuation object?
>>
>
> throwing an exeception was only one use case - infact if a suspended=20
> continuation has to be destroyed (instance goes out of scope) out of a de=
ep=20
> callstack - the current implementation executes a function ontop of those=
=20
> continuation that throws a speciall exception that unwinds the stakc of t=
he=20
> continuation and jumps back to the caller.
>
Yes, that is how I understood it. This is what would happen if you forget=
=20
to assign the returned continuation to your variable, I assume ;-)

So the only use case for invoke_on_top() that you have produced is in fact=
=20
equivalent to destroying the continuation object. Given that you can't=20
access data in underlying stack frames I fail to see a difference between=
=20
these two:

continuation c;

fun()
c()

and
c.invoke_on_top(fun);

Well, there may be some difference if fun throws, but isn't it unlikely=20
that the code dormant in c would have suitable catch clauses for throws in=
=20
an unrelated function fun.

Ok, maybe you only see this as a method of throwing an exception in the=20
other stack, if so maybe it would be better to have an explicit mechanism=
=20
for this:

template<typename EX, typename.... Args> continuation::throw_in(Args...);

This just swaps the stacks and then executes `throw EX(args...)`

The advantage of this approach is that it is obvious what it does and it=20
does not invite to inject arbitrary function calls (which may throw=20
exceptions without catching them) onto some other stack not prepared for=20
this.,

I would have thought that the main use would be to allow a pool of fibers=
=20
to be used for executing arbitrary code. The main reason for not doing new=
=20
callcc() calls each time would be to avoid having to allocate stacks each=
=20
time. If this is the use case it seems that the stack rather than the=20
continuation is the object to preserve and pool. It may be that this is the=
=20
functionality Nicol was asking for.
=20

> =20
>

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/113327fb-b26a-421e-9b07-9a2045c4178f%40isocpp.or=
g.

------=_Part_1215_1050567901.1488654255896
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>Den l=C3=B6rdag 4 mars 2017 kl. 17:14:18 UTC+1 skr=
ev Oliver Kowalke:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"=
ltr"><div><div class=3D"gmail_quote">2017-03-04 15:27 GMT+01:00 Bengt Gusta=
fsson <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-o=
bfuscated-mailto=3D"vgzdgWShCgAJ" rel=3D"nofollow" onmousedown=3D"this.href=
=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascri=
pt:&#39;;return true;">bengt.gu...@beamways.com</a><wbr>&gt;</span>:<br><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-lef=
t:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><blockquote=
 class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px so=
lid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"=
gmail_quote"><span><br><blockquote style=3D"margin:0px 0px 0px 0.8ex;border=
-left:1px solid rgb(204,204,204);padding-left:1ex" class=3D"gmail_quote"><d=
iv dir=3D"ltr">But I don&#39;t understand the need of data transfer at this=
 low abstraction level. After all, these are not threads, so there is no as=
ynchronism to think about. <br></div></blockquote><div><br></div></span><di=
v>P0534 is symmetric context switching, e.g. no coupling between caller and=
 <span>callee</span> as it is for generators/<span>coroutines.</span></div>=
</div></div></div></blockquote><div>Exactly, that&#39;s why I asked why dat=
a transfer is needed _on the call/cc level_. I showed in my example that yo=
u can do data transfer on top of this (at the generator level) with essenti=
ally no overhead. Giovanni pointed out that there may be the overhead of on=
e register save/restore, and if this the performance gain you are after I t=
hink the price of a scary &quot;void*&quot; style interface (hidden behind =
an unsafe cast) is not worth it, and if the access is to be tested the perf=
ormance cost is definitely more than a register save.</div></div></blockquo=
te><div><br></div><div>I don&#39;t see your point - accessing a register if=
 verry fast (1 CPU cycle I guess).<br></div></div></div></div></blockquote>=
<div>The point is that if the feature does not have a large performance gai=
n compared to not having it, and if it does not avoid a complex synchroniza=
tion problem then why have it? I don&#39;t see that you have shown any majo=
r performance or synchronization gain.</div><div><br></div><div>=C2=A0</div=
><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bo=
rder-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div cl=
ass=3D"gmail_quote"><div></div><div>The data transfer as proposed in P0534 =
(and used for coroutine and fiber implementation) does provide some kind of=
 type-safety and no overhead if no data are transferred.</div></div></div><=
/div></blockquote><div>While ideas in the direction of my Generator class o=
ffers compile time type safety and negligable overhead even if used! Not to=
 mention a smaller API.</div><div>=C2=A0</div><blockquote class=3D"gmail_qu=
ote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padd=
ing-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div>=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"=
><span><div>=C2=A0And you don&#39;t know the identity of the continuation r=
eturned from operator() in your case, what is the difference? The advantage=
 of the in situ version is however obvious: You can&#39;t forget doing the =
assignment, and thereby leave the continuation object stale.=C2=A0</div></s=
pan></div></blockquote><div><br></div><div>Suppose you have contoinuations =
c1, c2:<br><br></div><div>c1 =3D callcc( foo);<br>c2 =3D callcc( bar);</div=
><div><br></div><div>- in main() you resume c1: c1();<br></div></div></div>=
</div></blockquote><div>This must mean that both foo and bar have transfere=
d control back to main which in some later code calls c1().</div><blockquot=
e class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: =
1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmai=
l_quote"><div>- c1 executes foo<br></div></div></div></div></blockquote><di=
v>continuing foo after its first context switch.=C2=A0</div><div>=C2=A0</di=
v><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D=
"ltr"><div><div class=3D"gmail_quote"><div></div><div>- in foo you resume c=
2: c2()<br></div></div></div></div></blockquote><div>ok, a bit odd but doab=
le.=C2=A0</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">=
<div dir=3D"ltr"><div><div class=3D"gmail_quote"><div></div><div>- c2 execu=
tes bar<br></div></div></div></div></blockquote><div>continuing bar after i=
ts first context switch.</div><div>=C2=A0</div><blockquote class=3D"gmail_q=
uote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pad=
ding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div></di=
v><div>- in bar you jump to main()<br></div></div></div></div></blockquote>=
<div>Unless you involve setjmp/longjmp I don&#39;t see a way fot this to ha=
ppen... and those guys are not C++ safe anyway. What can happen is that foo=
 gives bar access to its stored continuation and bar uses this to transfer =
control to main after its c1() call.</div><div>And sure enough c1 now refer=
s to bar after its second context switch. Yes this seems to be what you ref=
er to.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"mar=
gin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><=
div dir=3D"ltr"><div><div class=3D"gmail_quote"><div></div><div>- that mean=
s you return from c1() in main()<br></div><div>- if you call c1() in main()=
 you do resume bar() instead of foo()<br></div></div></div></div></blockquo=
te><div>Yes. This can happen if you store the continuations in global varia=
bles where other functions can reach them. Isn&#39;t this why we want to ab=
stract the continuation level into higher level abstractions which are easi=
er to understand and where these types of</div><div>oddities are easy to av=
oid.</div><div><br></div><div>The only gain with the assignment is as a rem=
inder of &quot;next time this continuation will continue executing somewher=
e else&quot;. But as that always happens and you can not make something els=
e happen by NOT doing the assignment (except dropping a valuable asset) it =
seems rather error prone...</div><div><br></div><blockquote class=3D"gmail_=
quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pa=
dding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div><br=
></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><=
div dir=3D"ltr"><span><blockquote class=3D"gmail_quote" style=3D"margin:0px=
 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><di=
v dir=3D"ltr"><div><div class=3D"gmail_quote"><div></div><div><br></div><di=
v>=C2=A0</div><blockquote style=3D"margin:0px 0px 0px 0.8ex;border-left:1px=
 solid rgb(204,204,204);padding-left:1ex" class=3D"gmail_quote"><div dir=3D=
"ltr"><div>Also it would be interesting to know when this rather strange fu=
nctionality is useful.</div></div></blockquote><div><br></div><div>describe=
d in P0534:<br></div><div>you can invoke a new function after resuming the =
context that throws an exception<br></div></div></div></div></blockquote><d=
iv>=C2=A0</div></span><div>It is a bit hard to understsand this sentense. <=
/div></div></blockquote><div><br></div><div>context switching is a bit mind=
 twisiting<br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddin=
g-left:1ex"><div dir=3D"ltr"><div>Do you mean to resume a context after it =
has thrown an exception? </div></div></blockquote><div><br></div><div>no - =
resume the context and then, if you are in the resumed context, create a ne=
w stack frame and execute your supplied function (that might throw) <br></d=
iv></div></div></div></blockquote><div>OK, I understand what it does, my qu=
estion was why this is useful.=C2=A0</div><blockquote class=3D"gmail_quote"=
 style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-=
left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div></div><di=
v>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D=
"ltr"><span><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1=
ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div></div><div>for in=
stance you want abort <span>and</span> unwind the stack - instead to check =
for abort each time the context is resumed you call invoke-<span>ontop</spa=
n> functionality to execute the throwing abort function only at the time po=
int you know you want to abort the continuation/context<br></div></div></di=
v></div></blockquote></span><div>I think you may be saying that once in a w=
hile one party injects code that throws if an abort flag is set into anothe=
r piece of code on the other side of the continuation. </div></div></blockq=
uote><div><br></div><div>yes<br></div><div>=C2=A0</div><blockquote class=3D=
"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(2=
04,204,204);padding-left:1ex"><div dir=3D"ltr"><div>Or maybe you test the a=
bort flag first and then injects a function which just throws an exception.=
 Well that would be a way to get rid of the continuation and properly unwin=
d its stack, but didn&#39;t you have a specific way of doing that, such as =
desrtroying the continuation object?</div></div></blockquote><div><br></div=
><div>throwing an exeception was only one use case - infact if a suspended =
continuation has to be destroyed (instance goes out of scope) out of a deep=
 callstack - the current implementation executes a function ontop of those =
continuation that throws a speciall exception that unwinds the stakc of the=
 continuation and jumps back to the caller.<br></div></div></div></div></bl=
ockquote><div>Yes, that is how I understood it. This is what would happen i=
f you forget to assign the returned continuation to your variable, I assume=
 ;-)</div><div><br></div><div>So the only use case for invoke_on_top() that=
 you have produced is in fact equivalent to destroying the continuation obj=
ect. Given that you can&#39;t access data in underlying stack frames I fail=
 to see a difference between these two:</div><div><br></div><div>continuati=
on c;</div><div><br></div><div>fun()</div><div>c()</div><div><br></div><div=
>and</div><div>c.invoke_on_top(fun);</div><div><br></div><div>Well, there m=
ay be some difference if fun throws, but isn&#39;t it unlikely that the cod=
e dormant in c would have suitable catch clauses for throws in an unrelated=
 function fun.</div><div><br></div><div>Ok, maybe you only see this as a me=
thod of throwing an exception in the other stack, if so maybe it would be b=
etter to have an explicit mechanism for this:</div><div><br></div><div>temp=
late&lt;typename EX, typename.... Args&gt; continuation::throw_in(Args...);=
</div><div><br></div><div>This just swaps the stacks and then executes `thr=
ow EX(args...)`</div><div><br></div><div>The advantage of this approach is =
that it is obvious what it does and it does not invite to inject arbitrary =
function calls (which may throw exceptions without catching them) onto some=
 other stack not prepared for this.,</div><div><br></div><div>I would have =
thought that the main use would be to allow a pool of fibers to be used for=
 executing arbitrary code. The main reason for not doing new callcc() calls=
 each time would be to avoid having to allocate stacks each time. If this i=
s the use case it seems that the stack rather than the continuation is the =
object to preserve and pool. It may be that this is the functionality Nicol=
 was asking for.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" st=
yle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-lef=
t: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div></div><div>=
=C2=A0<br></div></div></div></div>
</blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/113327fb-b26a-421e-9b07-9a2045c4178f%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/113327fb-b26a-421e-9b07-9a2045c4178f=
%40isocpp.org</a>.<br />

------=_Part_1215_1050567901.1488654255896--

------=_Part_1214_2074571044.1488654255895--

.

--94eb2c1bcee8b8502c0549ede615
Content-Type: text/plain; charset=UTF-8

2017-03-04 20:04 GMT+01:00 Bengt Gustafsson <bengt.gustafsson@beamways.com>:

> I don't see your point - accessing a register if verry fast (1 CPU cycle I
>> guess).
>>
> The point is that if the feature does not have a large performance gain
> compared to not having it, and if it does not avoid a complex
> synchronization problem then why have it? I don't see that you have shown
> any major performance or synchronization gain.
>

I don't understand what you try to tell me


>
> The data transfer as proposed in P0534 (and used for coroutine and fiber
>> implementation) does provide some kind of type-safety and no overhead if no
>> data are transferred.
>>
> While ideas in the direction of my Generator class offers compile time
> type safety and negligable overhead even if used!
>

 generators provide asynchronous context switching which is always less
efficient than synchronous


> Not to mention a smaller API.
>

it's not


> - in foo you resume c2: c2()
>>
> ok, a bit odd but doable.
>

why is it odd?


>
> - in bar you jump to main()
>>
> Unless you involve setjmp/longjmp I don't see a way fot this to happen
>

callcc() does similiar things like setjmp/longjmp - actually callcc()
creates a new stack and a new context and exchanges stack and instruction
pointer


> What can happen is that foo gives bar access to its stored continuation
> and bar uses this to transfer control to main after its c1() call.
>

I don't get it

foo can not give its continuation to bar while foo is running
foo is supended by calling callcc() or continuation::operator() and the
invocation of this functions generate a continuation of foo


> And sure enough c1 now refers to bar after its second context switch. Yes
> this seems to be what you refer to.
>
>
>> - that means you return from c1() in main()
>> - if you call c1() in main() you do resume bar() instead of foo()
>>
> Yes. This can happen if you store the continuations in global variables
>

no, global vars are not needed


> Isn't this why we want to abstract the continuation level into higher
> level abstractions which are easier to understand and where these types of
> oddities are easy to avoid.
>

I would say no - higher level astractions defined how continuations interact



> The only gain with the assignment is as a reminder of "next time this
> continuation will continue executing somewhere else". But as that always
> happens and you can not make something else happen by NOT doing the
> assignment (except dropping a valuable asset) it seems rather error prone...
>

I don't get it


> no - resume the context and then, if you are in the resumed context,
>> create a new stack frame and execute your supplied function (that might
>> throw)
>>
> OK, I understand what it does, my question was why this is useful.
>

yes


> Yes, that is how I understood it. This is what would happen if you forget
> to assign the returned continuation to your variable, I assume ;-)
>

right


> So the only use case for invoke_on_top() that you have produced is in fact
> equivalent to destroying the continuation object.
>

no


> Given that you can't access data in underlying stack frames
>

you can pass data from the fucntion executed ontop of the context to the
underlying stack frame


> continuation c;
>
> fun()
> c()
>

fun() is executed on the current stack (and in the current context - lets
say main() for instance)

c() resumes c, e.g switches execution to the stack and context c is related
to

and
> c.invoke_on_top(fun);
>

resumes c and invokes fun on the stack c is related to == fun() is executed
in the context of c



> Well, there may be some difference if fun throws,
>

if fun() throws

fun()
c()
-> c() is not executed; exeception is thrown in the context of main() for
instance

c.invoke_on_top(fun);
-> exeception is thrown inside c and will terminate c if not catched

Ok, maybe you only see this as a method of throwing an exception in the
> other stack,
>

no

I would have thought that the main use would be to allow a pool of fibers
> to be used for executing arbitrary code.
>

you nixing up concepts - callcc() is not a fiber, but fibers can be
implemented using callcc() (see boost.fiber as an example)


> The main reason for not doing new callcc() calls each time would be to
> avoid having to allocate stacks each time.
>

callcc() is factory function of continuations, it generates a new stack and
context


> If this is the use case it seems that the stack rather than the
> continuation is the object to preserve and pool.
>

the stack is actually the continuation - if continuation::operator() is
called the stack pointer (stored inside continuation) is assigned to the
stack pointer and the instruction pointe ris poped from it

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2Bwfc1-oL6F%2B99T_ySpL%2BDjuARzSE5gSWkPqyZYGWAyhs%3DGOgw%40mail.gmail.com.

--94eb2c1bcee8b8502c0549ede615
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">2017=
-03-04 20:04 GMT+01:00 Bengt Gustafsson <span dir=3D"ltr">&lt;<a href=3D"ma=
ilto:bengt.gustafsson@beamways.com" target=3D"_blank">bengt.gustafsson@beam=
ways.com</a><wbr>&gt;</span>:<br><blockquote class=3D"gmail_quote" style=3D=
"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-le=
ft:1ex"><div dir=3D"ltr"><span class=3D"gmail-m_5014491845479166924gmail-">=
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div><di=
v class=3D"gmail_quote"><div></div><div>I don&#39;t see your point - access=
ing a register if verry fast (1 CPU cycle I guess).<br></div></div></div></=
div></blockquote></span><div>The point is that if the feature does not have=
 a large performance gain compared to not having it, and if it does not avo=
id a complex synchronization problem then why have it? I don&#39;t see that=
 you have shown any major performance or synchronization gain.</div></div><=
/blockquote><div><br></div><div>I don&#39;t understand what you try to tell=
 me<br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:=
1ex"><div dir=3D"ltr"><span class=3D"gmail-m_5014491845479166924gmail-"><di=
v><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
..8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"l=
tr"><div><div class=3D"gmail_quote"><div></div><div>The data transfer as pr=
oposed in P0534 (and used for coroutine and fiber implementation) does prov=
ide some kind of type-safety and no overhead if no data are transferred.</d=
iv></div></div></div></blockquote></span><div>While ideas in the direction =
of my Generator class offers compile time type safety and negligable overhe=
ad even if used!</div></div></blockquote><div><br><div></div>=C2=A0generato=
rs provide asynchronous context switching which is always less efficient th=
an synchronous<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:=
1ex"><div dir=3D"ltr"><div>Not to mention a smaller API.</div></div></block=
quote><div><br></div><div>it&#39;s not<br></div><div>=C2=A0</div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px s=
olid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><span class=3D"gma=
il-m_5014491845479166924gmail-"></span><span class=3D"gmail-m_5014491845479=
166924gmail-"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D=
"ltr"><div><div class=3D"gmail_quote"><div></div><div>- in foo you resume c=
2: c2()<br></div></div></div></div></blockquote></span><div>ok, a bit odd b=
ut doable.=C2=A0</div></div></blockquote><div><br></div><div>why is it odd?=
<br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margi=
n:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex=
"><div dir=3D"ltr"><br><span class=3D"gmail-m_5014491845479166924gmail-"><b=
lockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-le=
ft:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div><div =
class=3D"gmail_quote"><div></div><div>- in bar you jump to main()<br></div>=
</div></div></div></blockquote></span><div>Unless you involve setjmp/longjm=
p I don&#39;t see a way fot this to happen</div></div></blockquote><div><br=
></div><div>callcc() does similiar things like setjmp/longjmp - actually ca=
llcc() creates a new stack and a new context and exchanges stack and instru=
ction pointer<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1=
ex"><div dir=3D"ltr"><div>What can happen is that foo gives bar access to i=
ts stored continuation and bar uses this to transfer control to main after =
its c1() call.</div></div></blockquote><div><br></div><div>I don&#39;t get =
it<br><br>foo can not give its continuation to bar while foo is running <br=
></div><div>foo is supended by calling callcc() or continuation::operator()=
 and the invocation of this functions generate a continuation of foo<br></d=
iv><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div =
dir=3D"ltr"><div>And sure enough c1 now refers to bar after its second cont=
ext switch. Yes this seems to be what you refer to.</div><span class=3D"gma=
il-m_5014491845479166924gmail-"><div>=C2=A0</div><blockquote class=3D"gmail=
_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204=
,204);padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><d=
iv></div><div>- that means you return from c1() in main()<br></div><div>- i=
f you call c1() in main() you do resume bar() instead of foo()<br></div></d=
iv></div></div></blockquote></span><div>Yes. This can happen if you store t=
he continuations in global variables</div></div></blockquote><div><br></div=
><div>no, global vars are not needed<br></div><div>=C2=A0</div><blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px sol=
id rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>Isn&#39;t this =
why we want to abstract the continuation level into higher level abstractio=
ns which are easier to understand and where these types of</div><div>odditi=
es are easy to avoid.</div></div></blockquote><div><br></div><div>I would s=
ay no - higher level astractions defined how continuations interact<br><br>=
=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
..8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"l=
tr"><div></div><div>The only gain with the assignment is as a reminder of &=
quot;next time this continuation will continue executing somewhere else&quo=
t;. But as that always happens and you can not make something else happen b=
y NOT doing the assignment (except dropping a valuable asset) it seems rath=
er error prone...</div></div></blockquote><div><br></div><div>I don&#39;t g=
et it<br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-lef=
t:1ex"><div dir=3D"ltr"><span class=3D"gmail-m_5014491845479166924gmail-"><=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div><div=
 class=3D"gmail_quote"><div></div><div>no - resume the context and then, if=
 you are in the resumed context, create a new stack frame and execute your =
supplied function (that might throw) <br></div></div></div></div></blockquo=
te></span><div>OK, I understand what it does, my question was why this is u=
seful.=C2=A0</div></div></blockquote><div><br></div><div>yes<br></div><div>=
=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
..8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"l=
tr"><span class=3D"gmail-m_5014491845479166924gmail-"></span><div>Yes, that=
 is how I understood it. This is what would happen if you forget to assign =
the returned continuation to your variable, I assume ;-)</div></div></block=
quote><div><br></div><div>right<br></div><div>=C2=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div></div><div>So the on=
ly use case for invoke_on_top() that you have produced is in fact equivalen=
t to destroying the continuation object.</div></div></blockquote><div><br><=
/div><div>no<br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padd=
ing-left:1ex"><div dir=3D"ltr"><div> Given that you can&#39;t access data i=
n underlying stack frames </div></div></blockquote><div><br></div><div>you =
can pass data from the fucntion executed ontop of the context to the underl=
ying stack frame<br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote=
" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);=
padding-left:1ex"><div dir=3D"ltr">continuation c;<div><br></div><div>fun()=
</div><div>c()</div></div></blockquote><div><br></div><div>fun() is execute=
d on the current stack (and in the current context - lets say main() for in=
stance)<br></div><div>=C2=A0<br></div><div>c() resumes c, e.g switches exec=
ution to the stack and context c is related to<br></div><div><br></div><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left=
:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div></div><=
div>and</div><div>c.invoke_on_top(fun);</div></div></blockquote><div><br></=
div><div>resumes c and invokes fun on the stack c is related to =3D=3D fun(=
) is executed in the context of c<br></div><div><br>=C2=A0</div><blockquote=
 class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px so=
lid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div></div><div>Wel=
l, there may be some difference if fun throws,</div></div></blockquote><div=
><br></div><div>if fun() throws<br><br></div><div>fun()<br></div><div>c()<b=
r></div><div>-&gt; c() is not executed; exeception is thrown in the context=
 of main() for instance<br><br>c.invoke_on_top(fun);<br></div><div>-&gt; ex=
eception is thrown inside c and will terminate c if not catched<br></div><d=
iv><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px =
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"=
ltr"><div></div><div>Ok, maybe you only see this as a method of throwing an=
 exception in the other stack,</div></div></blockquote><div><br></div><div>=
no<br></div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margi=
n:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex=
"><div dir=3D"ltr"><div>I would have thought that the main use would be to =
allow a pool of fibers to be used for executing arbitrary code.</div></div>=
</blockquote><div><br></div><div>you nixing up concepts - callcc() is not a=
 fiber, but fibers can be implemented using callcc() (see boost.fiber as an=
 example)<br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex"><div dir=3D"ltr"><div> The main reason for not doing new callcc(=
) calls each time would be to avoid having to allocate stacks each time.</d=
iv></div></blockquote><div><br></div><div>callcc() is factory function of c=
ontinuations, it generates a new stack and context<br></div><div>=C2=A0</di=
v><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;borde=
r-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>I=
f this is the use case it seems that the stack rather than the continuation=
 is the object to preserve and pool.<br></div></div></blockquote><div><br><=
/div><div>the stack is actually the continuation - if continuation::operato=
r() is called the stack pointer (stored inside continuation) is assigned to=
 the stack pointer and the instruction pointe ris poped from it<br></div><d=
iv>=C2=A0</div></div><br></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CA%2Bwfc1-oL6F%2B99T_ySpL%2BDjuARzSE5=
gSWkPqyZYGWAyhs%3DGOgw%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfoo=
ter">https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CA%2Bwfc1=
-oL6F%2B99T_ySpL%2BDjuARzSE5gSWkPqyZYGWAyhs%3DGOgw%40mail.gmail.com</a>.<br=
 />

--94eb2c1bcee8b8502c0549ede615--

.

On Sat, Mar 4, 2017 at 7:04 PM, Bengt Gustafsson
<bengt.gustafsson@beamways.com> wrote:
>
> Den l=C3=B6rdag 4 mars 2017 kl. 17:14:18 UTC+1 skrev Oliver Kowalke:
>>
>> 2017-03-04 15:27 GMT+01:00 Bengt Gustafsson <bengt.gu...@beamways.com>:
>>>>
>>>>
>>>>> But I don't understand the need of data transfer at this low
>>>>> abstraction level. After all, these are not threads, so there is no
>>>>> asynchronism to think about.
>>>>
>>>>
>>>> P0534 is symmetric context switching, e.g. no coupling between caller
>>>> and callee as it is for generators/coroutines.
>>>
>>> Exactly, that's why I asked why data transfer is needed _on the call/cc
>>> level_. I showed in my example that you can do data transfer on top of =
this
>>> (at the generator level) with essentially no overhead. Giovanni pointed=
 out
>>> that there may be the overhead of one register save/restore, and if thi=
s the
>>> performance gain you are after I think the price of a scary "void*" sty=
le
>>> interface (hidden behind an unsafe cast) is not worth it, and if the ac=
cess
>>> is to be tested the performance cost is definitely more than a register
>>> save.
>>
>>
>> I don't see your point - accessing a register if verry fast (1 CPU cycle=
 I
>> guess).
>
> The point is that if the feature does not have a large performance gain
> compared to not having it, and if it does not avoid a complex
> synchronization problem then why have it? I don't see that you have shown
> any major performance or synchronization gain.
>

I haven't seen Oliver's implementation, but the feature can be
implemented with negative cost (as I mentioned elsethread): you simply
skip saving and restoring a register and use it to pass a pointer
though.

Implementing the same feature non intrusively is more expensive as you
need to go through memory and require coordination between the threads
of execution (i.e. sharing some memory cell), which might be non
trivial when the

There is a strong parallel between a function call and a continuation
invocation [1]. They both are a controlled jump to another memory
location, possibly while passing parameters though, and a program will
benefit by both being as fast as possible when inlining is not
desirable or possible.

[1] given a simple program transformation they are in fact exactly the
same thing.

[...]
>>
>> throwing an exeception was only one use case - infact if a suspended
>> continuation has to be destroyed (instance goes out of scope) out of a d=
eep
>> callstack - the current implementation executes a function ontop of thos=
e
>> continuation that throws a speciall exception that unwinds the stakc of =
the
>> continuation and jumps back to the caller.
>
> Yes, that is how I understood it. This is what would happen if you forget=
 to
> assign the returned continuation to your variable, I assume ;-)
>
> So the only use case for invoke_on_top() that you have produced is in fac=
t
> equivalent to destroying the continuation object.

The killer application is of course is implement waiting of events.
For example, waiting on an std::future:

     template<class T>
     T await(std::future<T> f, continuation& yield) {
           yield =3D yield(invoke_on_top, [&](auto&& c) { f =3D
f.then([c=3Dmove(c)] (auto f){ c(); return f.get(); }); return
continuation{} });
           return f.get();
      }

With invoke on top, waiting is trivial; without it is a pain to
implement; witness the epicycles that the other coroutine proposal
needs to make this work. Await doesn't require neither explicit
support from continuation nor std::future to work [2].

Other uses:

* implementing a (transparent) task scheduling system on top of
continuations: pop 'next' from ready queue, invoke-on-top of 'next'
and push captured 'previous' on back of queue. Return into 'next'.


* with typed continuations, it allows capturing the thread of control
with a different continuation type.

* continuation splicing:
   switch from thread of control 'a' to 'b', but return to 'b' a
separate thread of control 'c' instead of 'a'. This can be used to
implement complex control flow.

In general, invoke-on-top is useful in any case in which the current
flow of control need to capture its own continuation without spawning
a new flow of control. It is the well behaved equivalent of
getcontext+setcontext (as opposed to swapcontext), except that the
code in between is executed on a separate stack (which has implication
for exceptions and concurrency).

invoke_on_top can of course be implemented on top of an implementation
without it, especially if a parameter passing feature is available,
but it requires cooperation of the target continuation and it is less
efficient. Considering that an implementation will need something like
it anyway to implement setup, exception forwarding and termination, it
makes sense to expose it to the user.

[2] Having a non-allocating, dismissable, variant of 'then' would be
better, but that's another story.
-- gpd

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAL52AatqZFxTrTTxGbhQHsr2F7F56DpBhzpsU6caOxa0KSH=
%3Dbw%40mail.gmail.com.

.

------=_Part_1180_1700985829.1488669191181
Content-Type: multipart/alternative;
 boundary="----=_Part_1181_1260541816.1488669191182"

------=_Part_1181_1260541816.1488669191182
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Note: Giovanni's reply popped up while I was typing. There may be some more=
=20
good argumentation there...


Den l=C3=B6rdag 4 mars 2017 kl. 21:56:53 UTC+1 skrev Oliver Kowalke:
>
> 2017-03-04 20:04 GMT+01:00 Bengt Gustafsson <bengt.gu...@beamways.com=20
> <javascript:>>:
>
>> I don't see your point - accessing a register if verry fast (1 CPU cycle=
=20
>>> I guess).
>>>
>> The point is that if the feature does not have a large performance gain=
=20
>> compared to not having it, and if it does not avoid a complex=20
>> synchronization problem then why have it? I don't see that you have show=
n=20
>> any major performance or synchronization gain.
>>
>
> I don't understand what you try to tell me
>
=20
That mixing in the data passing into the continuation class is not a good=
=20
idea. I have asked you to come up with an explanation why it would be a=20
good idea, "because we can" is not good enough as this data can easily be=
=20
passed without any support from the continuation class.


=20

> =20
>
>>
>> The data transfer as proposed in P0534 (and used for coroutine and fiber=
=20
>>> implementation) does provide some kind of type-safety and no overhead i=
f no=20
>>> data are transferred.
>>>
>> While ideas in the direction of my Generator class offers compile time=
=20
>> type safety and negligable overhead even if used!
>>
>
>  generators provide asynchronous context switching which is always less=
=20
> efficient than synchronous
>

I am talking about the generators according to my continuation based class.
=20

> =20
>
>> Not to mention a smaller API.
>>
>
> it's not
>
How can not having a get method not be a smaller API?

=20

> =20
>
>> - in foo you resume c2: c2()
>>>
>> ok, a bit odd but doable.=20
>>
>
> why is it odd?
>
=20
I just ment that it doesn't follow any of the usual patterns that=20
continuations are used for: generators, data flow machines, fiber pools.
=20

> =20
>
>>
>> - in bar you jump to main()
>>>
>> Unless you involve setjmp/longjmp I don't see a way fot this to happen
>>
>
> callcc() does similiar things like setjmp/longjmp - actually callcc()=20
> creates a new stack and a new context and exchanges stack and instruction=
=20
> pointer
> =20
>
>> What can happen is that foo gives bar access to its stored continuation=
=20
>> and bar uses this to transfer control to main after its c1() call.
>>
>
> I don't get it
>
I could have messed up but I tried to follow the order of events you=20
described and came to the conclusion that foo got the context returned to=
=20
it from its first continuation invokation, so for bar to invoke it it must=
=20
have access to the variable where foo stored it.
=20

>
> foo can not give its continuation to bar while foo is running=20
>
"Its continuation" is the one it got returned from its invokation, of=20
course it can store it somewhere for bar to get.
=20

> foo is supended by calling callcc() or continuation::operator() and the=
=20
> invocation of this functions generate a continuation of foo
> =20
>
>> And sure enough c1 now refers to bar after its second context switch. Ye=
s=20
>> this seems to be what you refer to.
>> =20
>>
>>> - that means you return from c1() in main()
>>> - if you call c1() in main() you do resume bar() instead of foo()
>>>
>> Yes. This can happen if you store the continuations in global variables
>>
>
> no, global vars are not needed
>
ok, could be members then.
=20

> =20
>
>> Isn't this why we want to abstract the continuation level into higher=20
>> level abstractions which are easier to understand and where these types =
of
>> oddities are easy to avoid.
>>
>
> I would say no - higher level astractions defined how continuations=20
> interact
>
well maybe, but the application code using those abstractions don't see the=
=20
continuations, well whatever.
=20

>
> =20
>
>> The only gain with the assignment is as a reminder of "next time this=20
>> continuation will continue executing somewhere else". But as that always=
=20
>> happens and you can not make something else happen by NOT doing the=20
>> assignment (except dropping a valuable asset) it seems rather error pron=
e...
>>
>
> I don't get it
>
If you do myContinuation() instead of myContinuation =3D myContinuation() t=
he=20
other stack is unwound when the temporary object is destroyed, no error=20
message at compile time or runtime, that's what I call error prone.
=20

> =20
>
>> no - resume the context and then, if you are in the resumed context,=20
>>> create a new stack frame and execute your supplied function (that might=
=20
>>> throw)=20
>>>
>> OK, I understand what it does, my question was why this is useful.=20
>>
>
> yes
>
yes?=20

> =20
>
>> Yes, that is how I understood it. This is what would happen if you forge=
t=20
>> to assign the returned continuation to your variable, I assume ;-)
>>
>
> right
> =20
>
>> So the only use case for invoke_on_top() that you have produced is in=20
>> fact equivalent to destroying the continuation object.
>>
>
> no
>
what other use case have you produced, I can't find any...
=20

> =20
>
>> Given that you can't access data in underlying stack frames=20
>>
>
> you can pass data from the fucntion executed ontop of the context to the=
=20
> underlying stack frame
>

How?

The last piece of code that ran in the underlying stack frame was the=20
continuation invokation. This returns the other continuation, as far as=20
that code knows. Now you insert a function "on top", which I assume must=20
return a continuation to fulfil the obligation of the unsuspecting code=20
that invoked the continuation. The only way to not have to return a=20
continuation there would be to throw. Well of course this would be a=20
possible way to pass data to the invoker, like this:

try {
    myContinuation();    // This will throw
}catch (SomeData& data);
// Use data here.

and then the other side injects a function throwing a SomeData instance.=20
Apart from the questions about life time of the thrown object this seems=20
incredibly clumsy, which is a reason why I asked for concrete use case=20
apart from throwing.


=20

> =20
>
>> continuation c;
>>
>> fun()
>> c()
>>
>
> fun() is executed on the current stack (and in the current context - lets=
=20
> say main() for instance)
> =20
> c() resumes c, e.g switches execution to the stack and context c is=20
> related to
>
> and
>> c.invoke_on_top(fun);
>>
>
> resumes c and invokes fun on the stack c is related to =3D=3D fun() is=20
> executed in the context of c
>
Yes, but all visible effects except the addresses of local variables in=20
fun() would be the same.=20

>
> =20
>
>> Well, there may be some difference if fun throws,
>>
>
> if fun() throws
>
> fun()
> c()
> -> c() is not executed; exeception is thrown in the context of main() for=
=20
> instance
>
> c.invoke_on_top(fun);
> -> exeception is thrown inside c and will terminate c if not catched
>
> Ok, maybe you only see this as a method of throwing an exception in the=
=20
>> other stack,
>>
>
> no
>
Still the example only revolves around throwing and where the unwinding of=
=20
that exception continues.
=20

>
> I would have thought that the main use would be to allow a pool of fibers=
=20
>> to be used for executing arbitrary code.
>>
>
> you nixing up concepts - callcc() is not a fiber, but fibers can be=20
> implemented using callcc() (see boost.fiber as an example)
>

No I'm not, I was refering to callcc() calling a function containing only a=
=20
loop with a yeild, and then executing fibers on that stack using=20
invoke_on_top.
=20

> =20
>
>> The main reason for not doing new callcc() calls each time would be to=
=20
>> avoid having to allocate stacks each time.
>>
>
> callcc() is factory function of continuations, it generates a new stack=
=20
> and context
>

exactly, so to avoid having to allocate new stacks you would have to avoid=
=20
repeated calls to callcc(), but with invoke_on_top you can inject any code=
=20
for execution in that stack. However, the same effect can be achieved using=
=20
a std::function object that said loop executes between each continuation=20
call:

std::function<void()> work;
void fiber_caller(continuation cont)
{
    for(;;) {
       cont();
       work();
    }
}

To use it just set work to a function and invoke the continuation returned=
=20
from callcc. Same stack, much work.
       =20

=20
>
>> If this is the use case it seems that the stack rather than the=20
>> continuation is the object to preserve and pool.
>>
>
> the stack is actually the continuation - if continuation::operator() is=
=20
> called the stack pointer (stored inside continuation) is assigned to the=
=20
> stack pointer and the instruction pointe ris poped from it
>
Sure, viewing the continuation as the stack I think is a good way to gain=
=20
understanding. Then moving it around makes even less sense to me.

Giovanni's reply popped up while I was typing. There may be some more good=
=20
argumentation there...
=20

> =20
>
>

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/5d4dd1d4-8f8e-44ff-bdb5-4d4bd8f532f8%40isocpp.or=
g.

------=_Part_1181_1260541816.1488669191182
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Note: Giovanni&#39;s reply popped up while I was typing. T=
here may be some more good argumentation there...<div><br><br>Den l=C3=B6rd=
ag 4 mars 2017 kl. 21:56:53 UTC+1 skrev Oliver Kowalke:<blockquote class=3D=
"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc s=
olid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote">2=
017-03-04 20:04 GMT+01:00 Bengt Gustafsson <span dir=3D"ltr">&lt;<a href=3D=
"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"GXsRJ9CwCgAJ" rel=
=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;=
" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;">bengt.gu...@be=
amways.com</a><wbr>&gt;</span>:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex"><div dir=3D"ltr"><span><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div></div><div=
>I don&#39;t see your point - accessing a register if verry fast (1 CPU cyc=
le I guess).<br></div></div></div></div></blockquote></span><div>The point =
is that if the feature does not have a large performance gain compared to n=
ot having it, and if it does not avoid a complex synchronization problem th=
en why have it? I don&#39;t see that you have shown any major performance o=
r synchronization gain.</div></div></blockquote><div><br></div><div>I don&#=
39;t understand what you try to tell me<br></div></div></div></div></blockq=
uote><div>=C2=A0</div><div>That mixing in the data passing into the continu=
ation class is not a good idea. I have asked you to come up with an explana=
tion why it would be a good idea, &quot;because we can&quot; is not good en=
ough as this data can easily be passed without any support from the continu=
ation class.</div><div><br></div><div><br></div><div>=C2=A0</div><blockquot=
e class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: =
1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmai=
l_quote"><div></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddin=
g-left:1ex"><div dir=3D"ltr"><span><div><br></div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,20=
4,204);padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><=
div></div><div>The data transfer as proposed in P0534 (and used for corouti=
ne and fiber implementation) does provide some kind of type-safety and no o=
verhead if no data are transferred.</div></div></div></div></blockquote></s=
pan><div>While ideas in the direction of my Generator class offers compile =
time type safety and negligable overhead even if used!</div></div></blockqu=
ote><div><br><div></div>=C2=A0generators provide asynchronous context switc=
hing which is always less efficient than synchronous<br></div></div></div><=
/div></blockquote><div><br></div><div>I am talking about the generators acc=
ording to my continuation based class.</div><div>=C2=A0</div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px =
#ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_qu=
ote"><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px=
 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><di=
v dir=3D"ltr"><div>Not to mention a smaller API.</div></div></blockquote><d=
iv><br></div><div>it&#39;s not<br></div></div></div></div></blockquote><div=
>How can not having a get method not be a smaller API?</div><div><br></div>=
<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><div><div class=3D"gmail_quote"><div></div><div>=C2=A0</div><blockquote=
 class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px so=
lid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><span></span><span>=
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div><di=
v class=3D"gmail_quote"><div></div><div>- in foo you resume c2: c2()<br></d=
iv></div></div></div></blockquote></span><div>ok, a bit odd but doable.=C2=
=A0</div></div></blockquote><div><br></div><div>why is it odd?<br></div></d=
iv></div></div></blockquote><div>=C2=A0</div><div>I just ment that it doesn=
&#39;t follow any of the usual patterns that continuations are used for: ge=
nerators, data flow machines, fiber pools.</div><div>=C2=A0</div><blockquot=
e class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: =
1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmai=
l_quote"><div></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddin=
g-left:1ex"><div dir=3D"ltr"><br><span><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padd=
ing-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div></div><=
div>- in bar you jump to main()<br></div></div></div></div></blockquote></s=
pan><div>Unless you involve setjmp/longjmp I don&#39;t see a way fot this t=
o happen</div></div></blockquote><div><br></div><div>callcc() does similiar=
 things like setjmp/longjmp - actually callcc() creates a new stack and a n=
ew context and exchanges stack and instruction pointer<br>=C2=A0</div><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:=
1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>What can=
 happen is that foo gives bar access to its stored continuation and bar use=
s this to transfer control to main after its c1() call.</div></div></blockq=
uote><div><br></div><div>I don&#39;t get it<br></div></div></div></div></bl=
ockquote><div>I could have messed up but I tried to follow the order of eve=
nts you described and came to the conclusion that foo got the context retur=
ned to it from its first continuation invokation, so for bar to invoke it i=
t must have access to the variable where foo stored it.</div><div>=C2=A0</d=
iv><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;=
border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div =
class=3D"gmail_quote"><div><br>foo can not give its continuation to bar whi=
le foo is running <br></div></div></div></div></blockquote><div>&quot;Its c=
ontinuation&quot; is the one it got returned from its invokation, of course=
 it can store it somewhere for bar to get.</div><div>=C2=A0</div><blockquot=
e class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: =
1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmai=
l_quote"><div></div><div>foo is supended by calling callcc() or continuatio=
n::operator() and the invocation of this functions generate a continuation =
of foo<br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D=
"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-le=
ft:1ex"><div dir=3D"ltr"><div>And sure enough c1 now refers to bar after it=
s second context switch. Yes this seems to be what you refer to.</div><span=
><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px=
 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div di=
r=3D"ltr"><div><div class=3D"gmail_quote"><div></div><div>- that means you =
return from c1() in main()<br></div><div>- if you call c1() in main() you d=
o resume bar() instead of foo()<br></div></div></div></div></blockquote></s=
pan><div>Yes. This can happen if you store the continuations in global vari=
ables</div></div></blockquote><div><br></div><div>no, global vars are not n=
eeded<br></div></div></div></div></blockquote><div>ok, could be members the=
n.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:=
 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div =
dir=3D"ltr"><div><div class=3D"gmail_quote"><div></div><div>=C2=A0</div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-lef=
t:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>Isn&#3=
9;t this why we want to abstract the continuation level into higher level a=
bstractions which are easier to understand and where these types of</div><d=
iv>oddities are easy to avoid.</div></div></blockquote><div><br></div><div>=
I would say no - higher level astractions defined how continuations interac=
t<br></div></div></div></div></blockquote><div>well maybe, but the applicat=
ion code using those abstractions don&#39;t see the continuations, well wha=
tever.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"mar=
gin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><=
div dir=3D"ltr"><div><div class=3D"gmail_quote"><div><br>=C2=A0</div><block=
quote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1=
px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div></div><di=
v>The only gain with the assignment is as a reminder of &quot;next time thi=
s continuation will continue executing somewhere else&quot;. But as that al=
ways happens and you can not make something else happen by NOT doing the as=
signment (except dropping a valuable asset) it seems rather error prone...<=
/div></div></blockquote><div><br></div><div>I don&#39;t get it<br></div></d=
iv></div></div></blockquote><div>If you do myContinuation() instead of myCo=
ntinuation =3D myContinuation() the other stack is unwound when the tempora=
ry object is destroyed, no error message at compile time or runtime, that&#=
39;s what I call error prone.</div><div>=C2=A0</div><blockquote class=3D"gm=
ail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc soli=
d;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div=
></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0=
px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><=
div dir=3D"ltr"><span><blockquote class=3D"gmail_quote" style=3D"margin:0px=
 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><di=
v dir=3D"ltr"><div><div class=3D"gmail_quote"><div></div><div>no - resume t=
he context and then, if you are in the resumed context, create a new stack =
frame and execute your supplied function (that might throw) <br></div></div=
></div></div></blockquote></span><div>OK, I understand what it does, my que=
stion was why this is useful.=C2=A0</div></div></blockquote><div><br></div>=
<div>yes<br></div></div></div></div></blockquote><div>yes?=C2=A0</div><bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-l=
eft: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D=
"gmail_quote"><div></div><div>=C2=A0</div><blockquote class=3D"gmail_quote"=
 style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);p=
adding-left:1ex"><div dir=3D"ltr"><span></span><div>Yes, that is how I unde=
rstood it. This is what would happen if you forget to assign the returned c=
ontinuation to your variable, I assume ;-)</div></div></blockquote><div><br=
></div><div>right<br></div><div>=C2=A0</div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204)=
;padding-left:1ex"><div dir=3D"ltr"><div></div><div>So the only use case fo=
r invoke_on_top() that you have produced is in fact equivalent to destroyin=
g the continuation object.</div></div></blockquote><div><br></div><div>no<b=
r></div></div></div></div></blockquote><div>what other use case have you pr=
oduced, I can&#39;t find any...</div><div>=C2=A0</div><blockquote class=3D"=
gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc so=
lid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><d=
iv></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin=
:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"=
><div dir=3D"ltr"><div> Given that you can&#39;t access data in underlying =
stack frames </div></div></blockquote><div><br></div><div>you can pass data=
 from the fucntion executed ontop of the context to the underlying stack fr=
ame<br></div></div></div></div></blockquote><div><br></div><div>How?</div><=
div><br></div><div>The last piece of code that ran in the underlying stack =
frame was the continuation invokation. This returns the other continuation,=
 as far as that code knows. Now you insert a function &quot;on top&quot;, w=
hich I assume must return a continuation to fulfil the obligation of the un=
suspecting code that invoked the continuation. The only way to not have to =
return a continuation there would be to throw. Well of course this would be=
 a possible way to pass data to the invoker, like this:</div><div><br></div=
><div>try {</div><div>=C2=A0 =C2=A0 myContinuation(); =C2=A0 =C2=A0// This =
will throw</div><div>}catch (SomeData&amp; data);</div><div>// Use data her=
e.</div><div><br></div><div>and then the other side injects a function thro=
wing a SomeData instance. Apart from the questions about life time of the t=
hrown object this seems incredibly clumsy, which is a reason why I asked fo=
r concrete use case apart from throwing.</div><div><br></div><div><br></div=
><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"=
ltr"><div><div class=3D"gmail_quote"><div></div><div>=C2=A0</div><blockquot=
e class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px s=
olid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">continuation c;<di=
v><br></div><div>fun()</div><div>c()</div></div></blockquote><div><br></div=
><div>fun() is executed on the current stack (and in the current context - =
lets say main() for instance)<br></div><div>=C2=A0<br></div><div>c() resume=
s c, e.g switches execution to the stack and context c is related to<br></d=
iv><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px=
 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div di=
r=3D"ltr"><div></div><div>and</div><div>c.invoke_on_top(fun);</div></div></=
blockquote><div><br></div><div>resumes c and invokes fun on the stack c is =
related to =3D=3D fun() is executed in the context of c<br></div></div></di=
v></div></blockquote><div>Yes, but all visible effects except the addresses=
 of local variables in fun() would be the same.=C2=A0</div><blockquote clas=
s=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #c=
cc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quot=
e"><div></div><div><br>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex"><div dir=3D"ltr"><div></div><div>Well, there may be some differe=
nce if fun throws,</div></div></blockquote><div><br></div><div>if fun() thr=
ows<br><br></div><div>fun()<br></div><div>c()<br></div><div>-&gt; c() is no=
t executed; exeception is thrown in the context of main() for instance<br><=
br>c.invoke_on_top(fun);<br></div><div>-&gt; exeception is thrown inside c =
and will terminate c if not catched<br></div><div><br></div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid =
rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div></div><div>Ok, may=
be you only see this as a method of throwing an exception in the other stac=
k,</div></div></blockquote><div><br></div><div>no<br></div></div></div></di=
v></blockquote><div>Still the example only revolves around throwing and whe=
re the unwinding of that exception continues.</div><div>=C2=A0</div><blockq=
uote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-lef=
t: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"g=
mail_quote"><div></div><div><br></div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddi=
ng-left:1ex"><div dir=3D"ltr"><div>I would have thought that the main use w=
ould be to allow a pool of fibers to be used for executing arbitrary code.<=
/div></div></blockquote><div><br></div><div>you nixing up concepts - callcc=
() is not a fiber, but fibers can be implemented using callcc() (see boost.=
fiber as an example)<br></div></div></div></div></blockquote><div><br></div=
><div>No I&#39;m not, I was refering to callcc() calling a function contain=
ing only a loop with a yeild, and then executing fibers on that stack using=
 invoke_on_top.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" sty=
le=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left=
: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div></div><div>=
=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
..8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"l=
tr"><div> The main reason for not doing new callcc() calls each time would =
be to avoid having to allocate stacks each time.</div></div></blockquote><d=
iv><br></div><div>callcc() is factory function of continuations, it generat=
es a new stack and context<br></div></div></div></div></blockquote><div><br=
></div><div>exactly, so to avoid having to allocate new stacks you would ha=
ve to avoid repeated calls to callcc(), but with invoke_on_top you can inje=
ct any code for execution in that stack. However, the same effect can be ac=
hieved using a std::function object that said loop executes between each co=
ntinuation call:</div><div><br></div><div>std::function&lt;void()&gt; work;=
</div><div>void fiber_caller(continuation cont)</div><div>{</div><div>=C2=
=A0 =C2=A0 for(;;) {</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0cont();</div><div=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0work();</div><div>=C2=A0 =C2=A0 }</div><div>}</=
div><div><br></div><div>To use it just set work to a function and invoke th=
e continuation returned from callcc. Same stack, much work.</div><div>=C2=
=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0</div><div><br></div><blockquote class=3D"gma=
il_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid=
;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div>=
</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><d=
iv dir=3D"ltr"><div>If this is the use case it seems that the stack rather =
than the continuation is the object to preserve and pool.<br></div></div></=
blockquote><div><br></div><div>the stack is actually the continuation - if =
continuation::operator() is called the stack pointer (stored inside continu=
ation) is assigned to the stack pointer and the instruction pointe ris pope=
d from it<br></div></div></div></div></blockquote><div>Sure, viewing the co=
ntinuation as the stack I think is a good way to gain understanding. Then m=
oving it around makes even less sense to me.</div><div><br></div><div>Giova=
nni&#39;s reply popped up while I was typing. There may be some more good a=
rgumentation there...</div><div>=C2=A0</div><blockquote class=3D"gmail_quot=
e" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddin=
g-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div></div><=
div>=C2=A0</div></div><br></div></div>
</blockquote></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/5d4dd1d4-8f8e-44ff-bdb5-4d4bd8f532f8%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5d4dd1d4-8f8e-44ff-bdb5-4d4bd8f532f8=
%40isocpp.org</a>.<br />

------=_Part_1181_1260541816.1488669191182--

------=_Part_1180_1700985829.1488669191181--

.

--Apple-Mail=_C43991DF-3C34-484D-8B0F-F584F6836B5F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8

> On Mar 3, 2017, at 7:36 AM, Bengt Gustafsson <bengt.gustafsson@beamways.c=
om> wrote:
> I don't know what you mean by trampoline in this context. I checked wikip=
edia link but I didn't get it...
>=20
> =E2=80=A6

     Yeah, sorry, that article=E2=80=99s not as descriptive as one would ho=
pe, is it?  Maybe this StackOverflow question <http://stackoverflow.com/que=
stions/189725/what-is-a-trampoline-function> will help you understand what =
I was trying to convey, or perhaps I was just confusing the idea of a tramp=
oline with the similar concepts of thunks <https://en.wikipedia.org/wiki/Th=
unk> and/or shims <https://en.wikipedia.org/wiki/Shim_(computing)>.  The ex=
ample I usually tend to think of is the Objective-C run-time library=E2=80=
=99s `objc_msgSend()` function (which I=E2=80=99ve found <https://www.googl=
e.com/search?client=3Dsafari&rls=3Den&q=3DIs+objc_msgSend()+a+trampoline?&i=
e=3DUTF-8&oe=3DUTF-8> is referred to as a trampoline) due to my rudimentary=
 familiarity with Apple platforms, but I=E2=80=99m not sure how helpful tha=
t might be to you=E2=80=A6

> =E2=80=A6
>=20
> This aside, do you see a reason for this being a tag type and operator() =
rather than a method call?
>=20
> =E2=80=A6


Honestly, I don=E2=80=99t have enough of an opinion on or enough stake in t=
his argument to care all that much either way.  I just see continuations as=
 an interesting construct that I might use some time in the future. =20

> =E2=80=A6
>=20
> I thought about this more and it seems that it may have to do with implem=
enting a fiber pool. The invoked function is the body of the next fiber to =
execute on the stack of the continuation and the target of the ccllcc is ju=
st a function like this:
>=20
> void fiber_base(continuation&& cont, bool& stop)
> {
>    continuation c =3D std::move(cont);
>    while (!stop)
>        c =3D c();
> }
>=20
> then the party starting the fiber_base with callcc can invoke anything on=
 this stack and when this anything returns the loop goes back to wait for t=
he next task.
>=20
> This idea is just speculation on my part, but it seems to show a use case=
 (unless the stack itself is made a first class object which can be reused =
for multiple callcc calls which I would find more logical).=20
>=20
> =E2=80=A6


That=E2=80=99s another way of looking at it, I suppose=E2=80=A6

=E2=80=94=E2=80=89Bryce Glover
=E3=80=80=E2=80=89RandomDSdevel@gmail.com

> =E2=80=A6
>=20
> Den 2017-03-02 kl. 23:21, skrev Bryce Glover:
>> (snipped=E2=80=A6)
> --=20
> Bengt Gustafsson
> CEO, Beamways AB
> Westmansgatan 37
> 582 16 Link=C3=B6ping, Sweden
> +46 (705) 338259
> Skype: benke_g
> www.beamways.com <http://www.beamways.com/>

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/2EDD5373-2876-4B4C-9B68-DFA855DE4007%40gmail.com=
..

--Apple-Mail=_C43991DF-3C34-484D-8B0F-F584F6836B5F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dutf-8"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode: s=
pace; -webkit-line-break: after-white-space;" class=3D""><div><blockquote t=
ype=3D"cite" class=3D""><div class=3D"">On Mar 3, 2017, at 7:36 AM, Bengt G=
ustafsson &lt;<a href=3D"mailto:bengt.gustafsson@beamways.com" class=3D"">b=
engt.gustafsson@beamways.com</a>&gt; wrote:</div><div class=3D"">
 =20
    <meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
" class=3D"">
 =20
  <div bgcolor=3D"#FFFFFF" text=3D"#000000" class=3D""><p class=3D"">I don'=
t know what you mean by trampoline in this context. I
      checked wikipedia link but I didn't get it...</p><div class=3D"">=E2=
=80=A6</div></div></div></blockquote><div><br class=3D""></div><div>&nbsp; =
&nbsp; &nbsp;Yeah, sorry, that article=E2=80=99s not as descriptive as one =
would hope, is it? &nbsp;Maybe&nbsp;<a href=3D"http://stackoverflow.com/que=
stions/189725/what-is-a-trampoline-function" class=3D"">this StackOverflow =
question</a>&nbsp;will help you understand what I was trying to convey, or =
perhaps I was just confusing the idea of a trampoline with the similar conc=
epts of&nbsp;<a href=3D"https://en.wikipedia.org/wiki/Thunk" class=3D"">thu=
nks</a>&nbsp;and/or&nbsp;<a href=3D"https://en.wikipedia.org/wiki/Shim_(com=
puting)" class=3D"">shims</a>. &nbsp;The example I usually tend to think of=
 is the Objective-C run-time library=E2=80=99s `objc_msgSend()` function (w=
hich I=E2=80=99ve&nbsp;<a href=3D"https://www.google.com/search?client=3Dsa=
fari&amp;rls=3Den&amp;q=3DIs+objc_msgSend()+a+trampoline?&amp;ie=3DUTF-8&am=
p;oe=3DUTF-8" class=3D"">found</a>&nbsp;is referred to as a trampoline) due=
 to my rudimentary familiarity with Apple platforms, but I=E2=80=99m not su=
re how helpful that might be to you=E2=80=A6</div><div><br class=3D""></div=
><blockquote type=3D"cite" class=3D"">=E2=80=A6</blockquote><blockquote typ=
e=3D"cite" class=3D""><br class=3D""></blockquote><blockquote type=3D"cite"=
 class=3D"">This aside, do you see a reason for this being a tag type and
      operator() rather than a method call?</blockquote><div><blockquote ty=
pe=3D"cite" class=3D""><br class=3D""></blockquote><blockquote type=3D"cite=
" class=3D"">=E2=80=A6</blockquote></div><div><br class=3D""></div><div>Hon=
estly, I don=E2=80=99t have enough of an opinion on or enough stake in this=
 argument to care all that much either way. &nbsp;I just see continuations =
as an interesting construct that I might use some time in the future. &nbsp=
;</div><div><br class=3D""></div><blockquote type=3D"cite" class=3D"">=E2=
=80=A6</blockquote><blockquote type=3D"cite" class=3D""><br class=3D""></bl=
ockquote><blockquote type=3D"cite" class=3D"">I thought about this more and=
 it seems that it may have to do
      with implementing a fiber pool. The invoked function is the body
      of the next fiber to execute on the stack of the continuation and
      the target of the ccllcc is just a function like this:</blockquote><b=
lockquote type=3D"cite" class=3D""><br class=3D""></blockquote><blockquote =
type=3D"cite" class=3D"">void fiber_base(continuation&amp;&amp; cont, bool&=
amp; stop)</blockquote><blockquote type=3D"cite" class=3D"">{</blockquote><=
blockquote type=3D"cite" class=3D""> &nbsp; &nbsp;continuation c =3D std::m=
ove(cont);</blockquote><blockquote type=3D"cite" class=3D""> &nbsp; &nbsp;w=
hile (!stop)</blockquote><blockquote type=3D"cite" class=3D""> &nbsp; &nbsp=
; &nbsp; &nbsp;c =3D c();</blockquote><blockquote type=3D"cite" class=3D"">=
}</blockquote><blockquote type=3D"cite" class=3D""><br class=3D""></blockqu=
ote><blockquote type=3D"cite" class=3D"">then the party starting the fiber_=
base with callcc can invoke
      anything on this stack and when this anything returns the loop
      goes back to wait for the next task.</blockquote><blockquote type=3D"=
cite" class=3D""><br class=3D""></blockquote><blockquote type=3D"cite" clas=
s=3D"">This idea is just speculation on my part, but it seems to show a
      use case (unless the stack itself is made a first class object
      which can be reused for multiple callcc calls which I would find
      more logical).&nbsp;</blockquote><div><blockquote type=3D"cite" class=
=3D""><br class=3D""></blockquote><blockquote type=3D"cite" class=3D"">=E2=
=80=A6</blockquote></div><div><br class=3D""></div><div>That=E2=80=99s anot=
her way of looking at it, I suppose=E2=80=A6</div><div><br class=3D""></div=
><div><div class=3D"">=E2=80=94=E2=80=89Bryce Glover</div><div class=3D"">=
=E3=80=80=E2=80=89<a href=3D"mailto:RandomDSdevel@gmail.com" class=3D"">Ran=
domDSdevel@gmail.com</a></div></div><div><br class=3D""></div><blockquote t=
ype=3D"cite" class=3D"">=E2=80=A6</blockquote><blockquote type=3D"cite" cla=
ss=3D""><br class=3D""></blockquote><blockquote type=3D"cite" class=3D""><d=
iv bgcolor=3D"#FFFFFF" text=3D"#000000" class=3D"">
    <div class=3D"moz-cite-prefix">Den 2017-03-02 kl. 23:21, skrev Bryce
      Glover:<br class=3D"">
    </div>
    <blockquote cite=3D"mid:26EDCD88-C4FB-47F3-BF21-38D980966CA8@gmail.com"=
 type=3D"cite" class=3D""><font color=3D"#222222" face=3D"Arial, Helvetica,=
 sans-serif" size=3D"2" class=3D""><span style=3D"background-color: rgb(255=
, 255, 255);" class=3D"">(snipped=E2=80=A6)</span></font><div style=3D"marg=
in: 0px; padding: 0px; border: 0px; color: rgb(34,
        34, 34); font-family: Arial, Helvetica, sans-serif; font-size:
        13px;" class=3D"">
      </div>
    </blockquote>
    <pre class=3D"moz-signature" cols=3D"72">--=20
Bengt Gustafsson
CEO, Beamways AB
Westmansgatan 37
582 16 Link=C3=B6ping, Sweden
+46 (705) 338259
Skype: benke_g
<a class=3D"moz-txt-link-abbreviated" href=3D"http://www.beamways.com/">www=
..beamways.com</a></pre></div></blockquote></div></body></html>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/2EDD5373-2876-4B4C-9B68-DFA855DE4007%=
40gmail.com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/2EDD5373-2876-4B4C-9B68-DFA855DE4007%=
40gmail.com</a>.<br />

--Apple-Mail=_C43991DF-3C34-484D-8B0F-F584F6836B5F--

.