Hi,

On the Qt development mailing lists we're currently discussing the pros and
cons of member functions vs. free functions. One thing that came up there is
that member functions, if not inline(d), force the object into memory by way
of passing *this by reference (pointer). A free function otoh, can choose to
take the same parameter by value, which means that it may be passed in
registers.

Chandler has included this example in his BoostCon 2013 talk, too:
Larger context:
https://youtu.be/eR34r7HOU14?t=2021
Actual example:
https://youtu.be/eR34r7HOU14?t=3821

So, I thought, why not add a mechanism by which a class author can indicate
that *this should be passed by value?

Here's Chandler's example rewritten:

  struct S {
      float x, y, z;
      double compute() const =; // internally: double S::compute(S this)
      // = mickicks:
      double compute2() const &; // *this is lvalue reference
      double compute2() &&;      // *this is rvalue reference
  };

  double f() {
      S s;
      // ...
      s.compute(); // efficient now, S not forced into memory, can be passed
                   // in four registers (on most architectures)
  }

There are a lot of open ends here, of course, but you should get the idea.
Should I turn this into a proposal?

Thanks,
Marc

--
Marc Mutz <marc.mutz@kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt, C++ and OpenGL Experts

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

.

------=_Part_4194_1576677630.1490394909376
Content-Type: multipart/alternative;
 boundary="----=_Part_4195_1962882302.1490394909377"

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

On Friday, March 24, 2017 at 7:20:17 AM UTC-7, Marc Mutz wrote:
>
> Hi,=20
>
> On the Qt development mailing lists we're currently discussing the pros=
=20
> and=20
> cons of member functions vs. free functions. One thing that came up there=
=20
> is=20
> that member functions, if not inline(d), force the object into memory by=
=20
> way=20
> of passing *this by reference (pointer). A free function otoh, can choose=
=20
> to=20
> take the same parameter by value, which means that it may be passed in=20
> registers. [...]
> So, I thought, why not add a mechanism by which a class author can=20
> indicate=20
> that *this should be passed by value?=20
>
>   struct S {=20
>       float x, y, z;=20
>       double compute() const =3D; // internally: double S::compute(S this=
)=20
>   };=20
>
> There are a lot of open ends here, of course, but you should get the idea=
..=20
> Should I turn this into a proposal?=20
>

