Topic: Something is missing, but not delegate
Author: Zhihao Yuan <lichray@gmail.com>
Date: Mon, 21 Jan 2013 18:49:55 -0600
Raw View
Hi,
I studied Mr. Mikhail's article, "Implementation of Delegates".
First, we observed that it's a pain to use std::bind to create
a callable object from an object and a member function pointer.
However, Mikhail thinks the missing part is an opaque object
which is similar to the result of std::bind or std::mem_fn.
I do not agree with this, because such an opaque objects do not care
about the lifetime of its underlay function. But if we treat `*this`
as a part of the function instead of an argument, we should show its
lifetime while taking its reference.
There's an example in the standard library: std::reference_wrapper.
So what I did is to write something similar, stdex::mem_call_wrapper,
and to extended `std::ref` to accept two arguments:
https://github.com/lichray/mem_call/blob/master/example.cc
B a;
auto f = ref(b, &A::f); // f is a mem_call_wrapper
f(...); // derived version called
Don't forget that `std::ref` can accept a function, so that the syntax
is unified:
auto f = ref(free_f); // f is a reference_wrapper
f(...);
What do you think?
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Mon, 21 Jan 2013 17:27:21 -0800 (PST)
Raw View
------=_Part_647_6351238.1358818041760
Content-Type: text/plain; charset=ISO-8859-1
On Monday, January 21, 2013 4:49:55 PM UTC-8, Zhihao Yuan wrote:
>
> Hi,
>
> I studied Mr. Mikhail's article, "Implementation of Delegates".
>
> First, we observed that it's a pain to use std::bind to create
> a callable object from an object and a member function pointer.
That's the part I don't really understand; is this a problem worth solving?
Or, more to the point, are you solving the problem *enough*?
A point brought up in the other thread that your solution doesn't cover is
overloading. std::bind doesn't deal with overloading at all; you must do an
explicit cast. Now this is true whether it is a function pointer or a
member pointer. But my point is that your example doesn't cover overloading.
Granted, there's no way to actually cover overloading without some kind of
language change (reflection or some other explicit language feature). But
that leads into my point: if you're not going to solve the overloading
problem, you're not fixing enough. Why is it so much more onerous to write
this:
std::bind((ReturnType (ClassName::*)(ArgType1 &&, const ArgType2 &, ArgType3
))&ClassName::FuncName, instance, _1, _2, _3);
instead of this:
std::ref(instance, (ReturnType (ClassName::*)(ArgType1 &&, const ArgType2 &,
ArgType3))&ClassName::FuncName);
You're still writing a lot of stuff either way. And even if you don't have
the cast in there, it's still not too much to write the `_1, _2, _3` part.
I just don't think it's a big enough deal. *Especially* once we get
polymorphic lambdas, so we can solve the problem more directly by just
using a lambda.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
------=_Part_647_6351238.1358818041760
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<br><br>On Monday, January 21, 2013 4:49:55 PM UTC-8, Zhihao Yuan wrote:<bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border=
-left: 1px #ccc solid;padding-left: 1ex;">Hi,
<br>
<br>I studied Mr. Mikhail's article, "Implementation of Delegates".
<br>
<br>First, we observed that it's a pain to use std::bind to create
<br>a callable object from an object and a member function pointer.</blockq=
uote><div><br>That's the part I don't really understand; is this a problem =
worth solving? Or, more to the point, are you solving the problem <i>enough=
</i>?<br><br>A point brought up in the other thread that your solution does=
n't cover is overloading. std::bind doesn't deal with overloading at all; y=
ou must do an explicit cast. Now this is true whether it is a function poin=
ter or a member pointer. But my point is that your example doesn't cover ov=
erloading.<br><br>Granted, there's no way to actually cover overloading wit=
hout some kind of language change (reflection or some other explicit langua=
ge feature). But that leads into my point: if you're not going to solve the=
overloading problem, you're not fixing enough. Why is it so much more oner=
ous to write this:<br><br><div class=3D"prettyprint" style=3D"background-co=
lor: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: so=
lid; border-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"=
><div class=3D"subprettyprint"><span style=3D"color: #000;" class=3D"styled=
-by-prettify">std</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">b=
ind</span><span style=3D"color: #660;" class=3D"styled-by-prettify">((</spa=
n><span style=3D"color: #606;" class=3D"styled-by-prettify">ReturnType</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"c=
olor: #606;" class=3D"styled-by-prettify">ClassName</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">::*)(</span><span style=3D"color: =
#606;" class=3D"styled-by-prettify">ArgType1</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" clas=
s=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">const</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> </span><span style=3D"color: #606;" class=3D"styled-by-prettif=
y">ArgType2</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><spa=
n style=3D"color: #606;" class=3D"styled-by-prettify">ArgType3</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">))&</span><span sty=
le=3D"color: #606;" class=3D"styled-by-prettify">ClassName</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=3D"col=
or: #606;" class=3D"styled-by-prettify">FuncName</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> instance</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> _1</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> _2</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> _3</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">);</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br></span></div></code></di=
v><br>instead of this:<br><br><div class=3D"prettyprint" style=3D"backgroun=
d-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style=
: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"prettypr=
int"><div class=3D"subprettyprint"><span style=3D"color: #000;" class=3D"st=
yled-by-prettify">std</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">::</span><span style=3D"color: #008;" class=3D"styled-by-prettif=
y">ref</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify">instance</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">,</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: #60=
6;" class=3D"styled-by-prettify">ReturnType</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">(</span><span style=3D"color: #606;" class=3D"style=
d-by-prettify">ClassName</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">::*)(</span><span style=3D"color: #606;" class=3D"styled-by-p=
rettify">ArgType1</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">&a=
mp;&,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
</span><span style=3D"color: #008;" class=3D"styled-by-prettify">const</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span s=
tyle=3D"color: #606;" class=3D"styled-by-prettify">ArgType2</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: =
#000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" cl=
ass=3D"styled-by-prettify">ArgType3</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">))&</span><span style=3D"color: #606;" class=
=3D"styled-by-prettify">ClassName</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">::</span><span style=3D"color: #606;" class=3D"styl=
ed-by-prettify">FuncName</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">);</span></div></code></div></div><br>You're still writing a =
lot of stuff either way. And even if you don't have the cast in there, it's=
still not too much to write the `_1, _2, _3` part.<br><br>I just don't thi=
nk it's a big enough deal. <i>Especially</i> once we get polymorphic lambda=
s, so we can solve the problem more directly by just using a lambda.<br>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_647_6351238.1358818041760--
.
Author: Zhihao Yuan <lichray@gmail.com>
Date: Mon, 21 Jan 2013 19:48:24 -0600
Raw View
On Mon, Jan 21, 2013 at 7:27 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
> You're still writing a lot of stuff either way. And even if you don't have
> the cast in there, it's still not too much to write the `_1, _2, _3` part.
It's not scalable, not intuitive to write `_1, _2, _3`.
> I just don't think it's a big enough deal. Especially once we get
> polymorphic lambdas, so we can solve the problem more directly by just using
> a lambda.
Only if you know the number of arguments.
Missing overloading (and template argument deduction) is indeed a
shame for function adapters; however, just like Stephan's less<>
proposal, I'm trying to fix something can be fixed. We have lambda in
hand, but we don't want to treat everything as nails.
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Mon, 21 Jan 2013 17:58:33 -0800 (PST)
Raw View
------=_Part_760_24106555.1358819913608
Content-Type: text/plain; charset=ISO-8859-1
On Monday, January 21, 2013 5:48:24 PM UTC-8, Zhihao Yuan wrote:
>
> On Mon, Jan 21, 2013 at 7:27 PM, Nicol Bolas <jmck...@gmail.com<javascript:>>
> wrote:
> > You're still writing a lot of stuff either way. And even if you don't
> have
> > the cast in there, it's still not too much to write the `_1, _2, _3`
> part.
>
> It's not scalable, not intuitive to write `_1, _2, _3`.
>
That's my point: why do we need a fix *specifically* for this one
particular case of member functions and a member instance? Wouldn't it be
easier to just have the std::bind functor forward any additional arguments
that aren't given placeholders in order? That is, if you use
`std::bind(function)` without any placeholders, you can call the resulting
functor with any arguments. Arguments not covered by placeholders or given
values will be forwarded in the order given.
The way you're doing it enforces reference semantics. What if I want *value*semantics, the way std::bind provides?
> > I just don't think it's a big enough deal. Especially once we get
> > polymorphic lambdas, so we can solve the problem more directly by just
> using
> > a lambda.
>
> Only if you know the number of arguments.
>
If we're going to have polymorphic lambdas, there's no reason we can't have
polymorphic *variadic* lambdas.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
------=_Part_760_24106555.1358819913608
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<br><br>On Monday, January 21, 2013 5:48:24 PM UTC-8, Zhihao Yuan wrote:<bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border=
-left: 1px #ccc solid;padding-left: 1ex;">On Mon, Jan 21, 2013 at 7:27 PM, =
Nicol Bolas <<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-ma=
ilto=3D"2wsbR6nQ1cMJ">jmck...@gmail.com</a>> wrote:
<br>> You're still writing a lot of stuff either way. And even if you do=
n't have
<br>> the cast in there, it's still not too much to write the `_1, _2, _=
3` part.
<br>
<br>It's not scalable, not intuitive to write `_1, _2, _3`.<br></blockquote=
><div><br>That's my point: why do we need a fix <i>specifically</i> for thi=
s one particular case of member functions and a member instance? Wouldn't i=
t be easier to just have the std::bind functor forward any additional argum=
ents that aren't given placeholders in order? That is, if you use `std::bin=
d(function)` without any placeholders, you can call the resulting functor w=
ith any arguments. Arguments not covered by placeholders or given values wi=
ll be forwarded in the order given.<br><br>The way you're doing it enforces=
reference semantics. What if I want <i>value</i> semantics, the way std::b=
ind provides?<br></div><div><br> </div><blockquote class=3D"gmail_quot=
e" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddin=
g-left: 1ex;">> I just don't think it's a big enough deal. Especially on=
ce we get
<br>> polymorphic lambdas, so we can solve the problem more directly by =
just using
<br>> a lambda.
<br>
<br>Only if you know the number of arguments.<br></blockquote><div><br>If w=
e're going to have polymorphic lambdas, there's no reason we can't have pol=
ymorphic <i>variadic</i> lambdas.</div><br>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_760_24106555.1358819913608--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Mon, 21 Jan 2013 18:01:31 -0800 (PST)
Raw View
------=_Part_391_14032241.1358820091202
Content-Type: text/plain; charset=ISO-8859-1
On Monday, January 21, 2013 5:48:24 PM UTC-8, Zhihao Yuan wrote:
>
> On Mon, Jan 21, 2013 at 7:27 PM, Nicol Bolas <jmck...@gmail.com> wrote:
>> > You're still writing a lot of stuff either way. And even if you don't
>> have
>> > the cast in there, it's still not too much to write the `_1, _2, _3`
>> part.
>>
>> It's not scalable, not intuitive to write `_1, _2, _3`.
>>
>
Also, to be quite honest... so what? How often are you doing this that
writing a few placeholders is a significant burden on useability? How
intuitive it is is a matter of opinion; it's clear to the reader exactly
what you're doing.
Oh, and another reason not to use std::ref is that, if I decide to make
some adjustment to the argument list later, I can do that while still using
the same code with std::bind. If I'm using std::ref, now I need to switch
to std::bind and make the adjustment there.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
------=_Part_391_14032241.1358820091202
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<br>On Monday, January 21, 2013 5:48:24 PM UTC-8, Zhihao Yuan wrote:<blockq=
uote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-lef=
t: 1px #ccc solid;padding-left: 1ex;"><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1e=
x">On Mon, Jan 21, 2013 at 7:27 PM, Nicol Bolas <<a>jmck...@gmail.com</a=
>> wrote:
<br>> You're still writing a lot of stuff either way. And even if you do=
n't have
<br>> the cast in there, it's still not too much to write the `_1, _2, _=
3` part.
<br>
<br>It's not scalable, not intuitive to write `_1, _2, _3`.<br></blockquote=
></blockquote><div><br>Also, to be quite honest... so what? How often are y=
ou doing this that writing a few placeholders is a significant burden on us=
eability? How intuitive it is is a matter of opinion; it's clear to the rea=
der exactly what you're doing.<br><br>Oh, and another reason not to use std=
::ref is that, if I decide to make some adjustment to the argument list lat=
er, I can do that while still using the same code with std::bind. If I'm us=
ing std::ref, now I need to switch to std::bind and make the adjustment the=
re.<br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_391_14032241.1358820091202--
.
Author: Zhihao Yuan <lichray@gmail.com>
Date: Mon, 21 Jan 2013 20:26:23 -0600
Raw View
On Mon, Jan 21, 2013 at 8:01 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
> Oh, and another reason not to use std::ref is that, if I decide to make some
> adjustment to the argument list later, I can do that while still using the
> same code with std::bind. If I'm using std::ref, now I need to switch to
> std::bind and make the adjustment there.
Plus the comments from your last reply, I found that your whole point
is to treat a member function call indifferently from other calls. It's
true to INVOKE, std::bind, etc, but sometimes it's not. Think about it:
why you do not write std::bind(&A::f, _1, _2, _3) instead of just a
std::mem_fn(&A::f)? And have you ever tried to pass an `a->f` to
algorithms and got an compilation error BTW?
PS: reference_wrapper/mem_call_wrapper are copyable of course.
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Mon, 21 Jan 2013 18:32:32 -0800 (PST)
Raw View
------=_Part_686_22177370.1358821952083
Content-Type: text/plain; charset=ISO-8859-1
On Monday, January 21, 2013 6:26:23 PM UTC-8, Zhihao Yuan wrote:
>
> On Mon, Jan 21, 2013 at 8:01 PM, Nicol Bolas <jmck...@gmail.com<javascript:>>
> wrote:
> > Oh, and another reason not to use std::ref is that, if I decide to make
> some
> > adjustment to the argument list later, I can do that while still using
> the
> > same code with std::bind. If I'm using std::ref, now I need to switch to
> > std::bind and make the adjustment there.
>
> Plus the comments from your last reply, I found that your whole point
> is to treat a member function call indifferently from other calls. It's
> true to INVOKE, std::bind, etc, but sometimes it's not. Think about it:
> why you do not write std::bind(&A::f, _1, _2, _3) instead of just a
> std::mem_fn(&A::f)? And have you ever tried to pass an `a->f` to
> algorithms and got an compilation error BTW?
>
I'm not seeing your point. We *shouldn't* want to treat member
function+object differently from a function call. That's one of the main
reasons why we have std::bind to begin with: so that we can *hide* the fact
that it's a member function. So that the fact that it's a member function
is an implementation detail the receiving code doesn't have to know or care
about.
PS: reference_wrapper/mem_call_wrapper are copyable of course.
>
Yes, they're copyable, but the whole point is that they hold the value by *
reference*. And thus, the stored value has reference semantics; copying the
reference_wrapper does not copy the *value*. If I'm providing some callback
for something, I may want the object itself to be stored within the
functor, so that the bound object will always exist and the functor will be
legitimate outside of the scope it was created in.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
------=_Part_686_22177370.1358821952083
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<br><br>On Monday, January 21, 2013 6:26:23 PM UTC-8, Zhihao Yuan wrote:<bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border=
-left: 1px #ccc solid;padding-left: 1ex;">On Mon, Jan 21, 2013 at 8:01 PM, =
Nicol Bolas <<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-ma=
ilto=3D"0gl1BBI25cAJ">jmck...@gmail.com</a>> wrote:
<br>> Oh, and another reason not to use std::ref is that, if I decide to=
make some
<br>> adjustment to the argument list later, I can do that while still u=
sing the
<br>> same code with std::bind. If I'm using std::ref, now I need to swi=
tch to
<br>> std::bind and make the adjustment there.
<br>
<br>Plus the comments from your last reply, I found that your whole point
<br>is to treat a member function call indifferently from other calls. &nbs=
p;It's
<br>true to INVOKE, std::bind, etc, but sometimes it's not. Think abo=
ut it:
<br>why you do not write std::bind(&A::f, _1, _2, _3) instead of just a
<br>std::mem_fn(&A::f)? And have you ever tried to pass an `a->=
;f` to
<br>algorithms and got an compilation error BTW?<br></blockquote><div><br>I=
'm not seeing your point. We <i>shouldn't</i> want to treat member function=
+object differently from a function call. That's one of the main reasons wh=
y we have std::bind to begin with: so that we can <i>hide</i> the fact that=
it's a member function. So that the fact that it's a member function is an=
implementation detail the receiving code doesn't have to know or care abou=
t.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
PS: reference_wrapper/mem_call_<wbr>wrapper are copyable of course.<br></bl=
ockquote><div><br>Yes, they're copyable, but the whole point is that they h=
old the value by <i>reference</i>. And thus, the stored value has reference=
semantics; copying the reference_wrapper does not copy the <i>value</i>. I=
f I'm providing some callback for something, I may want the object itself t=
o be stored within the functor, so that the bound object will always exist =
and the functor will be legitimate outside of the scope it was created in.<=
br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_686_22177370.1358821952083--
.
Author: Zhihao Yuan <lichray@gmail.com>
Date: Mon, 21 Jan 2013 21:00:41 -0600
Raw View
On Mon, Jan 21, 2013 at 8:32 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
> I'm not seeing your point. We shouldn't want to treat member function+object
> differently from a function call. That's one of the main reasons why we have
> std::bind to begin with: so that we can hide the fact that it's a member
> function. So that the fact that it's a member function is an implementation
> detail the receiving code doesn't have to know or care about.
Than why not writing every member functions as free friend functions?
We have ADL anyway.
Syntax matters; syntax affects design choices. The syntax of C++
treats member function calls differently, then we have the reason to
give the design, a policy bound with an object, an intuitive way to
express.
> Yes, they're copyable, but the whole point is that they hold the value by
> reference. And thus, the stored value has reference semantics; copying the
> reference_wrapper does not copy the value. If I'm providing some callback
> for something, I may want the object itself to be stored within the functor,
> so that the bound object will always exist and the functor will be
> legitimate outside of the scope it was created in.
Several years ago there was a proposal to standardize Boost.Signal;
I guess that it's possible after we have std::any.
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Mon, 21 Jan 2013 21:22:06 -0800 (PST)
Raw View
------=_Part_692_5477301.1358832126552
Content-Type: text/plain; charset=ISO-8859-1
On Monday, January 21, 2013 7:00:41 PM UTC-8, Zhihao Yuan wrote:
>
> On Mon, Jan 21, 2013 at 8:32 PM, Nicol Bolas <jmck...@gmail.com<javascript:>>
> wrote:
> > I'm not seeing your point. We shouldn't want to treat member
> function+object
> > differently from a function call. That's one of the main reasons why we
> have
> > std::bind to begin with: so that we can hide the fact that it's a member
> > function. So that the fact that it's a member function is an
> implementation
> > detail the receiving code doesn't have to know or care about.
>
> Than why not writing every member functions as free friend functions?
> We have ADL anyway.
>
> Syntax matters; syntax affects design choices. The syntax of C++
> treats member function calls differently, then we have the reason to
> give the design, a policy bound with an object, an intuitive way to
> express.
>
And what is wrong with using the already existing std::bind for that,
instead of std::ref which makes no sense and can't handle value semantics?
How it is the proposed change to std::bind not intuitive?
> Yes, they're copyable, but the whole point is that they hold the value by
> > reference. And thus, the stored value has reference semantics; copying
> the
> > reference_wrapper does not copy the value. If I'm providing some
> callback
> > for something, I may want the object itself to be stored within the
> functor,
> > so that the bound object will always exist and the functor will be
> > legitimate outside of the scope it was created in.
>
> Several years ago there was a proposal to standardize Boost.Signal;
> I guess that it's possible after we have std::any.
>
That seems like a non-sequitur, as it doesn't address my point: std::ref
doesn't have value semantics. Boost.Signal won't give it value semantics,
and neither will std::any.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
------=_Part_692_5477301.1358832126552
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<br><br>On Monday, January 21, 2013 7:00:41 PM UTC-8, Zhihao Yuan wrote:<bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border=
-left: 1px #ccc solid;padding-left: 1ex;">On Mon, Jan 21, 2013 at 8:32 PM, =
Nicol Bolas <<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-ma=
ilto=3D"wlnBsvpxw8gJ">jmck...@gmail.com</a>> wrote:
<br>> I'm not seeing your point. We shouldn't want to treat member funct=
ion+object
<br>> differently from a function call. That's one of the main reasons w=
hy we have
<br>> std::bind to begin with: so that we can hide the fact that it's a =
member
<br>> function. So that the fact that it's a member function is an imple=
mentation
<br>> detail the receiving code doesn't have to know or care about.
<br>
<br>Than why not writing every member functions as free friend functions?
<br>We have ADL anyway.
<br>
<br>Syntax matters; syntax affects design choices. The syntax of C++
<br>treats member function calls differently, then we have the reason to
<br>give the design, a policy bound with an object, an intuitive way to
<br>express.
<br></blockquote><div><br>And what is wrong with using the already existing=
std::bind for that, instead of std::ref which makes no sense and can't han=
dle value semantics? How it is the proposed change to std::bind not intuiti=
ve?<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;">
> Yes, they're copyable, but the whole point is that they hold the value=
by
<br>> reference. And thus, the stored value has reference semantics; cop=
ying the
<br>> reference_wrapper does not copy the value. If I'm providing some c=
allback
<br>> for something, I may want the object itself to be stored within th=
e functor,
<br>> so that the bound object will always exist and the functor will be
<br>> legitimate outside of the scope it was created in.
<br>
<br>Several years ago there was a proposal to standardize Boost.Signal;
<br>I guess that it's possible after we have std::any.<br></blockquote><div=
><br>That seems like a non-sequitur, as it doesn't address my point: std::r=
ef doesn't have value semantics. Boost.Signal won't give it value semantics=
, and neither will std::any.<br></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_692_5477301.1358832126552--
.
Author: Zhihao Yuan <lichray@gmail.com>
Date: Tue, 22 Jan 2013 00:18:02 -0600
Raw View
On Mon, Jan 21, 2013 at 11:22 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
> And what is wrong with using the already existing std::bind for that,
> instead of std::ref which makes no sense and can't handle value semantics?
Because std::bind does not handle the lifetime of the arguments,
while *this is essentially an argument.
> How it is the proposed change to std::bind not intuitive?
Because std::bind generates opaque objects to reorder the parameters,
but a function without an reordering should be the function itself:
ref(f) == ref(f); // with existing std::ref
ref(a, &A::f) == ref(a, &A::f); // my version; &B::f is also OK
> That seems like a non-sequitur, as it doesn't address my point: std::ref
> doesn't have value semantics. Boost.Signal won't give it value semantics,
> and neither will std::any.
You said you want a callback, and Boost.Signal can resolve the problem.
I don't see to copy the whole *this is worth and good for anything.
Boost.Any is required by the implementation of Boost.Signal. And I
suppose that a proposal should be well tested before being accepted.
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Mon, 21 Jan 2013 23:41:03 -0800 (PST)
Raw View
------=_Part_643_18943318.1358840463831
Content-Type: text/plain; charset=ISO-8859-1
On Monday, January 21, 2013 10:18:02 PM UTC-8, Zhihao Yuan wrote:
>
> On Mon, Jan 21, 2013 at 11:22 PM, Nicol Bolas <jmck...@gmail.com<javascript:>>
> wrote:
> > And what is wrong with using the already existing std::bind for that,
> > instead of std::ref which makes no sense and can't handle value
> semantics?
>
> Because std::bind does not handle the lifetime of the arguments,
> while *this is essentially an argument.
>
std::bind *does* manage the lifetime of its arguments. It takes its
arguments by value; that's why if you want to pass an argument reference,
you explicitly need to use std::ref to wrap it.
> How it is the proposed change to std::bind not intuitive?
>
> Because std::bind generates opaque objects to reorder the parameters,
> but a function without an reordering should be the function itself:
>
> ref(f) == ref(f); // with existing std::ref
> ref(a, &A::f) == ref(a, &A::f); // my version; &B::f is also OK
>
That's the only difference (besides reference semantics); that the
resulting object can have equality testing done on it.
I'm sorry, but I don't buy that as a sufficient justification for forcing
reference semantics on the user and abusing std::ref like this.
> That seems like a non-sequitur, as it doesn't address my point: std::ref
> > doesn't have value semantics. Boost.Signal won't give it value
> semantics,
> > and neither will std::any.
>
> You said you want a callback, and Boost.Signal can resolve the problem.
>
So can std::function. Boost.Signal is about more than just "a callback";
it's a mechanism to register many callbacks with a single source, and to
later de-register them when needed.
It says nothing about value semantics vs. reference semantics.
> I don't see to copy the whole *this is worth and good for anything.
>
The fact that you don't think that something should have value semantics
doesn't mean that it shouldn't. There's a reason std::bind has value
semantics. That reason being that it allows the *user* to decide what is
"worth and good for anything" for their particular needs. If they want
value semantics, they can use an object directly. If they want reference
semantics, they put the object in a std::ref.
This is the same reason why we have [=] and [&] for lambdas: so that the
user can decide which they need. It is not our job to tell people what the
one-true-way to pass parameters to bound functions is.
As for when value semantics are "worth and good for anything", it's the
same times when [=] is "worth and good for anything": when you need the
functor *itself* to control the lifetime of the objects it relies upon. For
example, one could easily register a std::string's c_str() method with a
specific std::string instance, such that calling it with no parameters will
return that specific `const char*`. There's little real point in not
letting the functor handle the lifetime of something like that.
Not every use of std::bind is for large, non-copyable objects. Sometimes,
you just want to throw some data at a callback. No point in having your
class store that data when the callback functor can do it itself just fine.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
------=_Part_643_18943318.1358840463831
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<br><br>On Monday, January 21, 2013 10:18:02 PM UTC-8, Zhihao Yuan wrote:<b=
lockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;borde=
r-left: 1px #ccc solid;padding-left: 1ex;">On Mon, Jan 21, 2013 at 11:22 PM=
, Nicol Bolas <<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-=
mailto=3D"m9qGCV912zEJ">jmck...@gmail.com</a>> wrote:
<br>> And what is wrong with using the already existing std::bind for th=
at,
<br>> instead of std::ref which makes no sense and can't handle value se=
mantics?
<br>
<br>Because std::bind does not handle the lifetime of the arguments,
<br>while *this is essentially an argument.<br></blockquote><div><br>std::b=
ind <i>does</i> manage the lifetime of its arguments. It takes its argument=
s by value; that's why if you want to pass an argument reference, you expli=
citly need to use std::ref to wrap it.<br><br></div><blockquote class=3D"gm=
ail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc soli=
d;padding-left: 1ex;">
> How it is the proposed change to std::bind not intuitive?
<br>
<br>Because std::bind generates opaque objects to reorder the parameters,
<br>but a function without an reordering should be the function itself:
<br>
<br> ref(f) =3D=3D ref(f); // with existing std::ref
<br> ref(a, &A::f) =3D=3D ref(a, &A::f); // my version; &=
B::f is also OK<br></blockquote><div><br>That's the only difference (beside=
s reference semantics); that the resulting object can have equality testing=
done on it.<br><br>I'm sorry, but I don't buy that as a sufficient justifi=
cation for forcing reference semantics on the user and abusing std::ref lik=
e this.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
> That seems like a non-sequitur, as it doesn't address my point: std::r=
ef
<br>> doesn't have value semantics. Boost.Signal won't give it value sem=
antics,
<br>> and neither will std::any.
<br>
<br>You said you want a callback, and Boost.Signal can resolve the problem.=
<br></blockquote><div><br>So can std::function. Boost.Signal is about more =
than just "a callback"; it's a mechanism to register many callbacks with a =
single source, and to later de-register them when needed.<br><br>It says no=
thing about value semantics vs. reference semantics.<br> </div><blockq=
uote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-lef=
t: 1px #ccc solid;padding-left: 1ex;">I don't see to copy the whole *this i=
s worth and good for anything.<br></blockquote><br>The fact that you don't =
think that something should have value semantics doesn't mean that it shoul=
dn't. There's a reason std::bind has value semantics. That reason being tha=
t it allows the <i>user</i> to decide what is "worth and good for anything"=
for their particular needs. If they want value semantics, they can use an =
object directly. If they want reference semantics, they put the object in a=
std::ref.<br><br>This is the same reason why we have [=3D] and [&] for=
lambdas: so that the user can decide which they need. It is not our job to=
tell people what the one-true-way to pass parameters to bound functions is=
..<br><br>As for when value semantics are "worth and good for anything", it'=
s the same times when [=3D] is "worth and good for anything": when you need=
the functor <i>itself</i> to control the lifetime of the objects it relies=
upon. For example, one could easily register a std::string's c_str() metho=
d with a specific std::string instance, such that calling it with no parame=
ters will return that specific `const char*`. There's little real point in =
not letting the functor handle the lifetime of something like that.<br><br>=
Not every use of std::bind is for large, non-copyable objects. Sometimes, y=
ou just want to throw some data at a callback. No point in having your clas=
s store that data when the callback functor can do it itself just fine.<br>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_643_18943318.1358840463831--
.
Author: Zhihao Yuan <lichray@gmail.com>
Date: Tue, 22 Jan 2013 02:16:40 -0600
Raw View
On Tue, Jan 22, 2013 at 1:41 AM, Nicol Bolas <jmckesson@gmail.com> wrote:
>> ref(f) == ref(f); // with existing std::ref
>> ref(a, &A::f) == ref(a, &A::f); // my version; &B::f is also OK
>
> I'm sorry, but I don't buy that as a sufficient justification for forcing
> reference semantics on the user and abusing std::ref like this.
It's not an abusing actually. It's about the only portable way to
pass a stateful predicate to STL.
A stateful predicate may not be a good example; I love functional
programming, too. But think about other stateful policies -- copying
is NG. Moving looks better, but high-order functions have to be
std::forward'ed everywhere. INVOKE cares about it, but STL,
and probability most libraries does not.
But `reference_wrapper` can work with any calling depths, any ::*_type
requirements, even inside seq/assoc containers. So does
my `mem_fun_wrapper`.
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
.
Author: Mikhail Semenov <mikhailsemenov1957@gmail.com>
Date: Sat, 26 Jan 2013 05:04:36 -0800 (PST)
Raw View
------=_Part_731_904301.1359205476062
Content-Type: text/plain; charset=ISO-8859-1
Hello Zhihao,
I have noticed that *ref *cannot be compared if they reference unrelated
members (members in diffrent classes).
Since my first attempt to introduce delegates, I have created revision 2,
where delegated can be compared,
even unrelated ones.
I guest another diffrence between create_delegate and reference the
difference is that I cannot write:
create_delegate(&b, &A::f),
but
create_delegate(&b, &B::f) is OK.
Regards,
Mikhail.
On Tuesday, January 22, 2013 12:49:55 AM UTC, Zhihao Yuan wrote:
> Hi,
>
> I studied Mr. Mikhail's article, "Implementation of Delegates".
>
> First, we observed that it's a pain to use std::bind to create
> a callable object from an object and a member function pointer.
> However, Mikhail thinks the missing part is an opaque object
> which is similar to the result of std::bind or std::mem_fn.
>
> I do not agree with this, because such an opaque objects do not care
> about the lifetime of its underlay function. But if we treat `*this`
> as a part of the function instead of an argument, we should show its
> lifetime while taking its reference.
>
> There's an example in the standard library: std::reference_wrapper.
> So what I did is to write something similar, stdex::mem_call_wrapper,
> and to extended `std::ref` to accept two arguments:
>
> https://github.com/lichray/mem_call/blob/master/example.cc
>
> B a;
> auto f = ref(b, &A::f); // f is a mem_call_wrapper
> f(...); // derived version called
>
> Don't forget that `std::ref` can accept a function, so that the syntax
> is unified:
>
> auto f = ref(free_f); // f is a reference_wrapper
> f(...);
>
> What do you think?
>
> --
> Zhihao Yuan, ID lichray
> The best way to predict the future is to invent it.
> ___________________________________________________
> 4BSD -- http://4bsd.biz/
>
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
------=_Part_731_904301.1359205476062
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div>Hello Zhihao,</div><div> </div><div>I have noticed that <strong>r=
ef </strong>cannot be compared if they reference unrelated members (members=
in diffrent classes).</div><div>Since my first attempt to introduce delega=
tes, I have created revision 2, where delegated can be compared,</div><div>=
even unrelated ones.</div><div> </div><div>I guest another diffrence b=
etween create_delegate and reference the difference is that I cannot =
write:</div><div>create_delegate(&b, &A::f), </div><div>but </div><=
div>create_delegate(&b, &B::f) is OK.</div><div> </div><div>Re=
gards,</div><div>Mikhail.</div><div><br>On Tuesday, January 22, 2013 12:49:=
55 AM UTC, Zhihao Yuan wrote:</div><blockquote style=3D"margin: 0px 0px 0px=
0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-le=
ft-width: 1px; border-left-style: solid;" class=3D"gmail_quote">Hi,
<br>
<br>I studied Mr. Mikhail's article, "Implementation of Delegates".
<br>
<br>First, we observed that it's a pain to use std::bind to create
<br>a callable object from an object and a member function pointer.
<br>However, Mikhail thinks the missing part is an opaque object
<br>which is similar to the result of std::bind or std::mem_fn.
<br>
<br>I do not agree with this, because such an opaque objects do not care
<br>about the lifetime of its underlay function. But if we treat `*th=
is`
<br>as a part of the function instead of an argument, we should show its
<br>lifetime while taking its reference.
<br>
<br>There's an example in the standard library: std::reference_wrapper.
<br>So what I did is to write something similar, stdex::mem_call_wrapper,
<br>and to extended `std::ref` to accept two arguments:
<br>
<br><a href=3D"https://github.com/lichray/mem_call/blob/master/example.cc" =
target=3D"_blank">https://github.com/lichray/<wbr>mem_call/blob/master/exam=
ple.<wbr>cc</a>
<br>
<br> B a;
<br> auto f =3D ref(b, &A::f); // f is a mem_call_wrapper
<br> f(...); // derived version called
<br>
<br>Don't forget that `std::ref` can accept a function, so that the syntax
<br>is unified:
<br>
<br> auto f =3D ref(free_f); // f is a reference_wrapper
<br> f(...);
<br>
<br>What do you think?
<br>
<br>--
<br>Zhihao Yuan, ID lichray
<br>The best way to predict the future is to invent it.
<br>______________________________<wbr>_____________________
<br>4BSD -- <a href=3D"http://4bsd.biz/" target=3D"_blank">http://4bsd.biz/=
</a>
<br></blockquote>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_731_904301.1359205476062--
.
Author: Sylvester Hesp <s.hesp@oisyn.nl>
Date: Sun, 27 Jan 2013 17:06:49 -0800 (PST)
Raw View
------=_Part_742_26304477.1359335209688
Content-Type: text/plain; charset=ISO-8859-1
I'd like to rewind the discussion somewhat, and express what I feel is
*really* missing. We're trying to solve binding with pointer-to-members,
but really, why do we even need to explicitely bind an object to a
pointer-to-member?
What I much rather like to see is having the compiler figure it all out by
simply referring to a function on an object. Something like this:
struct foo
{
void bar() { }
};
foo obj;
auto f = &obj.bar;
f();
Of course, this immediately leads to some questions:
* Is the address-operator really necessary, and is it unambiguous in all
cases? Or does it break current code?
* What type should 'f' be? Is it some anonymous type, or a standard type
involving the function's signature so we can overload on it?
* What happens if foo::bar in above case is actually overloaded?
And more generally:
* I refuse to believe I would be the first one to think of this. Has it
been proposed before, and if so, why was it rejected?
I can't really answer the last question. As for the first three:
- I can't think of any case where the address-of operator would be
ambiguous or break any existing code, since it is currently ill-formed to
take the address of a pointer to non-static member function without using
the nested-name-specifier syntax (see 8.3.3). Whether not using the & like
with regular functions, I don't forsee any problems at this point but I
wouldn't be too fond of the syntax.
- I feel the type of 'f should be well-defined in the standard. Extending
the native typesystem would probably be too much hassle, but we can always
rely on a simple template class in the std namespace. For example, the type
of 'f' in the example above could be member_pointer<foo&, void()>. For
other CV-qualified functions the first template argument can simply be
altered, such as member_pointer<const foo&, void()> for a const function
and member_pointer<foo&&, void()> for a function binding to rvalue ref. The
member_pointer<T,S> class itself should obviously have an operator() with
appropriate signature S. But also a get_this() function that returns the
captured 'this' of type T, and a constructor that accepts a reference to an
object and a pointer-to-member. It should also be convertible to
member_function<T2,S> if is_base_of<T2,T>.
- Above answer immediately solves the issue with overloading. If the
context accepts a certain type of member_pointer, the compiler can
automatically select the appropriate overload.
What do you guys think? Is this worth a proposal?
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
------=_Part_742_26304477.1359335209688
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
I'd like to rewind the discussion somewhat, and express what I feel is *rea=
lly* missing. We're trying to solve binding with pointer-to-members, but re=
ally, why do we even need to explicitely bind an object to a pointer-to-mem=
ber?<div><br></div><div>What I much rather like to see is having the compil=
er figure it all out by simply referring to a function on an object. Someth=
ing like this:</div><div><br></div><div style=3D"background-color: rgb(250,=
250, 250); border: 1px solid rgb(187, 187, 187); word-wrap: break-word;" c=
lass=3D"prettyprint"><code class=3D"prettyprint"><div class=3D"subprettypri=
nt"><span style=3D"color: #008;" class=3D"styled-by-prettify">struct</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> foo<br></span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br> </span><sp=
an style=3D"color: #008;" class=3D"styled-by-prettify">void</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> bar</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;" cla=
ss=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><span style=3D"color: #000;" class=3D"styled-by-prettify"><=
br></span><span style=3D"color: #660;" class=3D"styled-by-prettify">};</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br>foo obj=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span st=
yle=3D"color: #008;" class=3D"styled-by-prettify">auto</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> f </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: #660;" class=3D=
"styled-by-prettify">&</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify">obj</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">.</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
bar</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br>f</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">();</span></div><=
/code></div><div><br></div><div>Of course, this immediately leads to some q=
uestions:</div><div>* Is the address-operator really necessary, and is it u=
nambiguous in all cases? Or does it break current code?</div><div>* What ty=
pe should 'f' be? Is it some anonymous type, or a standard type involving t=
he function's signature so we can overload on it?</div><div>* What happens =
if foo::bar in above case is actually overloaded?</div><div><br></div><div>=
And more generally:</div><div>* I refuse to believe I would be the first on=
e to think of this. Has it been proposed before, and if so, why was it reje=
cted?</div><div><br></div><div>I can't really answer the last question. As =
for the first three:</div><div><br></div><div>- I can't think of any case w=
here the address-of operator would be ambiguous or break any existing code,=
since it is currently ill-formed to take the address of a pointer to non-s=
tatic member function without using the nested-name-specifier syntax (see 8=
..3.3). Whether not using the & like with regular functions, I don't for=
see any problems at this point but I wouldn't be too fond of the syntax.</d=
iv><div><br></div><div>- I feel the type of 'f should be well-defined in th=
e standard. Extending the native typesystem would probably be too much hass=
le, but we can always rely on a simple template class in the std namespace.=
For example, the type of 'f' in the example above could be <font face=3D"c=
ourier new, monospace">member_pointer<foo&, void()></font>. For o=
ther CV-qualified functions the first template argument can simply be alter=
ed, such as <span style=3D"font-family: 'courier new', monospace;">mem=
ber_pointer<const foo&, void()></span><font face=3D"arial, sans-s=
erif"> for a const function and </font><span style=3D"font-family: 'co=
urier new', monospace;">member_pointer<foo&&, void()></span><=
font face=3D"arial, sans-serif"> for a function binding to rvalue ref. The&=
nbsp;</font><span style=3D"font-family: 'courier new', monospace;">member_p=
ointer<T,S></span><font face=3D"arial, sans-serif"> class itself=
should obviously have an </font><font face=3D"courier new, monospace">oper=
ator()</font><font face=3D"arial, sans-serif"> with appropriate signat=
ure S. But also a </font><font face=3D"courier new, monospace">get_this()</=
font><font face=3D"arial, sans-serif"> function that returns the captured '=
this' of type T, and a constructor that accepts a reference to an object an=
d a pointer-to-member. It should also be convertible to </font><font face=
=3D"courier new, monospace">member_function<T2,S></font><font face=3D=
"arial, sans-serif"> if </font><font face=3D"courier new, monospace">is_bas=
e_of<T2,T></font><font face=3D"arial, sans-serif">.</font></div><div>=
<font face=3D"arial, sans-serif"><br></font></div><div><font face=3D"arial,=
sans-serif">- Above answer immediately solves the issue with overloading. =
If the context accepts a certain type of </font><span style=3D"font-fa=
mily: 'courier new', monospace;">member_pointer</span><font face=3D"arial, =
sans-serif">, the compiler can automatically select the appropriate overloa=
d.</font></div><div><font face=3D"arial, sans-serif"><br></font></div><div>=
<font face=3D"arial, sans-serif">What do you guys think? Is this worth a pr=
oposal?</font></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_742_26304477.1359335209688--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sun, 27 Jan 2013 18:04:42 -0800 (PST)
Raw View
------=_Part_103_25577797.1359338682275
Content-Type: text/plain; charset=ISO-8859-1
On Sunday, January 27, 2013 5:06:49 PM UTC-8, Sylvester Hesp wrote:
>
> I'd like to rewind the discussion somewhat, and express what I feel is
> *really* missing. We're trying to solve binding with pointer-to-members,
> but really, why do we even need to explicitely bind an object to a
> pointer-to-member?
Because it's not worth having a language feature for something like this.
What I much rather like to see is having the compiler figure it all out by
> simply referring to a function on an object. Something like this:
>
> struct foo
> {
> void bar() { }
> };
>
> foo obj;
> auto f = &obj.bar;
>
> f();
>
> Of course, this immediately leads to some questions:
> * Is the address-operator really necessary, and is it unambiguous in all
> cases? Or does it break current code?
> * What type should 'f' be? Is it some anonymous type, or a standard type
> involving the function's signature so we can overload on it?
> * What happens if foo::bar in above case is actually overloaded?
>
> And more generally:
> * I refuse to believe I would be the first one to think of this. Has it
> been proposed before, and if so, why was it rejected?
>
> I can't really answer the last question. As for the first three:
>
> - I can't think of any case where the address-of operator would be
> ambiguous or break any existing code, since it is currently ill-formed to
> take the address of a pointer to non-static member function without using
> the nested-name-specifier syntax (see 8.3.3). Whether not using the & like
> with regular functions, I don't forsee any problems at this point but I
> wouldn't be too fond of the syntax.
>
> - I feel the type of 'f should be well-defined in the standard. Extending
> the native typesystem would probably be too much hassle, but we can always
> rely on a simple template class in the std namespace. For example, the type
> of 'f' in the example above could be member_pointer<foo&, void()>. For
> other CV-qualified functions the first template argument can simply be
> altered, such as member_pointer<const foo&, void()> for a const function
> and member_pointer<foo&&, void()> for a function binding to rvalue ref.
> The member_pointer<T,S> class itself should obviously have an operator() with
> appropriate signature S. But also a get_this() function that returns the
> captured 'this' of type T, and a constructor that accepts a reference to an
> object and a pointer-to-member. It should also be convertible to
> member_function<T2,S> if is_base_of<T2,T>.
>
That's great... if you want to capture by *reference*. C++ uses value
semantics by default, because it's safer overall. std::bind captures
values; you have to wrap a value in a std::ref to capture by reference.
Using no prefix in a lambda capture list (ie: `[capture]()`) means to
capture by value. And so forth.
So whatever this should do, it should capture *by value*. If you want
capture by reference, you should provide some alternative, more verbose,
mechanism for that.
- Above answer immediately solves the issue with overloading. If the
> context accepts a certain type of member_pointer, the compiler can
> automatically select the appropriate overload.
>
I assume that `auto` or other type-deduction contexts will fail, yes?
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
------=_Part_103_25577797.1359338682275
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<br><br>On Sunday, January 27, 2013 5:06:49 PM UTC-8, Sylvester Hesp wrote:=
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;">I'd like to rewind the discuss=
ion somewhat, and express what I feel is *really* missing. We're trying to =
solve binding with pointer-to-members, but really, why do we even need to e=
xplicitely bind an object to a pointer-to-member?</blockquote><div><br>Beca=
use it's not worth having a language feature for something like this.<br><b=
r></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0=
..8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div></div><div>What I=
much rather like to see is having the compiler figure it all out by simply=
referring to a function on an object. Something like this:</div><div><br><=
/div><div style=3D"background-color:rgb(250,250,250);border:1px solid rgb(1=
87,187,187);word-wrap:break-word"><code><div><span style=3D"color:#008">str=
uct</span><span style=3D"color:#000"> foo<br></span><span style=3D"color:#6=
60">{</span><span style=3D"color:#000"><br> </span><span style=
=3D"color:#008">void</span><span style=3D"color:#000"> bar</span><span styl=
e=3D"color:#660">()</span><span style=3D"color:#000"> </span><span style=3D=
"color:#660">{</span><span style=3D"color:#000"> </span><span style=3D"colo=
r:#660">}</span><span style=3D"color:#000"><br></span><span style=3D"color:=
#660">};</span><span style=3D"color:#000"><br><br>foo obj</span><span style=
=3D"color:#660">;</span><span style=3D"color:#000"><br></span><span style=
=3D"color:#008">auto</span><span style=3D"color:#000"> f </span><span style=
=3D"color:#660">=3D</span><span style=3D"color:#000"> </span><span style=3D=
"color:#660">&</span><span style=3D"color:#000">obj</span><span style=
=3D"color:#660">.</span><span style=3D"color:#000">bar</span><span style=3D=
"color:#660">;</span><span style=3D"color:#000"><br><br>f</span><span style=
=3D"color:#660">();</span></div></code></div><div><br></div><div>Of course,=
this immediately leads to some questions:</div><div>* Is the address-opera=
tor really necessary, and is it unambiguous in all cases? Or does it break =
current code?</div><div>* What type should 'f' be? Is it some anonymous typ=
e, or a standard type involving the function's signature so we can overload=
on it?</div><div>* What happens if foo::bar in above case is actually over=
loaded?</div><div><br></div><div>And more generally:</div><div>* I refuse t=
o believe I would be the first one to think of this. Has it been proposed b=
efore, and if so, why was it rejected?</div><div><br></div><div>I can't rea=
lly answer the last question. As for the first three:</div><div><br></div><=
div>- I can't think of any case where the address-of operator would be ambi=
guous or break any existing code, since it is currently ill-formed to take =
the address of a pointer to non-static member function without using the ne=
sted-name-specifier syntax (see 8.3.3). Whether not using the & like wi=
th regular functions, I don't forsee any problems at this point but I would=
n't be too fond of the syntax.</div><div><br></div><div>- I feel the type o=
f 'f should be well-defined in the standard. Extending the native typesyste=
m would probably be too much hassle, but we can always rely on a simple tem=
plate class in the std namespace. For example, the type of 'f' in the examp=
le above could be <font face=3D"courier new, monospace">member_pointer<f=
oo&, void()></font>. For other CV-qualified functions the first temp=
late argument can simply be altered, such as <span style=3D"font-famil=
y:'courier new',monospace">member_pointer<const foo&, void()></sp=
an><font face=3D"arial, sans-serif"> for a const function and </font><=
span style=3D"font-family:'courier new',monospace">member_pointer<foo&am=
p;&, void()></span><font face=3D"arial, sans-serif"> for a function =
binding to rvalue ref. The </font><span style=3D"font-family:'courier =
new',monospace">member_pointer<T,S></span><font face=3D"arial, sans-s=
erif"> class itself should obviously have an </font><font face=3D"cour=
ier new, monospace">operator()</font><font face=3D"arial, sans-serif"> =
;with appropriate signature S. But also a </font><font face=3D"courier new,=
monospace">get_this()</font><font face=3D"arial, sans-serif"> function tha=
t returns the captured 'this' of type T, and a constructor that accepts a r=
eference to an object and a pointer-to-member. It should also be convertibl=
e to </font><font face=3D"courier new, monospace">member_function<T2,S&g=
t;</font><font face=3D"arial, sans-serif"> if </font><font face=3D"courier =
new, monospace">is_base_of<T2,T></font><font face=3D"arial, sans-seri=
f">.</font></div></blockquote><div><br>That's great... if you want to captu=
re by <i>reference</i>. C++ uses value semantics by default, because it's s=
afer overall. std::bind captures values; you have to wrap a value in a std:=
:ref to capture by reference. Using no prefix in a lambda capture list (ie:=
`[capture]()`) means to capture by value. And so forth.<br><br>So whatever=
this should do, it should capture <i>by value</i>. If you want capture by =
reference, you should provide some alternative, more verbose, mechanism for=
that.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div><font=
face=3D"arial, sans-serif"></font></div><div><font face=3D"arial, sans-ser=
if">- Above answer immediately solves the issue with overloading. If the co=
ntext accepts a certain type of </font><span style=3D"font-family:'cou=
rier new',monospace">member_pointer</span><font face=3D"arial, sans-serif">=
, the compiler can automatically select the appropriate overload.</font></d=
iv></blockquote><div><br>I assume that `auto` or other type-deduction conte=
xts will fail, yes?</div><br>
<p></p>
-- <br />
<br />
--- <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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_103_25577797.1359338682275--
.
Author: Zhihao Yuan <lichray@gmail.com>
Date: Sun, 27 Jan 2013 20:19:45 -0600
Raw View
On Sun, Jan 27, 2013 at 7:06 PM, Sylvester Hesp <s.hesp@oisyn.nl> wrote:
> It should also be convertible to
> member_function<T2,S> if is_base_of<T2,T>.
So you are suggesting a language feature returning a library
type, which might not be appropriate.
If we really want a language level solution, let me see... How
about to make the syntax
a.f
returns a [a](...) /* mutable, if needed */ { return a.f(...); }, and the syntax
&a.f
returns a [&a](...) /* mutable, if needed */ { return a.f(...); }
But this solution requires a carefully specified parameters (including
template parameters, probably) transformation rule.
--
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
___________________________________________________
4BSD -- http://4bsd.biz/
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Sun, 27 Jan 2013 19:06:22 -0800 (PST)
Raw View
------=_Part_698_23419373.1359342382249
Content-Type: text/plain; charset=ISO-8859-1
On Sunday, January 27, 2013 6:19:45 PM UTC-8, Zhihao Yuan wrote:
>
> On Sun, Jan 27, 2013 at 7:06 PM, Sylvester Hesp <s.h...@oisyn.nl<javascript:>>
> wrote:
> > It should also be convertible to
> > member_function<T2,S> if is_base_of<T2,T>.
>
> So you are suggesting a language feature returning a library
> type, which might not be appropriate.
>
> If we really want a language level solution, let me see... How
> about to make the syntax
>
> a.f
>
> returns a [a](...) /* mutable, if needed */ { return a.f(...); }, and the
> syntax
>
> &a.f
>
> returns a [&a](...) /* mutable, if needed */ { return a.f(...); }
>
> But this solution requires a carefully specified parameters (including
> template parameters, probably) transformation rule.
>
I don't like that for one reason: it's more powerful and not orthogonal
with regular functions. This would effectively solve the overloading
problem, allowing one to create these delegates that could call overloaded
functions. But if we want that feature, we probably also want it for
non-member functions as well.
DeadMG (I think) proposed a mechanism that would wrap *any* function call
into a variadic, polymorphic callable type. That could be combined with
this syntax, which would be much more preferable and powerful.
Of course, it would also lose the equality testing part...
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
------=_Part_698_23419373.1359342382249
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<br><br>On Sunday, January 27, 2013 6:19:45 PM UTC-8, Zhihao Yuan wrote:<bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border=
-left: 1px #ccc solid;padding-left: 1ex;">On Sun, Jan 27, 2013 at 7:06 PM, =
Sylvester Hesp <<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated=
-mailto=3D"BxgJgDjKUIwJ">s.h...@oisyn.nl</a>> wrote:
<br>> It should also be convertible to
<br>> member_function<T2,S> if is_base_of<T2,T>.
<br>
<br>So you are suggesting a language feature returning a library
<br>type, which might not be appropriate.
<br>
<br>If we really want a language level solution, let me see... How
<br>about to make the syntax
<br>
<br> a.f
<br>
<br>returns a [a](...) /* mutable, if needed */ { return a.f(...); }, and t=
he syntax
<br>
<br> &a.f
<br>
<br>returns a [&a](...) /* mutable, if needed */ { return a.f(...); }
<br>
<br>But this solution requires a carefully specified parameters (including
<br>template parameters, probably) transformation rule.<br></blockquote><di=
v><br>I don't like that for one reason: it's more powerful and not orthogon=
al with regular functions. This would effectively solve the overloading pro=
blem, allowing one to create these delegates that could call overloaded fun=
ctions. But if we want that feature, we probably also want it for non-membe=
r functions as well.<br><br>DeadMG (I think) proposed a mechanism that woul=
d wrap <i>any</i> function call into a variadic, polymorphic callable type.=
That could be combined with this syntax, which would be much more preferab=
le and powerful.<br><br>Of course, it would also lose the equality testing =
part...<br></div>
<p></p>
-- <br />
<br />
--- <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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_698_23419373.1359342382249--
.
Author: Sylvester Hesp <s.hesp@oisyn.nl>
Date: Mon, 28 Jan 2013 03:19:01 -0800 (PST)
Raw View
------=_Part_668_30338402.1359371941899
Content-Type: text/plain; charset=ISO-8859-1
On Monday, January 28, 2013 3:04:42 AM UTC+1, Nicol Bolas wrote:
>
>
>
> On Sunday, January 27, 2013 5:06:49 PM UTC-8, Sylvester Hesp wrote:
>>
>> I'd like to rewind the discussion somewhat, and express what I feel is
>> *really* missing. We're trying to solve binding with pointer-to-members,
>> but really, why do we even need to explicitely bind an object to a
>> pointer-to-member?
>
>
> Because it's not worth having a language feature for something like this.
>
I severely disagree with you on that one. Typing std::bind(obj, &T::fun) is
too verbose. Similar languages like C# tend to agree with me.
> That's great... if you want to capture by *reference*. C++ uses value
> semantics by default, because it's safer overall. std::bind captures
> values; you have to wrap a value in a std::ref to capture by reference.
> Using no prefix in a lambda capture list (ie: `[capture]()`) means to
> capture by value. And so forth.
>
Indeed, you capture the this pointer by value. What I propose is not
essentially all that different from capturing 'this' in a lambda. That
certainly does NOT copy the object. The reason I went for the reference
parameter is to distinguish between pointer-to-members that bind to lvalues
and rvalues.
> I assume that `auto` or other type-deduction contexts will fail, yes?
>
Yes, similar to using auto in other overloaded contexts.
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
------=_Part_668_30338402.1359371941899
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<br><br>On Monday, January 28, 2013 3:04:42 AM UTC+1, Nicol Bolas wrote:<bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border=
-left: 1px #ccc solid;padding-left: 1ex;"><br><br>On Sunday, January 27, 20=
13 5:06:49 PM UTC-8, Sylvester Hesp wrote:<blockquote class=3D"gmail_quote"=
style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-lef=
t:1ex">I'd like to rewind the discussion somewhat, and express what I feel =
is *really* missing. We're trying to solve binding with pointer-to-members,=
but really, why do we even need to explicitely bind an object to a pointer=
-to-member?</blockquote><div><br>Because it's not worth having a language f=
eature for something like this.<br></div></blockquote><div><br></div><div>I=
severely disagree with you on that one. Typing std::bind(obj, &T::fun)=
is too verbose. Similar languages like C# tend to agree with me.</div><div=
> </div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div>That's great=
.... if you want to capture by <i>reference</i>. C++ uses value semantics by=
default, because it's safer overall. std::bind captures values; you have t=
o wrap a value in a std::ref to capture by reference. Using no prefix in a =
lambda capture list (ie: `[capture]()`) means to capture by value. And so f=
orth.<br></div></blockquote><div><br></div><div>Indeed, you capture the thi=
s pointer by value. What I propose is not essentially all that different fr=
om capturing 'this' in a lambda. That certainly does NOT copy the object. T=
he reason I went for the reference parameter is to distinguish between poin=
ter-to-members that bind to lvalues and rvalues.</div><div> </div><blo=
ckquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-=
left: 1px #ccc solid;padding-left: 1ex;"><div></div><div>I assume that `aut=
o` or other type-deduction contexts will fail, yes?<br></div></blockquote><=
div><br></div><div>Yes, similar to using auto in other overloaded contexts.=
</div>
<p></p>
-- <br />
<br />
--- <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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_668_30338402.1359371941899--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Mon, 28 Jan 2013 03:40:47 -0800 (PST)
Raw View
------=_Part_741_23394933.1359373247064
Content-Type: text/plain; charset=ISO-8859-1
On Monday, January 28, 2013 3:19:01 AM UTC-8, Sylvester Hesp wrote:
>
>
>
> On Monday, January 28, 2013 3:04:42 AM UTC+1, Nicol Bolas wrote:
>>
>>
>>
>> On Sunday, January 27, 2013 5:06:49 PM UTC-8, Sylvester Hesp wrote:
>>>
>>> I'd like to rewind the discussion somewhat, and express what I feel is
>>> *really* missing. We're trying to solve binding with pointer-to-members,
>>> but really, why do we even need to explicitely bind an object to a
>>> pointer-to-member?
>>
>>
>> Because it's not worth having a language feature for something like this.
>>
>
> I severely disagree with you on that one. Typing std::bind(obj, &T::fun)
> is too verbose. Similar languages like C# tend to agree with me.
>
You are quite literally talking about 13 characters. You want a whole
language feature for the sole purpose of not typing *thirteen characters*.
We got `auto` because the typenames for many things were either ecxeedingly
long (80+ characters), not easily discoverable, or a combination of both.
We didn't get it so that you didn't have to type `std::string` in a few
places. The same goes here: we're not going to add a language feature for
no other purpose than to save you a couple of keystrokes.
That's great... if you want to capture by *reference*. C++ uses value
>> semantics by default, because it's safer overall. std::bind captures
>> values; you have to wrap a value in a std::ref to capture by reference.
>> Using no prefix in a lambda capture list (ie: `[capture]()`) means to
>> capture by value. And so forth.
>>
>
> Indeed, you capture the this pointer by value. What I propose is not
> essentially all that different from capturing 'this' in a lambda. That
> certainly does NOT copy the object.
>
Which is one of the big reasons why implicit capture of `this` is very
likely to go away<http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2012/n3424.pdf>.
It was a mistake, not something to be emulated.
Most importantly of all... what if I don't *want* to capture by reference?
And yes, capturing a pointer by value is capturing by reference; you know
exactly what I'm talking about, so don't split hairs. What if I *want* the
functor to actually *contain* the object? You know, so that I can use that
functor outside of this call stack?
The thing about capture-by-value that's nice is that if you want to capture
by reference, you can. Whereas if you're already capturing-by-reference,
you can't turn that into capture-by-value.
The reason I went for the reference parameter is to distinguish between
> pointer-to-members that bind to lvalues and rvalues.
>
Isn't that just part of the member function signature?
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
------=_Part_741_23394933.1359373247064
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<br><br>On Monday, January 28, 2013 3:19:01 AM UTC-8, Sylvester Hesp wrote:=
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;"><br><br>On Monday, January 28,=
2013 3:04:42 AM UTC+1, Nicol Bolas wrote:<blockquote class=3D"gmail_quote"=
style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-lef=
t:1ex"><br><br>On Sunday, January 27, 2013 5:06:49 PM UTC-8, Sylvester Hesp=
wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8e=
x;border-left:1px #ccc solid;padding-left:1ex">I'd like to rewind the discu=
ssion somewhat, and express what I feel is *really* missing. We're trying t=
o solve binding with pointer-to-members, but really, why do we even need to=
explicitely bind an object to a pointer-to-member?</blockquote><div><br>Be=
cause it's not worth having a language feature for something like this.<br>=
</div></blockquote><div><br></div><div>I severely disagree with you on that=
one. Typing std::bind(obj, &T::fun) is too verbose. Similar languages =
like C# tend to agree with me.</div></blockquote><div><br>You are quite lit=
erally talking about 13 characters. You want a whole language feature for t=
he sole purpose of not typing <i>thirteen characters</i>.<br><br>We got `au=
to` because the typenames for many things were either ecxeedingly long (80+=
characters), not easily discoverable, or a combination of both. We didn't =
get it so that you didn't have to type `std::string` in a few places. The s=
ame goes here: we're not going to add a language feature for no other purpo=
se than to save you a couple of keystrokes.<br><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div></div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1=
ex"><div>That's great... if you want to capture by <i>reference</i>. C++ us=
es value semantics by default, because it's safer overall. std::bind captur=
es values; you have to wrap a value in a std::ref to capture by reference. =
Using no prefix in a lambda capture list (ie: `[capture]()`) means to captu=
re by value. And so forth.<br></div></blockquote><div><br></div><div>Indeed=
, you capture the this pointer by value. What I propose is not essentially =
all that different from capturing 'this' in a lambda. That certainly does N=
OT copy the object.</div></blockquote><div><br>Which is one of the big reas=
ons why implicit capture of `this` is <a href=3D"http://www.open-std.org/JT=
C1/SC22/WG21/docs/papers/2012/n3424.pdf">very likely to go away</a>. It was=
a mistake, not something to be emulated.<br><br>Most importantly of all...=
what if I don't <i>want</i> to capture by reference? And yes, capturing a =
pointer by value is capturing by reference; you know exactly what I'm talki=
ng about, so don't split hairs. What if I <i>want</i> the functor to actual=
ly <i>contain</i> the object? You know, so that I can use that functor outs=
ide of this call stack?<br><br>The thing about capture-by-value that's nice=
is that if you want to capture by reference, you can. Whereas if you're al=
ready capturing-by-reference, you can't turn that into capture-by-value.<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>The reason I w=
ent for the reference parameter is to distinguish between pointer-to-member=
s that bind to lvalues and rvalues.</div></blockquote><div><br>Isn't that j=
ust part of the member function signature? <br></div>
<p></p>
-- <br />
<br />
--- <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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_741_23394933.1359373247064--
.
Author: Sylvester Hesp <s.hesp@oisyn.nl>
Date: Mon, 28 Jan 2013 04:05:43 -0800 (PST)
Raw View
------=_Part_1036_9814884.1359374743590
Content-Type: text/plain; charset=ISO-8859-1
> You are quite literally talking about 13 characters. You want a whole
> language feature for the sole purpose of not typing *thirteen characters*.
>
Do I really need to point out that 'T' usually isn't just 'T'? The compiler
already knows the type, why should I bothered with typing it again? Also,
pointer-to-member syntax isn't really userfriendly.
> Which is one of the big reasons why implicit capture of `this` is very
> likely to go away<http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2012/n3424.pdf>.
> It was a mistake, not something to be emulated.
>
You're talking about *implicit *capturing of this. With explicit capturing
you still capture the pointer, not the object. That document even talks
about "'this' captured by value" which implies the member is effectively
captured by reference.
> Most importantly of all... what if I don't *want* to capture by reference?
>
Then use bind, or copy the object by hand. This idea is simply intended if
you merely want to want to create a callback to a member function of a
class instance. I don't know about the codebase you're involved in, but in
my personal experience you pretty much always want to capture the object by
reference. I literally can't think of any actual scenario where we wanted a
copy. We always bind() with a pointer to the object.
>
> Isn't that just part of the member function signature?
>
The second template parameter is just a function type (e.g., void(int)),
not pointer-to-member. If I really wanted full type erasure I would've
simply used std::function<void()>, but I don't want that for more than one
reason (overloading, automatic type deduction, equality operators, getting
the 'this', etc.)
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
------=_Part_1036_9814884.1359374743590
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<br><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;"><div>You are quite literal=
ly talking about 13 characters. You want a whole language feature for the s=
ole purpose of not typing <i>thirteen characters</i>.<br></div></blockquote=
><div><br></div><div>Do I really need to point out that 'T' usually isn't j=
ust 'T'? The compiler already knows the type, why should I bothered with ty=
ping it again? Also, pointer-to-member syntax isn't really userfriendly.</d=
iv><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div><br></d=
iv><div>Which is one of the big reasons why implicit capture of `this` is <=
a href=3D"http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2012/n3424.pdf=
" target=3D"_blank">very likely to go away</a>. It was a mistake, not somet=
hing to be emulated.<br></div></blockquote><div><br></div><div>You're talki=
ng about <b>implicit </b>capturing of this. With explicit capturing you sti=
ll capture the pointer, not the object. That document even talks about "'th=
is' captured by value" which implies the member is effectively captured by =
reference.</div><div> </div><blockquote class=3D"gmail_quote" style=3D=
"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex=
;"><div>Most importantly of all... what if I don't <i>want</i> to capture b=
y reference?</div></blockquote><div><br></div><div>Then use bind, or copy t=
he object by hand. This idea is simply intended if you merely want to want =
to create a callback to a member function of a class instance. I don't know=
about the codebase you're involved in, but in my personal experience you p=
retty much always want to capture the object by reference. I literally can'=
t think of any actual scenario where we wanted a copy. We always bind() wit=
h a pointer to the object.</div><div> </div><blockquote class=3D"gmail=
_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;p=
adding-left: 1ex;"><div><br></div></blockquote><blockquote class=3D"gmail_q=
uote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pad=
ding-left: 1ex;"><div>Isn't that just part of the member function signature=
? <br></div></blockquote><div><br></div><div>The second template parameter =
is just a function type (e.g., void(int)), not pointer-to-member. If I real=
ly wanted full type erasure I would've simply used std::function<void()&=
gt;, but I don't want that for more than one reason (overloading, automatic=
type deduction, equality operators, getting the 'this', etc.)</div><div>&n=
bsp;</div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_1036_9814884.1359374743590--
.
Author: Sylvester Hesp <s.hesp@oisyn.nl>
Date: Mon, 28 Jan 2013 04:10:54 -0800 (PST)
Raw View
------=_Part_552_30607353.1359375054409
Content-Type: text/plain; charset=ISO-8859-1
On Monday, January 28, 2013 3:19:45 AM UTC+1, Zhihao Yuan wrote:
>
> On Sun, Jan 27, 2013 at 7:06 PM, Sylvester Hesp <s.h...@oisyn.nl<javascript:>>
> wrote:
> > It should also be convertible to
> > member_function<T2,S> if is_base_of<T2,T>.
>
> So you are suggesting a language feature returning a library
> type, which might not be appropriate.
>
Perhaps not. Are you suggesting to change the type returned from typeid()
as well? Or what dynamic_cast throws? I've heard about putting core types
in a separate namespace, and I agree with that. In that case, this type
should be in that namespace as well.
> a.f
>
> returns a [a](...) /* mutable, if needed */ { return a.f(...); }, and the
> syntax
>
> &a.f
>
> returns a [&a](...) /* mutable, if needed */ { return a.f(...); }
>
> But this solution requires a carefully specified parameters (including
> template parameters, probably) transformation rule.
>
I thought about using some unpecified type, but I don't like not being able
to overload on specific signatures or that two occurences of the same
function and 'this' are of different types.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
------=_Part_552_30607353.1359375054409
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<br>On Monday, January 28, 2013 3:19:45 AM UTC+1, Zhihao Yuan wrote:<blockq=
uote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-lef=
t: 1px #ccc solid;padding-left: 1ex;">On Sun, Jan 27, 2013 at 7:06 PM, Sylv=
ester Hesp <<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mai=
lto=3D"BxgJgDjKUIwJ">s.h...@oisyn.nl</a>> wrote:
<br>> It should also be convertible to
<br>> member_function<T2,S> if is_base_of<T2,T>.
<br>
<br>So you are suggesting a language feature returning a library
<br>type, which might not be appropriate.
<br></blockquote><div><br></div><div>Perhaps not. Are you suggesting to cha=
nge the type returned from typeid() as well? Or what dynamic_cast throws? I=
've heard about putting core types in a separate namespace, and I agree wit=
h that. In that case, this type should be in that namespace as well.</div><=
div><br></div><div> </div><blockquote class=3D"gmail_quote" style=3D"m=
argin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"=
> a.f
<br>
<br>returns a [a](...) /* mutable, if needed */ { return a.f(...); }, and t=
he syntax
<br>
<br> &a.f
<br>
<br>returns a [&a](...) /* mutable, if needed */ { return a.f(...); }
<br>
<br>But this solution requires a carefully specified parameters (including
<br>template parameters, probably) transformation rule.
<br></blockquote><div><br></div><div>I thought about using some unpecified =
type, but I don't like not being able to overload on specific signatures or=
that two occurences of the same function and 'this' are of different types=
..</div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_552_30607353.1359375054409--
.
Author: =?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?= <mjklaim@gmail.com>
Date: Mon, 28 Jan 2013 13:46:16 +0100
Raw View
--f46d04446c01b9488404d458a999
Content-Type: text/plain; charset=ISO-8859-1
On Mon, Jan 28, 2013 at 12:40 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
> You are quite literally talking about 13 characters. You want a whole
> language feature for the sole purpose of not typing *thirteen characters*.
>
I strongly disagree with this argument because these last few days I had to
use std::bind a lot and each time it is a great pain to have to
- specify the member function type again
- specify the arguments placeholders again
It makes code really hard to read, in particular when you use it in any
observer pattern library:
SystemInstance::SystemInstance()
: // ...
{
m_on_connection_begin = m_network.on_connection_begin( boost::bind(
&SystemInstance::on_connection_begin, this, _1 ));
m_on_connection_end = m_network.on_connection_end( boost::bind(
&SystemInstance::on_connection_begin, this, _1 ));
}
This is a simplified example of what I have to write each time I want to
use boost.signals2 for example.
Did you spot the error?
Now imagine I have tens of signals to write.
Compare with:
SystemInstance::SystemInstance()
: // ...
{
m_on_connection_begin = m_network.on_connection_begin(
&this->on_connection_begin ));
m_on_connection_end = m_network.on_connection_end(
&this->on_connection_end ));
}
This can be written with a lambda but it's redundant unless we get
polymorphic and "terse syntax" lambdas:
SystemInstance::SystemInstance()
: // ...
{
m_on_connection_begin = m_network.on_connection_begin( [&](
ConnectionPtr connection ){ on_connection_begin( connection ); } ));
m_on_connection_end = m_network.on_connection_end( [&]( ConnectionPtr
connection ){ on_connection_end( connection ); } ));
}
Joel Lamotte.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
--f46d04446c01b9488404d458a999
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Mon, Jan 28, 2013 at 12:40 PM, Nicol Bolas <span dir=3D"ltr"><<a href=
=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&g=
t;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div>You are quite literally talking about 13 characters. =
You want a whole language feature for the sole purpose of not typing <i>thi=
rteen characters</i>.</div>
</blockquote></div><br>I strongly disagree with this argument because these=
last few days I had to use std::bind a lot and each time it is a great pai=
n to have to=A0</div><div class=3D"gmail_extra" style>=A0- specify the memb=
er function type again</div>
<div class=3D"gmail_extra" style>=A0- specify the arguments placeholders ag=
ain<br><br>It makes code really hard to read, in particular when you use it=
in any observer pattern library:</div><div><br></div>SystemInstance::Syste=
mInstance()<div>
=A0 =A0 : // ...<br><div>{<br>=A0 =A0 m_on_connection_begin =3D m_network.o=
n_connection_begin(=A0boost::bind( &SystemInstance::on_connection_begin=
, this, _1 ));<div>=A0 =A0 m_on_connection_end =3D m_network.on_connection_=
end(=A0boost::bind( &SystemInstance::on_connection_begin, this, _1 )); =
=A0<br>
<div>}</div><div><br></div><div style>This is a simplified example of what =
I have to write each time I want to use boost.signals2 for example.</div><d=
iv style>Did you spot the error?</div><div style><div>Now imagine I have te=
ns of signals to write.</div>
<div><br></div></div><div style>Compare with:</div><div style><br></div><di=
v style>SystemInstance::SystemInstance()<div>=A0 =A0 : // ...<br><div>{<br>=
=A0 =A0 m_on_connection_begin =3D m_network.on_connection_begin( &this-=
>on_connection_begin ));<div>
=A0 =A0 m_on_connection_end =3D m_network.on_connection_end( &this->=
on_connection_end ));=A0<br><div>}</div></div></div></div></div><div style>=
<br></div><div style>This can be written with a lambda but it's redunda=
nt unless we get polymorphic and "terse syntax" lambdas:<br>
</div><div style><br></div><div style>SystemInstance::SystemInstance()<div>=
=A0 =A0 : // ...<br><div>{<br>=A0 =A0 m_on_connection_begin =3D m_network.o=
n_connection_begin( =A0[&]( ConnectionPtr connection ){ =A0on_connectio=
n_begin( connection ); }=A0));<div>
=A0 =A0 m_on_connection_end =3D m_network.on_connection_end( =A0[&]( Co=
nnectionPtr connection ){ =A0on_connection_end( connection ); }=A0));<br><d=
iv>}</div></div></div></div><div><br></div></div><div style><div style><br>=
</div><div style>
Joel Lamotte.</div></div><div><br></div></div></div></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
--f46d04446c01b9488404d458a999--
.
Author: Nevin Liber <nliber@gmail.com>
Date: Mon, 28 Jan 2013 08:11:41 -0600
Raw View
On Jan 28, 2013, at 6:46 AM, "Klaim - Jo=EBl Lamotte" <mjklaim@gmail.com> w=
rote:
> I strongly disagree with this argument because these last few days I had =
to use std::bind a lot and each time it is a great pain to have to
> - specify the member function type again
> - specify the arguments placeholders again
>
> It makes code really hard to read, in particular when you use it in any o=
bserver pattern library:
>
> SystemInstance::SystemInstance()
> : // ...
> {
> m_on_connection_begin =3D m_network.on_connection_begin( boost::bind(=
&SystemInstance::on_connection_begin, this, _1 ));
> m_on_connection_end =3D m_network.on_connection_end( boost::bind( &Sy=
stemInstance::on_connection_begin, this, _1 ));
> }
Since you are always calling functions with the same name, why not
just create a polymorphic function object to do it now, and use
polymorphic lambdas when they get added to the language later?
I just don't see why C++14 lambdas aren't the solution to this...
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
.
Author: =?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?= <mjklaim@gmail.com>
Date: Mon, 28 Jan 2013 15:19:15 +0100
Raw View
--e89a8ff252ee48210004d459f6ba
Content-Type: text/plain; charset=ISO-8859-1
On Mon, Jan 28, 2013 at 3:11 PM, Nevin Liber <nliber@gmail.com> wrote:
> Since you are always calling functions with the same name, why not
> just create a polymorphic function object to do it now, and use
> polymorphic lambdas when they get added to the language later?
>
As I noted before, this is an error, the member function to connect is
SystemInstance::on_connection_end on the second line,
I wrote this to show that it makes code harder to read.
SystemInstance::SystemInstance()
: // ...
{
m_on_connection_begin = m_network.on_connection_begin( boost::bind(
&SystemInstance::on_connection_begin, this, _1 ));
m_on_connection_end = m_network.on_connection_end( boost::bind(
&SystemInstance::on_connection_end, this, _1 ));
}
> I just don't see why C++14 lambdas aren't the solution to this...
I don't know it depends how it ends, more or less terse, I have no idea
what is the current state of the proposal at the moment.
Anyway current lambdas are not less verbose but at least you don't have to
repeat the member function type.
Joel Lamotte
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
--e89a8ff252ee48210004d459f6ba
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Mon, Jan 28, 2013 at 3:11 PM, Nevin Liber <span dir=3D"ltr"><<a href=
=3D"mailto:nliber@gmail.com" target=3D"_blank">nliber@gmail.com</a>></sp=
an> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div id=3D":2jo">Since you are always calling functions wi=
th the same name, why not<br>
just create a polymorphic function object to do it now, and use<br>
polymorphic lambdas when they get added to the language later?</div></block=
quote></div><div class=3D"gmail_extra"><br></div>As I noted before, this is=
an error, the member function to connect is SystemInstance::on_connection_=
end on the second line,<br>
I wrote this to show that it makes code harder to read.<br></div><div class=
=3D"gmail_extra" style><br></div><div class=3D"gmail_extra" style><span sty=
le=3D"font-family:arial,sans-serif;font-size:12.727272033691406px">SystemIn=
stance::</span><span style=3D"font-family:arial,sans-serif;font-size:12.727=
272033691406px">SystemInstance()</span><div style=3D"font-family:arial,sans=
-serif;font-size:12.727272033691406px">
=A0 =A0 : // ...<br><div>{<br>=A0 =A0 m_on_connection_begin =3D m_network.o=
n_connection_begin(=A0boost::bind( &SystemInstance::on_connection_begin=
, this, _1 ));<div>=A0 =A0 m_on_connection_end =3D m_network.on_connection_=
end(=A0boost::bind( &SystemInstance::on_connection_end, this, _1 )); =
=A0<br>
<div>}</div></div></div><div><br></div><div><br></div></div></div><div clas=
s=3D"gmail_extra" style><span style=3D"font-family:arial,sans-serif;font-si=
ze:12.727272033691406px"><font color=3D"#500050"><br></font></span></div><d=
iv class=3D"gmail_extra" style>
<span style=3D"font-family:arial,sans-serif;font-size:12.727272033691406px"=
><font color=3D"#500050">>=A0</font>I just don't see why C++14 lambd=
as aren't the solution to this...</span><br></div><div class=3D"gmail_e=
xtra" style>
<span style=3D"font-family:arial,sans-serif;font-size:12.727272033691406px"=
><br></span></div><div class=3D"gmail_extra" style><font face=3D"arial, san=
s-serif">I don't know it depends how it ends, more or less terse, I hav=
e no idea what is the current state of the proposal at the moment.</font></=
div>
<div class=3D"gmail_extra" style><font face=3D"arial, sans-serif">Anyway cu=
rrent lambdas are not less verbose but at least you don't have to repea=
t the member function type.</font></div><div class=3D"gmail_extra" style><b=
r>
</div><div class=3D"gmail_extra" style><font face=3D"arial, sans-serif"><br=
></font></div><div class=3D"gmail_extra" style><font face=3D"arial, sans-se=
rif">Joel Lamotte</font></div><div class=3D"gmail_extra" style><font face=
=3D"arial, sans-serif"><br>
</font></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
--e89a8ff252ee48210004d459f6ba--
.
Author: Sylvester Hesp <s.hesp@oisyn.nl>
Date: Mon, 28 Jan 2013 06:22:05 -0800 (PST)
Raw View
------=_Part_1289_23139586.1359382925744
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Monday, January 28, 2013 3:11:41 PM UTC+1, Nevin ":-)" Liber wrote:
>
> On Jan 28, 2013, at 6:46 AM, "Klaim - Jo=EBl Lamotte" <mjk...@gmail.com<j=
avascript:>>=20
> wrote:=20
>
> > I strongly disagree with this argument because these last few days I ha=
d=20
> to use std::bind a lot and each time it is a great pain to have to=20
> > - specify the member function type again=20
> > - specify the arguments placeholders again=20
> >=20
> > It makes code really hard to read, in particular when you use it in any=
=20
> observer pattern library:=20
> >=20
> > SystemInstance::SystemInstance()=20
> > : // ...=20
> > {=20
> > m_on_connection_begin =3D m_network.on_connection_begin( boost::bin=
d(=20
> &SystemInstance::on_connection_begin, this, _1 ));=20
> > m_on_connection_end =3D m_network.on_connection_end( boost::bind(=
=20
> &SystemInstance::on_connection_begin, this, _1 ));=20
> > }=20
>
> Since you are always calling functions with the same name
I think that's just a typo. He uses different functions in the second=20
example.
=20
> , why not=20
> just create a polymorphic function object to do it now, and use=20
> polymorphic lambdas when they get added to the language later?=20
>
> I just don't see why C++14 lambdas aren't the solution to this...=20
>
Because you still need to supply and forward all the arguments. This=20
solution is even worse than simply using bind().
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/?hl=3Den.
------=_Part_1289_23139586.1359382925744
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<br><br>On Monday, January 28, 2013 3:11:41 PM UTC+1, Nevin ":-)" Liber wro=
te:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;=
border-left: 1px #ccc solid;padding-left: 1ex;">On Jan 28, 2013, at 6:46 AM=
, "Klaim - Jo=EBl Lamotte" <<a href=3D"javascript:" target=3D"_blank" gd=
f-obfuscated-mailto=3D"E6Uy0xUHceAJ">mjk...@gmail.com</a>> wrote:
<br>
<br>> I strongly disagree with this argument because these last few days=
I had to use std::bind a lot and each time it is a great pain to have to
<br>> - specify the member function type again
<br>> - specify the arguments placeholders again
<br>>
<br>> It makes code really hard to read, in particular when you use it i=
n any observer pattern library:
<br>>
<br>> SystemInstance::<wbr>SystemInstance()
<br>> : // ...
<br>> {
<br>> m_on_connection_begin =3D m_network.on_connection_be=
gin( boost::bind( &SystemInstance::on_<wbr>connection_begin, this, _1 )=
);
<br>> m_on_connection_end =3D m_network.on_connection_end(=
boost::bind( &SystemInstance::on_<wbr>connection_begin, this, _1 ));
<br>> }
<br>
<br>Since you are always calling functions with the same name</blockquote><=
div><br></div><div>I think that's just a typo. He uses different functions =
in the second example.</div><div> </div><blockquote class=3D"gmail_quo=
te" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddi=
ng-left: 1ex;">, why not
<br>just create a polymorphic function object to do it now, and use
<br>polymorphic lambdas when they get added to the language later?
<br>
<br>I just don't see why C++14 lambdas aren't the solution to this...
<br></blockquote><div><br></div><div>Because you still need to supply and f=
orward all the arguments. This solution is even worse than simply using bin=
d().</div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
To unsubscribe from this group, send email to std-proposals+unsubscribe@iso=
cpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_1289_23139586.1359382925744--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Mon, 28 Jan 2013 16:25:55 +0200
Raw View
On 28 January 2013 16:22, Sylvester Hesp <s.hesp@oisyn.nl> wrote:
>> I just don't see why C++14 lambdas aren't the solution to this...
> Because you still need to supply and forward all the arguments. This
> solution is even worse than simply using bind().
Wouldn't a polymorphic lambda allow a pack as its argument?
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To post to this group, send email to std-proposals@isocpp.org.
To unsubscribe from this group, send email to std-proposals+unsubscribe@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Mon, 28 Jan 2013 16:51:01 -0800 (PST)
Raw View
------=_Part_1588_7752917.1359420661645
Content-Type: text/plain; charset=ISO-8859-1
On Monday, January 28, 2013 6:25:55 AM UTC-8, Ville Voutilainen wrote:
>
> On 28 January 2013 16:22, Sylvester Hesp <s.h...@oisyn.nl <javascript:>>
> wrote:
> >> I just don't see why C++14 lambdas aren't the solution to this...
> > Because you still need to supply and forward all the arguments. This
> > solution is even worse than simply using bind().
>
> Wouldn't a polymorphic lambda allow a pack as its argument?
>
Not with the current proposal<http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2012/n3418.pdf>.
It *should* be there, and I would consider the current lack of the feature
to be a deal-breaker. But it isn't there now.
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en.
------=_Part_1588_7752917.1359420661645
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Monday, January 28, 2013 6:25:55 AM UTC-8, Ville Voutilainen wrote:<bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-l=
eft: 1px #ccc solid;padding-left: 1ex;">On 28 January 2013 16:22, Sylvester=
Hesp <<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=
=3D"9qeEVW5oLdIJ">s.h...@oisyn.nl</a>> wrote:
<br>>> I just don't see why C++14 lambdas aren't the solution to this=
....
<br>> Because you still need to supply and forward all the arguments. Th=
is
<br>> solution is even worse than simply using bind().
<br>
<br>Wouldn't a polymorphic lambda allow a pack as its argument?
<br></blockquote><div><br>Not with the <a href=3D"http://www.open-std.org/J=
TC1/SC22/WG21/docs/papers/2012/n3418.pdf">current proposal</a>. It <i>shoul=
d</i> be there, and I would consider the current lack of the feature to be =
a deal-breaker. But it isn't there now.<br></div>
<p></p>
-- <br />
<br />
--- <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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_1588_7752917.1359420661645--
.