Topic: Proposal - "function_ref: a non-owning reference
Author: "T. C." <rs2740@gmail.com>
Date: Sat, 15 Jul 2017 16:20:54 -0700 (PDT)
Raw View
------=_Part_520_915087538.1500160855157
Content-Type: multipart/alternative;
boundary="----=_Part_521_621610997.1500160855157"
------=_Part_521_621610997.1500160855157
Content-Type: text/plain; charset="UTF-8"
Why have an empty state? We don't have null references.
Perfectly forwarding the callable shouldn't be done by default. A
function_ref should model a (named) reference and so should call the
referred callable as an lvalue.
Assignment from F&& should be constrained to at least reject function_ref;
preferably also reject non-invocable types so that is_assignable doesn't
lie.
"This function shall not participate in overload resolution unless " is a
Remarks:, not a Requires.
operator() should not use static_cast. It should use INVOKE<R> instead.
With "Effects: equivalent to: return..." you don't need a separate
"Returns:" clause.
Since you have both member and non-member swap, the usual practice is to
specify the latter in terms of the former. Why is it not noexcept?
There's a bunch of double colons after "Effects" etc.
--
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/dc089478-7462-4650-b252-9893b67d242b%40isocpp.org.
------=_Part_521_621610997.1500160855157
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Why have an empty state? We don't have null references=
..<div><br></div><div>Perfectly forwarding the callable shouldn't be don=
e by default. A function_ref should model a (named) reference and so should=
call the referred callable as an lvalue.=C2=A0<br></div><div><div><br></di=
v><div>Assignment from F&& should be constrained to at least reject=
function_ref; preferably also reject non-invocable types so that is_assign=
able doesn't lie.</div><div><br>"This function shall not participa=
te in overload resolution unless " is a Remarks:, not a Requires.</div=
><div><br></div><div>operator() should not use static_cast. It should use I=
NVOKE<R> instead. With "Effects: equivalent to: return..." =
you don't need a separate "Returns:" clause.</div><div><br></=
div><div>Since you have both member and non-member swap, the usual practice=
is to specify the latter in terms of the former. Why is it not noexcept?</=
div><div><br></div>There's a bunch of double colons after "Effects=
" =C2=A0etc.</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/dc089478-7462-4650-b252-9893b67d242b%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/dc089478-7462-4650-b252-9893b67d242b=
%40isocpp.org</a>.<br />
------=_Part_521_621610997.1500160855157--
------=_Part_520_915087538.1500160855157--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sat, 15 Jul 2017 16:54:45 -0700 (PDT)
Raw View
------=_Part_480_1991797926.1500162885565
Content-Type: multipart/alternative;
boundary="----=_Part_481_1214743532.1500162885565"
------=_Part_481_1214743532.1500162885565
Content-Type: text/plain; charset="UTF-8"
On Saturday, July 15, 2017 at 7:20:55 PM UTC-4, T. C. wrote:
>
> Why have an empty state? We don't have null references.
>
Because lots of C++ types have empty states. `any`, for example.
`string_view` being a reference example.
--
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/a1cea0da-23b7-42d1-8741-e8f03ab0db27%40isocpp.org.
------=_Part_481_1214743532.1500162885565
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Saturday, July 15, 2017 at 7:20:55 PM UTC-4, T. C. wrot=
e:<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">Why have an=
empty state? We don't have null references.</div></blockquote><div><br=
>Because lots of C++ types have empty states. `any`, for example. `string_v=
iew` being a reference example.</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/a1cea0da-23b7-42d1-8741-e8f03ab0db27%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/a1cea0da-23b7-42d1-8741-e8f03ab0db27=
%40isocpp.org</a>.<br />
------=_Part_481_1214743532.1500162885565--
------=_Part_480_1991797926.1500162885565--
.
Author: "T. C." <rs2740@gmail.com>
Date: Sat, 15 Jul 2017 17:08:49 -0700 (PDT)
Raw View
------=_Part_99_596016304.1500163729068
Content-Type: multipart/alternative;
boundary="----=_Part_100_608026460.1500163729068"
------=_Part_100_608026460.1500163729068
Content-Type: text/plain; charset="UTF-8"
On Saturday, July 15, 2017 at 7:54:45 PM UTC-4, Nicol Bolas wrote:
>
> On Saturday, July 15, 2017 at 7:20:55 PM UTC-4, T. C. wrote:
>>
>> Why have an empty state? We don't have null references.
>>
>
> Because lots of C++ types have empty states. `any`, for example.
> `string_view` being a reference example.
>
Yet `reference_wrapper` does not.
Having an empty state may or may not be the right choice, but I don't see
any discussion in the paper about this choice, which doubled the number of
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/25b8af82-55a3-462f-917e-4df11e5ccb62%40isocpp.org.
------=_Part_100_608026460.1500163729068
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Saturday, July 15, 2017 at 7:54:45 PM UTC-4, Ni=
col 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"lt=
r">On Saturday, July 15, 2017 at 7:20:55 PM UTC-4, T. C. 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">Why have an empty state? We do=
n't have null references.</div></blockquote><div><br>Because lots of C+=
+ types have empty states. `any`, for example. `string_view` being a refere=
nce example.</div></div></blockquote><div><br></div><div>Yet `reference_wra=
pper` does not.</div><div><br></div><div>Having an empty state may or may n=
ot be the right choice, but I don't see any discussion in the paper abo=
ut this choice, which doubled the number of functions.</div></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/25b8af82-55a3-462f-917e-4df11e5ccb62%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/25b8af82-55a3-462f-917e-4df11e5ccb62=
%40isocpp.org</a>.<br />
------=_Part_100_608026460.1500163729068--
------=_Part_99_596016304.1500163729068--
.
Author: Zhihao Yuan <zy@miator.net>
Date: Sun, 16 Jul 2017 02:51:44 -0500
Raw View
On Sat, Jul 15, 2017 at 11:25 AM, Vittorio Romeo
<vittorio.romeo.vee@gmail.com> wrote:
> Hello everyone - I'm looking for feedback on my "function_ref: a non-owning
> reference to a Callable" proposal. In short, this paper proposes the
> addition of something like `std::string_view` for functions, a lightweight
> type-erased reference vocabulary type that's especially useful when used as
> a function parameter.
Suggestions:
1. Remove everything related to nullptr; there
is no need to copy std::function's interface.
2. Perfect forward the source function's cv & ref
qualifiers; because the major use cases is not
to store a reference to the source function but
to take the function and immediately apply it,
therefore we should provide the perfect forward
behavior.
3. Provide a noexcept specialization to simulate
noexcept in type system.
4. Bikeshedding: `signature`.
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent 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/CAGsORuC1JiLdiMLB-Q2jSniyrhG09KkeoK9YRtMKTRvWQqWLeA%40mail.gmail.com.
.
Author: inkwizytoryankes@gmail.com
Date: Sun, 16 Jul 2017 04:26:33 -0700 (PDT)
Raw View
------=_Part_595_1742571628.1500204393689
Content-Type: multipart/alternative;
boundary="----=_Part_596_976142836.1500204393690"
------=_Part_596_976142836.1500204393690
Content-Type: text/plain; charset="UTF-8"
On Saturday, July 15, 2017 at 6:25:49 PM UTC+2, Vittorio Romeo wrote:
>
> Hello everyone - I'm looking for feedback on my *"function_ref: a
> non-owning reference to a Callable"* proposal. In short, this paper
> proposes the addition of something like `std::string_view` for functions, a
> lightweight type-erased reference vocabulary type that's especially useful
> when used as a function parameter.
>
> I wrote an article with a toy implementation in the past:
> https://vittorioromeo.info/index/blog/passing_functions_to_functions.html
>
> Jonathan Muller wrote two related posts:
> http://foonathan.net/blog/2017/01/20/function-ref-implementation.html
> http://foonathan.net/blog/2017/03/22/string_view-temporary.html
>
> Some earlier discussions can be found here:
>
> https://groups.google.com/a/isocpp.org/forum/?fromgroups#!searchin/std-proposals/function_ref/std-proposals/vven2Om7Ha8/_vTUvwSzBgAJ
>
> https://groups.google.com/a/isocpp.org/forum/?fromgroups#!searchin/std-proposals/function_ref/std-proposals/vMvzAl0a-P8/fbx1POVBCAAJ
> https://twitter.com/ericniebler/status/880899867035394048
>
> Thanks!
>
Did you think about constnes of `operator()`? I remember discussion about
`std::function` and that const call do not follow rule that all std const
objects are thread 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/2abc2b18-e6f2-4aa8-ac98-2b221ee536e0%40isocpp.org.
------=_Part_596_976142836.1500204393690
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Saturday, July 15, 2017 at 6:25:49 PM UTC+2, Vi=
ttorio Romeo wrote:<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">Hello everyone - I'm looking for feedback on my=C2=A0<i>"fun=
ction_ref: a non-owning reference to a Callable"</i> proposal. In shor=
t, this paper proposes the addition of something like `std::string_view` fo=
r functions, a lightweight type-erased reference vocabulary type that's=
=C2=A0especially useful when used as a function parameter.<br><br>I wrote a=
n article with a toy implementation in the past:<br><a href=3D"https://vitt=
orioromeo.info/index/blog/passing_functions_to_functions.html" target=3D"_b=
lank" rel=3D"nofollow" onmousedown=3D"this.href=3D'https://www.google.c=
om/url?q\x3dhttps%3A%2F%2Fvittorioromeo.info%2Findex%2Fblog%2Fpassing_funct=
ions_to_functions.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHve4dpkW7rNn=
mQkkxgBjnq3tYJEg';return true;" onclick=3D"this.href=3D'https://www=
..google.com/url?q\x3dhttps%3A%2F%2Fvittorioromeo.info%2Findex%2Fblog%2Fpass=
ing_functions_to_functions.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHve=
4dpkW7rNnmQkkxgBjnq3tYJEg';return true;">https://vittorioromeo.info/<wb=
r>index/blog/passing_functions_<wbr>to_functions.html</a><br><br>Jonathan M=
uller wrote two related posts:<br><a href=3D"http://foonathan.net/blog/2017=
/01/20/function-ref-implementation.html" target=3D"_blank" rel=3D"nofollow"=
onmousedown=3D"this.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%=
2Ffoonathan.net%2Fblog%2F2017%2F01%2F20%2Ffunction-ref-implementation.html\=
x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEpBx-ae0suoM1BpzgCF3SdVmg8sg';r=
eturn true;" onclick=3D"this.href=3D'http://www.google.com/url?q\x3dhtt=
p%3A%2F%2Ffoonathan.net%2Fblog%2F2017%2F01%2F20%2Ffunction-ref-implementati=
on.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEpBx-ae0suoM1BpzgCF3SdVmg8s=
g';return true;">http://foonathan.net/blog/<wbr>2017/01/20/function-ref=
-<wbr>implementation.html</a><br><a href=3D"http://foonathan.net/blog/2017/=
03/22/string_view-temporary.html" target=3D"_blank" rel=3D"nofollow" onmous=
edown=3D"this.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Ffoona=
than.net%2Fblog%2F2017%2F03%2F22%2Fstring_view-temporary.html\x26sa\x3dD\x2=
6sntz\x3d1\x26usg\x3dAFQjCNGqIKfzUK0egJJ2ATHE0O6YIo14TQ';return true;" =
onclick=3D"this.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Ffoo=
nathan.net%2Fblog%2F2017%2F03%2F22%2Fstring_view-temporary.html\x26sa\x3dD\=
x26sntz\x3d1\x26usg\x3dAFQjCNGqIKfzUK0egJJ2ATHE0O6YIo14TQ';return true;=
">http://foonathan.net/blog/<wbr>2017/03/22/string_view-<wbr>temporary.html=
</a><br><br>Some earlier discussions can be found here:<br><a href=3D"https=
://groups.google.com/a/isocpp.org/forum/?fromgroups#!searchin/std-proposals=
/function_ref/std-proposals/vven2Om7Ha8/_vTUvwSzBgAJ" target=3D"_blank" rel=
=3D"nofollow" onmousedown=3D"this.href=3D'https://groups.google.com/a/i=
socpp.org/forum/?fromgroups#!searchin/std-proposals/function_ref/std-propos=
als/vven2Om7Ha8/_vTUvwSzBgAJ';return true;" onclick=3D"this.href=3D'=
;https://groups.google.com/a/isocpp.org/forum/?fromgroups#!searchin/std-pro=
posals/function_ref/std-proposals/vven2Om7Ha8/_vTUvwSzBgAJ';return true=
;">https://groups.google.com/a/<wbr>isocpp.org/forum/?fromgroups#!<wbr>sear=
chin/std-proposals/<wbr>function_ref/std-proposals/<wbr>vven2Om7Ha8/_vTUvwS=
zBgAJ</a><br><a href=3D"https://groups.google.com/a/isocpp.org/forum/?fromg=
roups#!searchin/std-proposals/function_ref/std-proposals/vMvzAl0a-P8/fbx1PO=
VBCAAJ" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D'=
https://groups.google.com/a/isocpp.org/forum/?fromgroups#!searchin/std-prop=
osals/function_ref/std-proposals/vMvzAl0a-P8/fbx1POVBCAAJ';return true;=
" onclick=3D"this.href=3D'https://groups.google.com/a/isocpp.org/forum/=
?fromgroups#!searchin/std-proposals/function_ref/std-proposals/vMvzAl0a-P8/=
fbx1POVBCAAJ';return true;">https://groups.google.com/a/<wbr>isocpp.org=
/forum/?fromgroups#!<wbr>searchin/std-proposals/<wbr>function_ref/std-propo=
sals/<wbr>vMvzAl0a-P8/fbx1POVBCAAJ</a><br><a href=3D"https://twitter.com/er=
icniebler/status/880899867035394048" target=3D"_blank" rel=3D"nofollow" onm=
ousedown=3D"this.href=3D'https://www.google.com/url?q\x3dhttps%3A%2F%2F=
twitter.com%2Fericniebler%2Fstatus%2F880899867035394048\x26sa\x3dD\x26sntz\=
x3d1\x26usg\x3dAFQjCNEo3baSGDFms-zP1yX3OHXj6tGOEw';return true;" onclic=
k=3D"this.href=3D'https://www.google.com/url?q\x3dhttps%3A%2F%2Ftwitter=
..com%2Fericniebler%2Fstatus%2F880899867035394048\x26sa\x3dD\x26sntz\x3d1\x2=
6usg\x3dAFQjCNEo3baSGDFms-zP1yX3OHXj6tGOEw';return true;">https://twitt=
er.com/<wbr>ericniebler/status/<wbr>880899867035394048</a><br><br>Thanks!</=
div></blockquote><div><br>Did you think about constnes of `operator()`? I r=
emember discussion about `std::function` and that const call do not follow =
rule that all std const objects are thread 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" 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/2abc2b18-e6f2-4aa8-ac98-2b221ee536e0%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/2abc2b18-e6f2-4aa8-ac98-2b221ee536e0=
%40isocpp.org</a>.<br />
------=_Part_596_976142836.1500204393690--
------=_Part_595_1742571628.1500204393689--
.
Author: Vittorio Romeo <vittorio.romeo.vee@gmail.com>
Date: Mon, 17 Jul 2017 04:32:58 -0700 (PDT)
Raw View
------=_Part_1284_1520223279.1500291179087
Content-Type: multipart/alternative;
boundary="----=_Part_1285_1112499006.1500291179087"
------=_Part_1285_1112499006.1500291179087
Content-Type: text/plain; charset="UTF-8"
Thanks everyone for the feedback.
So far I have:
* Fixed the typos (double colon, "requires" instead of "remarks") found by
T.C..
* Marked `swap` as `noexcept` and defined the non-member `swap` in terms of
the member one.
Regarding the "empty state": I will think about this and add a small
section in the paper discussing pros&cons.
I couldn't find anything regarding `INVOKE<R>`. Where can I find more
information about that?
I will also look into a `noexcept` specialization.
--
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/e952b0e4-f989-4ee1-a554-e306c9278191%40isocpp.org.
------=_Part_1285_1112499006.1500291179087
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Thanks everyone for the feedback.=C2=A0<br><br>So far I ha=
ve:<br>* Fixed the typos (double colon, "requires" instead of &qu=
ot;remarks") found by T.C..<br>* Marked `swap` as `noexcept` and defin=
ed the non-member `swap` in terms of the member one.<br><br>Regarding the &=
quot;empty state": I will think about this and add a small section in =
the paper discussing pros&cons.<br>I couldn't find anything regardi=
ng `INVOKE<R>`. Where can I find more information about that?<br><br>=
I will also look into a `noexcept` specialization.</div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/e952b0e4-f989-4ee1-a554-e306c9278191%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/e952b0e4-f989-4ee1-a554-e306c9278191=
%40isocpp.org</a>.<br />
------=_Part_1285_1112499006.1500291179087--
------=_Part_1284_1520223279.1500291179087--
.