Seems like a nifty idea to me. Loose ends include:
- This obviously is redundant with Unified Function Call Syntax, in case=20
that idea isn't totally dead yet.
- I encourage you to find some alternative syntaxes to that dangling "=3D"=
=20
sign. Even if it doesn't confuse the grammar, it's confusing to me as a=20
reader.
- When is the temporary *this constructed, and when is it destroyed? (This=
=20
might be obvious; I'm not sure.)
- Virtual functions mustn't be by-value.
- Member functions of abstract classes mustn't be by-value.
- What would it mean to mark a member function by-value *and* const? Is the=
=20
const qualifier ignored in that case?
- By-value member functions presumably shouldn't be allowed to call=20
non-by-value member functions, is that right?

*Arguably*, the entire idea is a bad one. You're proposing that I be=20
allowed to write a method call

    myobj.mymethod();

where the code inside mymethod does not interact with the object named=20
myobj at all!  This feels like a horrible subversion of traditional OO=20
practice... and after all, "traditional OO practice" is the only reason C++=
=20
supports member functions to begin with. (Otherwise we'd all use free=20
functions all the time. The STL is only lately catching up to the=20
free-function bandwagon with templates like std::begin and std::size, but I=
=20
don't doubt it'll get there eventually.)
Now, I'm not saying that I personally feel *strongly* in that direction.=20
But I'm sure a fair number of people do, so your proposal should explain=20
the complaint and then figure out a defense against it.

=E2=80=93Arthur

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

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

<div dir=3D"ltr">On Friday, March 24, 2017 at 7:20:17 AM UTC-7, Marc Mutz w=
rote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;">Hi,
<br>
<br>On the Qt development mailing lists we&#39;re currently discussing the =
pros and=20
<br>cons of member functions vs. free functions. One thing that came up the=
re is=20
<br>that member functions, if not inline(d), force the object into memory b=
y way=20
<br>of passing *this by reference (pointer). A free function otoh, can choo=
se to=20
<br>take the same parameter by value, which means that it may be passed in=
=20
<br>registers. [...]<br>So, I thought, why not add a mechanism by which a c=
lass author can indicate=20
<br>that *this should be passed by value?
<br>
<br>=C2=A0 struct S {
<br>=C2=A0 =C2=A0 =C2=A0 float x, y, z;
<br>=C2=A0 =C2=A0 =C2=A0 double compute() const =3D; // internally: double =
S::compute(S this)
<br>=C2=A0 };
<br><br>There are a lot of open ends here, of course, but you should get th=
e idea.=20
<br>Should I turn this into a proposal?
<br></blockquote><div><br></div><div>Seems like a nifty idea to me. Loose e=
nds include:</div><div>- This obviously is redundant with Unified Function =
Call Syntax, in case that idea isn&#39;t totally dead yet.</div><div>- I en=
courage you to find some alternative syntaxes to that dangling &quot;=3D&qu=
ot; sign. Even if it doesn&#39;t confuse the grammar, it&#39;s confusing to=
 me as a reader.</div><div>- When is the temporary *this constructed, and w=
hen is it destroyed? (This might be obvious; I&#39;m not sure.)</div><div>-=
 Virtual functions mustn&#39;t be by-value.</div><div>- Member functions of=
 abstract classes mustn&#39;t be by-value.</div><div>- What would it mean t=
o mark a member function by-value *and* const? Is the const qualifier ignor=
ed in that case?</div><div>- By-value member functions presumably shouldn&#=
39;t be allowed to call non-by-value member functions, is that right?</div>=
<div><br></div><div><i>Arguably</i>, the entire idea is a bad one. You&#39;=
re proposing that I be allowed to write a method call</div><div><br></div><=
div>=C2=A0 =C2=A0 myobj.mymethod();</div><div><br></div><div>where the code=
 inside mymethod does not interact with the object named myobj at all! =C2=
=A0This feels like a horrible subversion of traditional OO practice... and =
after all, &quot;traditional OO practice&quot; is the only reason C++ suppo=
rts member functions to begin with. (Otherwise we&#39;d all use free functi=
ons all the time. The STL is only lately catching up to the free-function b=
andwagon with templates like std::begin and std::size, but I don&#39;t doub=
t it&#39;ll get there eventually.)</div><div>Now, I&#39;m not saying that I=
 personally feel <i>strongly</i> in that direction. But I&#39;m sure a fair=
 number of people do, so your proposal should explain the complaint and the=
n figure out a defense against it.</div><div><br></div><div>=E2=80=93Arthur=
</div></div>

<p></p>

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

------=_Part_4195_1962882302.1490394909377--

------=_Part_4194_1576677630.1490394909376--

.

On sexta-feira, 24 de mar=C3=A7o de 2017 15:35:09 PDT Arthur O'Dwyer wrote:
> Seems like a nifty idea to me. Loose ends include:
> - This obviously is redundant with Unified Function Call Syntax, in case
> that idea isn't totally dead yet.

True, but it seems it is dead...

> - I encourage you to find some alternative syntaxes to that dangling "=3D=
"
> sign. Even if it doesn't confuse the grammar, it's confusing to me as a
> reader.

And clashes with "=3D 0" for pure virtuals. Even though passing a polymorph=
ic=20
type by value is probably a bad idea, someone may want it.

> - When is the temporary *this constructed, and when is it destroyed? (Thi=
s
> might be obvious; I'm not sure.)

I'd expect the same rules as if it were an implicit parameter, which is the=
=20
same as the Unified Function Call syntax.

> - Virtual functions mustn't be by-value.
> - Member functions of abstract classes mustn't be by-value.

To both: Why not? Sure, it's a bad idea, but any strict reason why not?

> - What would it mean to mark a member function by-value *and* const? Is t=
he
> const qualifier ignored in that case?

It's indeed redundant, since you're clearly not modifying the original. But=
=20
having that "const" there can help the eyes.

Another question: what should *this be in that function? Should it be const=
 or=20
not?

> - By-value member functions presumably shouldn't be allowed to call
> non-by-value member functions, is that right?

I don't see why. They can call, but the object modified is obviously the co=
py,=20
not the original.

> *Arguably*, the entire idea is a bad one. You're proposing that I be
> allowed to write a method call
>=20
>     myobj.mymethod();
>=20
> where the code inside mymethod does not interact with the object named
> myobj at all!  This feels like a horrible subversion of traditional OO
> practice... and after all, "traditional OO practice" is the only reason C=
++
> supports member functions to begin with. (Otherwise we'd all use free
> functions all the time. The STL is only lately catching up to the
> free-function bandwagon with templates like std::begin and std::size, but=
 I
> don't doubt it'll get there eventually.)

Well, it did interact with myobj, when you created a copy.

The point is that most const member functions will not modify the object, s=
o=20
it hardly matters to them if they receive a pointer to the original or if i=
t's=20
an identical copy. But it does matter for performance and code optimisation=
:=20
passing by value in registers is more efficient, plus the compiler knows fo=
r a=20
fact the original was not modified, so it can optimise the code that follow=
s on=20
that assumption.

> Now, I'm not saying that I personally feel *strongly* in that direction.
> But I'm sure a fair number of people do, so your proposal should explain
> the complaint and then figure out a defense against it.

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

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

.