Topic: const T* operator->() const
Author: mobiphil <mobi@mobiphil.com>
Date: Mon, 2 Feb 2015 06:27:24 -0800 (PST)
Raw View
------=_Part_3715_1369852134.1422887244175
Content-Type: multipart/alternative;
boundary="----=_Part_3716_2080120298.1422887244175"
------=_Part_3716_2080120298.1422887244175
Content-Type: text/plain; charset=UTF-8
*Problem*: compiler does not paste const operator -> when used to refer to
a const method
*Proposal: *well, fix it
*Context*: Thought a trivial solution for cow, but does not work. The idea
was to have a Cow wrapper template around the classes used in my system.
The protocol would be: if a non const method is called on the object then a
copy is made (if necessary), otherwise just call the method. The idea was
to play with pair of const and nonconst operator->
So, in the example below, I thought for a moment that when writing
a->constFunc() for non const object the const "->" operator would be chosen
by the compiler as constFunc() is const, but had to conclude that it is not
the case.
What is your opinion? Was my expectation completely wrong. If was not
wrong, could this make subject of a proposal?
thanks for your feedback
#include <cstdio>
template<class T>
class Cow {
private:
T* ptr;
public:
T* operator->() {
printf("-> called\n") ;
}
const T* operator->() const {
printf("const -> called\n") ;
}
};
class A {
public:
void func() {};
void constFunc() const {};
};
int main()
{
Cow<A> a = Cow<A>();
a->constFunc(); /* as constFunc is const, would expect the operator->
const to be used*/
const Cow<A> ca = Cow<A>();
ca->constFunc(); /* well, this one uses the const operator -> */
}
--
---
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/.
------=_Part_3716_2080120298.1422887244175
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><b>Problem</b>: compiler does not paste const operato=
r -> when used to refer to a const method</div><div><b>Proposal: </b>wel=
l, fix it</div><div><br></div><div><b>Context</b>: Thought a trivial soluti=
on for cow, but does not work. The idea was to have a Cow wrapper template =
around the classes used in my system. The protocol would be: if a non const=
method is called on the object then a copy is made (if necessary), otherwi=
se just call the method. The idea was to play with pair of const and noncon=
st operator-></div><div><br></div><div>So, in the example below, I thoug=
ht for a moment that when writing a->constFunc() for non const object th=
e const "->" operator would be chosen by the compiler as constFunc() is =
const, but had to conclude that it is not the case.<br><br>What is your opi=
nion? Was my expectation completely wrong. If was not wrong, could this mak=
e subject of a proposal?<br><br></div><div>thanks for your feedback</div><d=
iv><br></div><div><div class=3D"prettyprint" style=3D"border: 1px solid rgb=
(187, 187, 187); word-wrap: break-word; background-color: rgb(250, 250, 250=
);"><code class=3D"prettyprint"><div class=3D"subprettyprint"><div class=3D=
"subprettyprint"><font color=3D"#000000">#include <cstdio></font></di=
v><div class=3D"subprettyprint"><font color=3D"#000000"><br></font></div><d=
iv class=3D"subprettyprint"><font color=3D"#000000">template<class T>=
</font></div><div class=3D"subprettyprint"><font color=3D"#000000">class Co=
w {</font></div><div class=3D"subprettyprint"><font color=3D"#000000"> =
; private:</font></div><div class=3D"subprettyprint"><font color=3D"#=
000000"> T* ptr;</font></div><div class=3D"subprettypri=
nt"><font color=3D"#000000"> public:</font></div><div class=3D"=
subprettyprint"><font color=3D"#000000"><br></font></div><div class=3D"subp=
rettyprint"><font color=3D"#000000"> T* operator->()=
{</font></div><div class=3D"subprettyprint"><font color=3D"#000000"> =
printf("-> called\n") ;</font></div><d=
iv class=3D"subprettyprint"><font color=3D"#000000"> }<=
/font></div><div class=3D"subprettyprint"><font color=3D"#000000"> &n=
bsp; const T* operator->() const {</font></div><div class=3D"subp=
rettyprint"><font color=3D"#000000"> print=
f("const -> called\n") ;</font></div><div class=3D"subprettyprint"=
><font color=3D"#000000"> }</font></div><div class=3D"s=
ubprettyprint"><font color=3D"#000000">};</font></div><div class=3D"subpret=
typrint"><font color=3D"#000000"><br></font></div><div class=3D"subprettypr=
int"><font color=3D"#000000">class A {</font></div><div class=3D"subprettyp=
rint"><font color=3D"#000000"> public:</font></div><div class=
=3D"subprettyprint"><font color=3D"#000000"> void func(=
) {};</font></div><div class=3D"subprettyprint"><font color=3D"#000000">&nb=
sp; void constFunc() const {};</font></div><div class=
=3D"subprettyprint"><font color=3D"#000000">};</font></div><div class=3D"su=
bprettyprint"><font color=3D"#000000"><br></font></div><div class=3D"subpre=
ttyprint"><font color=3D"#000000"><br></font></div><div class=3D"subprettyp=
rint"><font color=3D"#000000">int main()</font></div><div class=3D"subprett=
yprint"><font color=3D"#000000">{</font></div><div class=3D"subprettyprint"=
><font color=3D"#000000"> Cow<A> a =3D Cow<A>();</f=
ont></div><div class=3D"subprettyprint"><font color=3D"#000000"> &nbs=
p;a->constFunc(); /* as constFunc is const, would expect the operator-&g=
t; const to be used*/</font></div><div class=3D"subprettyprint"><font color=
=3D"#000000"><br></font></div><div class=3D"subprettyprint"><font color=3D"=
#000000"> const Cow<A> ca =3D Cow<A>();</font></div=
><div class=3D"subprettyprint"><font color=3D"#000000"> ca->=
constFunc(); /* well, this one uses the const operator -> */</font></div=
><div class=3D"subprettyprint"><font color=3D"#000000">}</font></div><div s=
tyle=3D"color: rgb(0, 0, 0);"><br></div><br><br><br></div></code></div><br>=
<br></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 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_3716_2080120298.1422887244175--
------=_Part_3715_1369852134.1422887244175--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Mon, 2 Feb 2015 16:39:47 +0200
Raw View
On 2 February 2015 at 16:27, mobiphil <mobi@mobiphil.com> wrote:
> Problem: compiler does not paste const operator -> when used to refer to a
> const method
> Proposal: well, fix it
>
> Context: Thought a trivial solution for cow, but does not work. The idea was
> to have a Cow wrapper template around the classes used in my system. The
> protocol would be: if a non const method is called on the object then a copy
> is made (if necessary), otherwise just call the method. The idea was to play
> with pair of const and nonconst operator->
>
> So, in the example below, I thought for a moment that when writing
> a->constFunc() for non const object the const "->" operator would be chosen
> by the compiler as constFunc() is const, but had to conclude that it is not
> the case.
>
> What is your opinion? Was my expectation completely wrong. If was not wrong,
> could this make subject of a proposal?
>
> thanks for your feedback
>
> #include <cstdio>
>
> template<class T>
> class Cow {
> private:
> T* ptr;
> public:
>
> T* operator->() {
> printf("-> called\n") ;
> }
> const T* operator->() const {
> printf("const -> called\n") ;
> }
> };
>
> class A {
> public:
> void func() {};
> void constFunc() const {};
> };
>
>
> int main()
> {
> Cow<A> a = Cow<A>();
> a->constFunc(); /* as constFunc is const, would expect the operator->
> const to be used*/
>
> const Cow<A> ca = Cow<A>();
> ca->constFunc(); /* well, this one uses the const operator -> */
> }
Your expectation is wrong. What the result of an operator-> is used to
access doesn't
affect the overload resolution of operator-> itself, so the first case
with a non-const Cow<A>
will use the non-const Cow<A>::operator->.
--
---
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/.
.
Author: mobiphil <mobi@mobiphil.com>
Date: Mon, 2 Feb 2015 08:32:42 -0800 (PST)
Raw View
------=_Part_1257_345340019.1422894762945
Content-Type: multipart/alternative;
boundary="----=_Part_1258_1628885139.1422894762946"
------=_Part_1258_1628885139.1422894762946
Content-Type: text/plain; charset=UTF-8
On Monday, February 2, 2015 at 3:39:49 PM UTC+1, Ville Voutilainen wrote:
>
> On 2 February 2015 at 16:27, mobiphil <mo...@mobiphil.com <javascript:>>
> wrote:
> > Problem: compiler does not paste const operator -> when used to refer to
> a
> > const method
> > Proposal: well, fix it
> >
> > Context: Thought a trivial solution for cow, but does not work. The idea
> was
> > to have a Cow wrapper template around the classes used in my system. The
> > protocol would be: if a non const method is called on the object then a
> copy
> > is made (if necessary), otherwise just call the method. The idea was to
> play
> > with pair of const and nonconst operator->
> >
> > So, in the example below, I thought for a moment that when writing
> > a->constFunc() for non const object the const "->" operator would be
> chosen
> > by the compiler as constFunc() is const, but had to conclude that it is
> not
> > the case.
> >
> > What is your opinion? Was my expectation completely wrong. If was not
> wrong,
> > could this make subject of a proposal?
> >
> > thanks for your feedback
> >
> > #include <cstdio>
> >
> > template<class T>
> > class Cow {
> > private:
> > T* ptr;
> > public:
> >
> > T* operator->() {
> > printf("-> called\n") ;
> > }
> > const T* operator->() const {
> > printf("const -> called\n") ;
> > }
> > };
> >
> > class A {
> > public:
> > void func() {};
> > void constFunc() const {};
> > };
> >
> >
> > int main()
> > {
> > Cow<A> a = Cow<A>();
> > a->constFunc(); /* as constFunc is const, would expect the operator->
> > const to be used*/
> >
> > const Cow<A> ca = Cow<A>();
> > ca->constFunc(); /* well, this one uses the const operator -> */
> > }
>
>
> Your expectation is wrong. What the result of an operator-> is used to
> access doesn't
> affect the overload resolution of operator-> itself, so the first case
> with a non-const Cow<A>
> will use the non-const Cow<A>::operator->.
>
Thanks, but the compiler reasoned for me from his point of view and told me
that as far he learned my expectation was wrong.
The question about the expectation was not in the context of "is" state of
the compiler, but about extending the language as most of the proposals are
about.
Given the construct above, I would find it very valuable if the compiler
could deduce the operator based on the right hand. Well of course this
would mean a bit of change in the semantics of operators, etc.
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_1258_1628885139.1422894762946
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Monday, February 2, 2015 at 3:39:49 PM UTC+1, V=
ille Voutilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2 Fe=
bruary 2015 at 16:27, mobiphil <<a href=3D"javascript:" target=3D"_blank=
" gdf-obfuscated-mailto=3D"fJrOJ85OIEoJ" rel=3D"nofollow" onmousedown=3D"th=
is.href=3D'javascript:';return true;" onclick=3D"this.href=3D'javascript:';=
return true;">mo...@mobiphil.com</a>> wrote:
<br>> Problem: compiler does not paste const operator -> when used to=
refer to a
<br>> const method
<br>> Proposal: well, fix it
<br>>
<br>> Context: Thought a trivial solution for cow, but does not work. Th=
e idea was
<br>> to have a Cow wrapper template around the classes used in my syste=
m. The
<br>> protocol would be: if a non const method is called on the object t=
hen a copy
<br>> is made (if necessary), otherwise just call the method. The idea w=
as to play
<br>> with pair of const and nonconst operator->
<br>>
<br>> So, in the example below, I thought for a moment that when writing
<br>> a->constFunc() for non const object the const "->" operator =
would be chosen
<br>> by the compiler as constFunc() is const, but had to conclude that =
it is not
<br>> the case.
<br>>
<br>> What is your opinion? Was my expectation completely wrong. If was =
not wrong,
<br>> could this make subject of a proposal?
<br>>
<br>> thanks for your feedback
<br>>
<br>> #include <cstdio>
<br>>
<br>> template<class T>
<br>> class Cow {
<br>> private:
<br>> T* ptr;
<br>> public:
<br>>
<br>> T* operator->() {
<br>> printf("-> called\n") ;
<br>> }
<br>> const T* operator->() const {
<br>> printf("const -> called\n") &=
nbsp;;
<br>> }
<br>> };
<br>>
<br>> class A {
<br>> public:
<br>> void func() {};
<br>> void constFunc() const {};
<br>> };
<br>>
<br>>
<br>> int main()
<br>> {
<br>> Cow<A> a =3D Cow<A>();
<br>> a->constFunc(); /* as constFunc is const, would ex=
pect the operator->
<br>> const to be used*/
<br>>
<br>> const Cow<A> ca =3D Cow<A>();
<br>> ca->constFunc(); /* well, this one uses the const =
operator -> */
<br>> }
<br>
<br>
<br>Your expectation is wrong. What the result of an operator-> is used =
to
<br>access doesn't
<br>affect the overload resolution of operator-> itself, so the first ca=
se
<br>with a non-const Cow<A>
<br>will use the non-const Cow<A>::operator->.
<br></blockquote><div><br></div><div>Thanks, but the compiler reasoned for =
me from his point of view and told me that as far he learned my expectation=
was wrong.<br></div><div><br></div><div>The question about the expectation=
was not in the context of "is" state of the compiler, but about extending =
the language as most of the proposals are about. </div><div><br></div>=
<div>Given the construct above, I would find it very valuable if the compil=
er could deduce the operator based on the right hand. Well of course this w=
ould mean a bit of change in the semantics of operators, etc.</div><div><br=
></div><div><br></div><div><br></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 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_1258_1628885139.1422894762946--
------=_Part_1257_345340019.1422894762945--
.
Author: Arthur O'Dwyer <arthur.j.odwyer@gmail.com>
Date: Mon, 2 Feb 2015 14:58:35 -0800 (PST)
Raw View
------=_Part_2929_310117292.1422917915931
Content-Type: multipart/alternative;
boundary="----=_Part_2930_198515375.1422917915931"
------=_Part_2930_198515375.1422917915931
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Monday, February 2, 2015 at 8:32:43 AM UTC-8, mobiphil wrote:
>
> On Monday, February 2, 2015 at 3:39:49 PM UTC+1, Ville Voutilainen wrote:
>>
>> On 2 February 2015 at 16:27, mobiphil <mo...@mobiphil.com> wrote:=20
>> > Problem: compiler does not paste const operator -> when used to refer=
=20
>> to a=20
>> > const method=20
>> > Proposal: well, fix it=20
>> >=20
>> > Context: Thought a trivial solution for cow, but does not work. The=20
>> idea was=20
>> > to have a Cow wrapper template around the classes used in my system.=
=20
>> The=20
>> > protocol would be: if a non const method is called on the object then =
a=20
>> copy=20
>> > is made (if necessary), otherwise just call the method. The idea was t=
o=20
>> play=20
>> > with pair of const and nonconst operator->=20
>> >=20
>> > So, in the example below, I thought for a moment that when writing=20
>> > a->constFunc() for non const object the const "->" operator would be=
=20
>> chosen=20
>> > by the compiler as constFunc() is const, but had to conclude that it i=
s=20
>> not=20
>> > the case.
>
>
Indeed, your expectation was simply wrong.
Consider:
class Foo {
void member();
void member() const;
void member() volatile;
};
Foo foo; foo->member(); // calls the non-`const` version
const Foo cfoo; cfoo->member(); // calls the `const` version
volatile Foo vfoo; vfoo->member(); // calls the `volatile` version
Furthermore, you've forgotten that it's possible to overload operator->=20
(possibly with const and non-const versions) so that you don't even know=20
what context to look up member in, until you've resolved which operator->=
=20
is being called.
class Widget {
Foo* operator-> () const;
void member();
};
Widget w; w->member(); // calls Widget::member()
const Widget cw; cw->member(); // calls Widget::operator->() followed by=
=20
Foo::member()
HTH,
=E2=80=93Arthur
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_2930_198515375.1422917915931
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Monday, February 2, 2015 at 8:32:43 AM UTC-8, m=
obiphil wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"=
>On Monday, February 2, 2015 at 3:39:49 PM UTC+1, Ville Voutilainen wrote:<=
blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border=
-left:1px #ccc solid;padding-left:1ex">On 2 February 2015 at 16:27, mobiphi=
l <<a rel=3D"nofollow">mo...@mobiphil.com</a>> wrote:
<br>> Problem: compiler does not paste const operator -> when used to=
refer to a
<br>> const method
<br>> Proposal: well, fix it
<br>>
<br>> Context: Thought a trivial solution for cow, but does not work. Th=
e idea was
<br>> to have a Cow wrapper template around the classes used in my syste=
m. The
<br>> protocol would be: if a non const method is called on the object t=
hen a copy
<br>> is made (if necessary), otherwise just call the method. The idea w=
as to play
<br>> with pair of const and nonconst operator->
<br>>
<br>> So, in the example below, I thought for a moment that when writing
<br>> a->constFunc() for non const object the const "->" operator =
would be chosen
<br>> by the compiler as constFunc() is const, but had to conclude that =
it is not
<br>> the case.</blockquote></div></blockquote><div><br></div><div>Indee=
d, your expectation was simply wrong.</div><div>Consider:</div><div><br></d=
iv><div class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250)=
; border: 1px solid rgb(187, 187, 187); word-wrap: break-word;"><code class=
=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #008;"=
class=3D"styled-by-prettify">class</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"styl=
ed-by-prettify">Foo</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br> =
; </span><span style=3D"color: #008;" class=3D"styled-by-prettify">v=
oid</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> member=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">();</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"><br> =
</span><span style=3D"color: #008;" class=3D"styled-by-prettify">void</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> member</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">()</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"col=
or: #008;" class=3D"styled-by-prettify">const</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"><br> </span><span style=3D"color: #0=
08;" class=3D"styled-by-prettify">void</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> member</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">()</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-pr=
ettify">volatile</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br=
></span><span style=3D"color: #660;" class=3D"styled-by-prettify">};</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br></span><s=
pan style=3D"color: #606;" class=3D"styled-by-prettify">Foo</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> foo</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> foo</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">-></span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">member</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: #800;" class=3D"styled-by-=
prettify">// calls the non-`const` version</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" cla=
ss=3D"styled-by-prettify">const</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"styled-b=
y-prettify">Foo</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> cfoo</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> cfoo</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">-></span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify">member</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: #800;" class=3D"styled-by-prettify">// calls the `const` version</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><s=
pan style=3D"color: #008;" class=3D"styled-by-prettify">volatile</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #606;" class=3D"styled-by-prettify">Foo</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> vfoo</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> vfoo</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">-></span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify">member</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">();</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> </span><span style=3D"color: #800;" class=3D"styled-by-prettify=
">// calls the `volatile` version</span></div></code></div><div><br>Further=
more, you've forgotten that it's possible to overload <font face=3D"courier=
new, monospace">operator-></font> (possibly with const and non-const ve=
rsions) so that you don't even know what context to look up member in, unti=
l you've resolved which <font face=3D"courier new, monospace">operator->=
</font> is being called.</div><div><br></div><div class=3D"prettyprint" sty=
le=3D"background-color: rgb(250, 250, 250); border: 1px solid rgb(187, 187,=
187); word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"su=
bprettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettify">cla=
ss</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span>=
<span style=3D"color: #606;" class=3D"styled-by-prettify">Widget</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"><br> </span><span style=
=3D"color: #606;" class=3D"styled-by-prettify">Foo</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: #008;" class=
=3D"styled-by-prettify">operator</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">-></span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">()</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">const</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"><br> </s=
pan><span style=3D"color: #008;" class=3D"styled-by-prettify">void</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> member</span><span=
style=3D"color: #660;" class=3D"styled-by-prettify">();</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">};</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"><br><br></span><span style=3D"color: #606;=
" class=3D"styled-by-prettify">Widget</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> w</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> w</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">-></span><span style=3D"color: #000;" class=3D"styled-by-prettify">mem=
ber</span><span style=3D"color: #660;" class=3D"styled-by-prettify">();</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span>=
<span style=3D"color: #800;" class=3D"styled-by-prettify">// calls Widget::=
member()</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><b=
r></span><span style=3D"color: #008;" class=3D"styled-by-prettify">const</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span=
style=3D"color: #606;" class=3D"styled-by-prettify">Widget</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> cw</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> cw</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">-></span><span style=3D"color: #000;" class=3D=
"styled-by-prettify">member</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">();</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> </span><span style=3D"color: #800;" class=3D"styled-by-pre=
ttify">// calls Widget::operator->() followed by Foo::member()</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"><br></span></div></c=
ode></div><div><br></div><div>HTH,</div><div>=E2=80=93Arthur<br></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 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_2930_198515375.1422917915931--
------=_Part_2929_310117292.1422917915931--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Tue, 3 Feb 2015 10:40:19 -0800 (PST)
Raw View
------=_Part_5159_94414491.1422988819657
Content-Type: multipart/alternative;
boundary="----=_Part_5160_1981418751.1422988819657"
------=_Part_5160_1981418751.1422988819657
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Monday, February 2, 2015 at 5:58:36 PM UTC-5, Arthur O'Dwyer wrote:
>
>
>
> On Monday, February 2, 2015 at 8:32:43 AM UTC-8, mobiphil wrote:
>>
>> On Monday, February 2, 2015 at 3:39:49 PM UTC+1, Ville Voutilainen wrote=
:
>>>
>>> On 2 February 2015 at 16:27, mobiphil <mo...@mobiphil.com> wrote:=20
>>> > Problem: compiler does not paste const operator -> when used to refer=
=20
>>> to a=20
>>> > const method=20
>>> > Proposal: well, fix it=20
>>> >=20
>>> > Context: Thought a trivial solution for cow, but does not work. The=
=20
>>> idea was=20
>>> > to have a Cow wrapper template around the classes used in my system.=
=20
>>> The=20
>>> > protocol would be: if a non const method is called on the object then=
=20
>>> a copy=20
>>> > is made (if necessary), otherwise just call the method. The idea was=
=20
>>> to play=20
>>> > with pair of const and nonconst operator->=20
>>> >=20
>>> > So, in the example below, I thought for a moment that when writing=20
>>> > a->constFunc() for non const object the const "->" operator would be=
=20
>>> chosen=20
>>> > by the compiler as constFunc() is const, but had to conclude that it=
=20
>>> is not=20
>>> > the case.
>>
>>
> Indeed, your expectation was simply wrong.
> Consider:
>
> class Foo {
> void member();
> void member() const;
> void member() volatile;
> };
>
> Foo foo; foo->member(); // calls the non-`const` version
> const Foo cfoo; cfoo->member(); // calls the `const` version
> volatile Foo vfoo; vfoo->member(); // calls the `volatile` version
>
> Furthermore, you've forgotten that it's possible to overload operator->=
=20
> (possibly with const and non-const versions) so that you don't even know=
=20
> what context to look up member in, until you've resolved which operator->=
=20
> is being called.
>
> class Widget {
> Foo* operator-> () const;
> void member();
> };
>
> Widget w; w->member(); // calls Widget::member()
> const Widget cw; cw->member(); // calls Widget::operator->() followed by=
=20
> Foo::member()
>
> HTH,
> =E2=80=93Arthur
>
Um, I'm fairly sure that's not true <http://ideone.com/e.js/qNI9Ky>. You=20
can call const member functions from a non-const object. It's the other way=
=20
around that doesn't work. So the first one will call Foo::member, just like=
=20
the second.
And even if you did it the right way around, it would be a *compile error*.=
=20
Due to attempting to call a non-const member function on a const object.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_5160_1981418751.1422988819657
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Monday, February 2, 2015 at 5:58:36 PM UTC-5, A=
rthur O'Dwyer wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;ma=
rgin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><br><br>On Monday, February 2, 2015 at 8:32:43 AM UTC-8, mobiphil =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">On Monday, F=
ebruary 2, 2015 at 3:39:49 PM UTC+1, Ville Voutilainen wrote:<blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #cc=
c solid;padding-left:1ex">On 2 February 2015 at 16:27, mobiphil <<a rel=
=3D"nofollow">mo...@mobiphil.com</a>> wrote:
<br>> Problem: compiler does not paste const operator -> when used to=
refer to a
<br>> const method
<br>> Proposal: well, fix it
<br>>
<br>> Context: Thought a trivial solution for cow, but does not work. Th=
e idea was
<br>> to have a Cow wrapper template around the classes used in my syste=
m. The
<br>> protocol would be: if a non const method is called on the object t=
hen a copy
<br>> is made (if necessary), otherwise just call the method. The idea w=
as to play
<br>> with pair of const and nonconst operator->
<br>>
<br>> So, in the example below, I thought for a moment that when writing
<br>> a->constFunc() for non const object the const "->" operator =
would be chosen
<br>> by the compiler as constFunc() is const, but had to conclude that =
it is not
<br>> the case.</blockquote></div></blockquote><div><br></div><div>Indee=
d, your expectation was simply wrong.</div><div>Consider:</div><div><br></d=
iv><div style=3D"background-color:rgb(250,250,250);border:1px solid rgb(187=
,187,187);word-wrap:break-word"><code><div><span style=3D"color:#008">class=
</span><span style=3D"color:#000"> </span><span style=3D"color:#606">Foo</s=
pan><span style=3D"color:#000"> </span><span style=3D"color:#660">{</span><=
span style=3D"color:#000"><br> </span><span style=3D"color:#00=
8">void</span><span style=3D"color:#000"> member</span><span style=3D"color=
:#660">();</span><span style=3D"color:#000"><br> </span><span =
style=3D"color:#008">void</span><span style=3D"color:#000"> member</span><s=
pan style=3D"color:#660">()</span><span style=3D"color:#000"> </span><span =
style=3D"color:#008">const</span><span style=3D"color:#660">;</span><span s=
tyle=3D"color:#000"><br> </span><span style=3D"color:#008">voi=
d</span><span style=3D"color:#000"> member</span><span style=3D"color:#660"=
>()</span><span style=3D"color:#000"> </span><span style=3D"color:#008">vol=
atile</span><span style=3D"color:#660">;</span><span style=3D"color:#000"><=
br></span><span style=3D"color:#660">};</span><span style=3D"color:#000"><b=
r><br></span><span style=3D"color:#606">Foo</span><span style=3D"color:#000=
"> foo</span><span style=3D"color:#660">;</span><span style=3D"color:#000">=
foo</span><span style=3D"color:#660">-></span><span style=3D"color:#000=
">member</span><span style=3D"color:#660">();</span><span style=3D"color:#0=
00"> </span><span style=3D"color:#800">// calls the non-`const` versi=
on</span><span style=3D"color:#000"><br></span><span style=3D"color:#008">c=
onst</span><span style=3D"color:#000"> </span><span style=3D"color:#606">Fo=
o</span><span style=3D"color:#000"> cfoo</span><span style=3D"color:#660">;=
</span><span style=3D"color:#000"> cfoo</span><span style=3D"color:#660">-&=
gt;</span><span style=3D"color:#000">member</span><span style=3D"color:#660=
">();</span><span style=3D"color:#000"> </span><span style=3D"color:#=
800">// calls the `const` version</span><span style=3D"color:#000"><br></sp=
an><span style=3D"color:#008">volatile</span><span style=3D"color:#000"> </=
span><span style=3D"color:#606">Foo</span><span style=3D"color:#000"> vfoo<=
/span><span style=3D"color:#660">;</span><span style=3D"color:#000"> vfoo</=
span><span style=3D"color:#660">-></span><span style=3D"color:#000">memb=
er</span><span style=3D"color:#660">();</span><span style=3D"color:#000"> &=
nbsp;</span><span style=3D"color:#800">// calls the `volatile` version</spa=
n></div></code></div><div><br>Furthermore, you've forgotten that it's possi=
ble to overload <font face=3D"courier new, monospace">operator-></font> =
(possibly with const and non-const versions) so that you don't even know wh=
at context to look up member in, until you've resolved which <font face=3D"=
courier new, monospace">operator-></font> is being called.</div><div><br=
></div><div style=3D"background-color:rgb(250,250,250);border:1px solid rgb=
(187,187,187);word-wrap:break-word"><code><div><span style=3D"color:#008">c=
lass</span><span style=3D"color:#000"> </span><span style=3D"color:#606">Wi=
dget</span><span style=3D"color:#000"> </span><span style=3D"color:#660">{<=
/span><span style=3D"color:#000"><br> </span><span style=3D"co=
lor:#606">Foo</span><span style=3D"color:#660">*</span><span style=3D"color=
:#000"> </span><span style=3D"color:#008">operator</span><span style=3D"col=
or:#660">-></span><span style=3D"color:#000"> </span><span style=3D"colo=
r:#660">()</span><span style=3D"color:#000"> </span><span style=3D"color:#0=
08">const</span><span style=3D"color:#660">;</span><span style=3D"color:#00=
0"><br> </span><span style=3D"color:#008">void</span><span sty=
le=3D"color:#000"> member</span><span style=3D"color:#660">();</span><span =
style=3D"color:#000"><br></span><span style=3D"color:#660">};</span><span s=
tyle=3D"color:#000"><br><br></span><span style=3D"color:#606">Widget</span>=
<span style=3D"color:#000"> w</span><span style=3D"color:#660">;</span><spa=
n style=3D"color:#000"> w</span><span style=3D"color:#660">-></span><spa=
n style=3D"color:#000">member</span><span style=3D"color:#660">();</span><s=
pan style=3D"color:#000"> </span><span style=3D"color:#800">// calls =
Widget::member()</span><span style=3D"color:#000"><br></span><span style=3D=
"color:#008">const</span><span style=3D"color:#000"> </span><span style=3D"=
color:#606">Widget</span><span style=3D"color:#000"> cw</span><span style=
=3D"color:#660">;</span><span style=3D"color:#000"> cw</span><span style=3D=
"color:#660">-></span><span style=3D"color:#000">member</span><span styl=
e=3D"color:#660">();</span><span style=3D"color:#000"> </span><span s=
tyle=3D"color:#800">// calls Widget::operator->() followed by Foo::membe=
r()</span><span style=3D"color:#000"><br></span></div></code></div><div><br=
></div><div>HTH,</div><div>=E2=80=93Arthur<br></div></div></blockquote><div=
><br>Um, I'm <a href=3D"http://ideone.com/e.js/qNI9Ky">fairly sure that's n=
ot true</a>. You can call const member functions from a non-const object. I=
t's the other way around that doesn't work. So the first one will call Foo:=
:member, just like the second.<br><br>And even if you did it the right way =
around, it would be a <i>compile error</i>. Due to attempting to call a non=
-const member function on a const object.<br></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 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_5160_1981418751.1422988819657--
------=_Part_5159_94414491.1422988819657--
.
Author: mobi phil <mobi@mobiphil.com>
Date: Thu, 5 Feb 2015 22:23:32 +0100
Raw View
--001a113f8f8a863c83050e5dea08
Content-Type: text/plain; charset=UTF-8
Well... ideas are often coming from mistakes that are conceptually not
necessarily mistakes in a certain context.
The "->" operator is an unary operator, though intuitively myself I tend
often to think it as as a binary operator, with second parameter what is on
the right side. Definitively the language would be richer if there would be
a mechanism to have overload also based on the right hand. Obviously one
would need to support stuff like:
(this is rather meta-C++)
template<Type>
Widget::operator->( RightHandType ) {
return (what is intended).RightHandType;
}
but this is just yet another mental-*turbation, far from ever taken
seriously.
Definitively it would help to implement what I thought for COW.
--
---
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/.
--001a113f8f8a863c83050e5dea08
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Well... ideas are often coming from mistakes that are conc=
eptually not necessarily mistakes in a certain context.<div>The "->=
" operator is an unary operator, though intuitively myself I tend ofte=
n to think it as as a binary operator, with second parameter what is on the=
right side. Definitively the language would be richer if there would be a =
mechanism to have overload also based on the right hand. Obviously one woul=
d need to support stuff like:</div><div><br></div><div>(this is rather meta=
-C++)</div><div>template<Type></div><div>=C2=A0 Widget::operator->=
( =C2=A0RightHandType ) {</div><div>=C2=A0 =C2=A0 =C2=A0 return (what is in=
tended).RightHandType;</div><div>}=C2=A0</div><div><br></div><div>but this =
is just yet another mental-*turbation, far from ever taken seriously.</div>=
<div><br></div><div>Definitively it would help to implement what I thought =
for COW.</div><div><br></div><div><br></div><div><br></div><div><br></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 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a113f8f8a863c83050e5dea08--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Thu, 5 Feb 2015 23:35:23 +0200
Raw View
On 5 February 2015 at 23:23, mobi phil <mobi@mobiphil.com> wrote:
> Well... ideas are often coming from mistakes that are conceptually not
> necessarily mistakes in a certain context.
> The "->" operator is an unary operator, though intuitively myself I tend
> often to think it as as a binary operator, with second parameter what is on
> the right side. Definitively the language would be richer if there would be
> a mechanism to have overload also based on the right hand. Obviously one
> would need to support stuff like:
>
> (this is rather meta-C++)
> template<Type>
> Widget::operator->( RightHandType ) {
> return (what is intended).RightHandType;
> }
>
> but this is just yet another mental-*turbation, far from ever taken
> seriously.
>
> Definitively it would help to implement what I thought for COW.
Such an operator-> is certainly something that I'd hope to ultimately see as
an extension of the current reflection work.
--
---
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/.
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Thu, 05 Feb 2015 16:03:14 -0800
Raw View
On Thursday 05 February 2015 22:23:32 mobi phil wrote:
> Well... ideas are often coming from mistakes that are conceptually not
> necessarily mistakes in a certain context.
> The "->" operator is an unary operator, though intuitively myself I tend
> often to think it as as a binary operator, with second parameter what is on
> the right side. Definitively the language would be richer if there would be
> a mechanism to have overload also based on the right hand. Obviously one
> would need to support stuff like:
>
> (this is rather meta-C++)
> template<Type>
> Widget::operator->( RightHandType ) {
> return (what is intended).RightHandType;
> }
>
> but this is just yet another mental-*turbation, far from ever taken
> seriously.
>
> Definitively it would help to implement what I thought for COW.
QSharedDataPointer does COW using operator->.
However, it copies when you call the non-const operator->, even if your use is
read-only.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--
---
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/.
.
Author: mobi phil <mobi@mobiphil.com>
Date: Fri, 6 Feb 2015 01:06:54 +0100
Raw View
--001a113f8f8ac539b4050e6032bc
Content-Type: text/plain; charset=UTF-8
>
>
> QSharedDataPointer does COW using operator->.
>
> However, it copies when you call the non-const operator->, even if your
> use is
> read-only.
>
then you may agree that there would be some added value in such a
construct... Does not make sense to copy if the method is read-only, isn't
it?
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
--001a113f8f8ac539b4050e6032bc
Content-Type: text/html; charset=UTF-8
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br>
</div></div>QSharedDataPointer does COW using operator->.<br>
<br>
However, it copies when you call the non-const operator->, even if your use is<br>
read-only.<br></blockquote><div><br></div><div>then you may agree that there would be some added value in such a construct... Does not make sense to copy if the method is read-only, isn't it?</div><div><br></div></div>
</div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href="mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />
--001a113f8f8ac539b4050e6032bc--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Thu, 05 Feb 2015 17:04:04 -0800
Raw View
On Friday 06 February 2015 01:06:54 mobi phil wrote:
> > QSharedDataPointer does COW using operator->.
> >
> > However, it copies when you call the non-const operator->, even if your
> > use is
> > read-only.
>
> then you may agree that there would be some added value in such a
> construct... Does not make sense to copy if the method is read-only, isn't
> it?
That doesn't work if I'm accessing a member.
For example, the expression
type->member
Is an lvalue and could be assigned to. But that doesn't mean that it is
assigned to, so the operator-> would have no choice but to copy and assume
that you do.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--
---
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/.
.
Author: mobi phil <mobi@mobiphil.com>
Date: Fri, 6 Feb 2015 10:50:43 +0100
Raw View
--001a113f8f8aa001f4050e685ae0
Content-Type: text/plain; charset=UTF-8
On Fri, Feb 6, 2015 at 2:04 AM, Thiago Macieira <thiago@macieira.org> wrote:
> On Friday 06 February 2015 01:06:54 mobi phil wrote:
> > > QSharedDataPointer does COW using operator->.
> > >
> > > However, it copies when you call the non-const operator->, even if your
> > > use is
> > > read-only.
> >
> > then you may agree that there would be some added value in such a
> > construct... Does not make sense to copy if the method is read-only,
> isn't
> > it?
>
> That doesn't work if I'm accessing a member.
>
> For example, the expression
> type->member
>
> Is an lvalue and could be assigned to. But that doesn't mean that it is
> assigned to, so the operator-> would have no choice but to copy and assume
> that you do.
>
well, if you are directly accessing members, you would compromise the
implementation of COW, wouldn't you?
--
---
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/.
--001a113f8f8aa001f4050e685ae0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Fri, Feb 6, 2015 at 2:04 AM, Thiago Macieira <span dir=3D"ltr"><<=
a href=3D"mailto:thiago@macieira.org" target=3D"_blank">thiago@macieira.org=
</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin=
:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=3D"HOEn=
Zb"><div class=3D"h5">On Friday 06 February 2015 01:06:54 mobi phil wrote:<=
br>
> > QSharedDataPointer does COW using operator->.<br>
> ><br>
> > However, it copies when you call the non-const operator->, eve=
n if your<br>
> > use is<br>
> > read-only.<br>
><br>
> then you may agree that there would be some added value in such a<br>
> construct... Does not make sense to copy if the method is read-only, i=
sn't<br>
> it?<br>
<br>
</div></div>That doesn't work if I'm accessing a member.<br>
<br>
For example, the expression<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 type->member<br>
<br>
Is an lvalue and could be assigned to. But that doesn't mean that it is=
<br>
assigned to, so the operator-> would have no choice but to copy and assu=
me<br>
that you do.<br>
<div class=3D"HOEnZb"><div class=3D"h5"></div></div></blockquote></div><br>
</div><div class=3D"gmail_extra">well, if you are directly accessing member=
s, you would compromise the implementation of COW, wouldn't you?</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 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a113f8f8aa001f4050e685ae0--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Fri, 06 Feb 2015 08:42:52 -0800
Raw View
On Friday 06 February 2015 10:50:43 mobi phil wrote:
> > For example, the expression
> >
> > type->member
> >
> > Is an lvalue and could be assigned to. But that doesn't mean that it is
> > assigned to, so the operator-> would have no choice but to copy and assume
> > that you do.
>
> well, if you are directly accessing members, you would compromise the
> implementation of COW, wouldn't you?
How is accessing a member different from calling a member function? Either the
inner object knows it's under COW or it does.
If it does, then the operator-> is irrelevant. The member functions implement
the COW.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--
---
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/.
.
Author: mobi phil <mobi@mobiphil.com>
Date: Fri, 6 Feb 2015 18:13:17 +0100
Raw View
--089e0111b8fa6503a5050e6e89a5
Content-Type: text/plain; charset=UTF-8
>
> How is accessing a member different from calling a member function? Either
> the
> inner object knows it's under COW or it does.
>
sorry, but I fail to understand why you say would not be different. In
which sense different, as for the trivial sense it is different. Once you
assign to a member, for me it is obvious that a copy should be triggered.
While a const method is a clear marking of intention that it will not
change the object state, thus no copy should be triggered.
> If it does, then the operator-> is irrelevant. The member functions
> implement
> the COW.
>
I am afraid you are thinking someway in this reflection context, which is
not obvious... Can you be pls. more explicit.
--
---
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/.
--089e0111b8fa6503a5050e6e89a5
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex">How is accessing a member different from calling=
a member function? Either the<br>
inner object knows it's under COW or it does.<br></blockquote><div><br>=
</div><div>sorry, but I fail to understand why you say would not be differe=
nt. In which sense different, as for the trivial sense it is different. Onc=
e you assign to a member, for me it is obvious that a copy should be trigge=
red. While a const method is a clear marking of intention that it will not =
change the object state, thus no copy should be triggered.</div><div>=C2=A0=
</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex">If it does, then the operator-> is =
irrelevant. The member functions implement<br>
the COW.<br></blockquote><div><br></div><div>I am afraid you are thinking s=
omeway in this reflection context, which is not obvious... Can you be pls. =
more explicit.</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 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--089e0111b8fa6503a5050e6e89a5--
.
Author: Matthew Woehlke <mw_triad@users.sourceforge.net>
Date: Fri, 06 Feb 2015 12:40:13 -0500
Raw View
On 2015-02-06 11:42, Thiago Macieira wrote:
> On Friday 06 February 2015 10:50:43 mobi phil wrote:
>>> For example, the expression
>>>
>>> type->member
>>>
>>> Is an lvalue and could be assigned to. But that doesn't mean that it is
>>> assigned to, so the operator-> would have no choice but to copy and assume
>>> that you do.
>>
>> well, if you are directly accessing members, you would compromise the
>> implementation of COW, wouldn't you?
>
> How is accessing a member different from calling a member function? Either the
> inner object knows it's under COW or it does.
>
> If it does, then the operator-> is irrelevant. The member functions implement
> the COW.
I think there may be confusion here between how QSharedDataPointer works
and how the OP's class works. The OP's class appears to be an *external*
pointer to a shared object, such that choice of whether or not to detach
happens where the *user* uses the object.
QSharedDataPointer on the other hand is a special type of PIMPL pointer.
The object held by this is never directly accessible to the user, and
from the user's perspective, COW objects are *always* copied (in Qt
terminology, they are "implicitly shared", where the "implicit" means
that the sharing/COW is normally invisible to the user).
So, for example, QString is a PIMPL class that uses QSharedDataPointer
to reference it's private data. If the user calls a const method on
QString (e.g. isEmpty()), the const operator-> is used, and no copy occurs.
So I think the confusion is because Thiago is thinking "member access"
in terms of QString accessing a member of QStringData, whereas the OP is
thinking of the application accessing a member of 'A', where 'A' is a
public class with a pointer instance being tracked by 'Cow'.
This latter approach does indeed have the sorts of issues that the OP
raises, because the determination if a detach needs to occur must be
made by the caller (i.e. the user's application) rather than the methods
of the COW object. The advantage of course is that this can be
retrofitted to any class, whereas QSharedDataPointer is an intrusive
property of the COW class. The disadvantage... is that it has the issues
that the OP raised, which is to say essentially that there is no sane
way to implement an operator-> for it currently that just Does The Right
Thing. (A work-around is to only provide data() and constData() methods,
where the former always detaches, and give up on the simplicity of '->'.)
--
Matthew
--
---
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/.
.
Author: mobi phil <mobi@mobiphil.com>
Date: Fri, 6 Feb 2015 19:52:18 +0100
Raw View
--047d7b343c9c7da9c1050e6feb3c
Content-Type: text/plain; charset=UTF-8
>
> > On Friday 06 February 2015 10:50:43 mobi phil wrote:
> >>> For example, the expression
> >>>
> >>> type->member
> >>>
> >>> Is an lvalue and could be assigned to. But that doesn't mean that it is
> >>> assigned to, so the operator-> would have no choice but to copy and
> assume
> >>> that you do.
> >>
> >> well, if you are directly accessing members, you would compromise the
> >> implementation of COW, wouldn't you?
> >
> > How is accessing a member different from calling a member function?
> Either the
> > inner object knows it's under COW or it does.
> >
> > If it does, then the operator-> is irrelevant. The member functions
> implement
> > the COW.
>
> I think there may be confusion here between how QSharedDataPointer works
> and how the OP's class works. The OP's class appears to be an *external*
> pointer to a shared object, such that choice of whether or not to detach
> happens where the *user* uses the object.
>
> QSharedDataPointer on the other hand is a special type of PIMPL pointer.
> The object held by this is never directly accessible to the user, and
> from the user's perspective, COW objects are *always* copied (in Qt
> terminology, they are "implicitly shared", where the "implicit" means
> that the sharing/COW is normally invisible to the user).
>
> So, for example, QString is a PIMPL class that uses QSharedDataPointer
> to reference it's private data. If the user calls a const method on
> QString (e.g. isEmpty()), the const operator-> is used, and no copy occurs.
>
> So I think the confusion is because Thiago is thinking "member access"
> in terms of QString accessing a member of QStringData, whereas the OP is
> thinking of the application accessing a member of 'A', where 'A' is a
> public class with a pointer instance being tracked by 'Cow'.
>
> This latter approach does indeed have the sorts of issues that the OP
> raises, because the determination if a detach needs to occur must be
> made by the caller (i.e. the user's application) rather than the methods
> of the COW object. The advantage of course is that this can be
> retrofitted to any class, whereas QSharedDataPointer is an intrusive
> property of the COW class. The disadvantage... is that it has the issues
> that the OP raised, which is to say essentially that there is no sane
> way to implement an operator-> for it currently that just Does The Right
> Thing.
Thanks for your patience and time to explain the difference. I completely
agree with your clarification, at least what concerns my point.
> (A work-around is to only provide data() and constData() methods,
> where the former always detaches, and give up on the simplicity of '->'.)
>
did you mean data() and constData() on the internal wrapped class, or for
the COW wrapper itself?
--
---
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/.
--047d7b343c9c7da9c1050e6feb3c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote 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;paddi=
ng-left:1ex"><span class=3D"">> On Friday 06 February 2015 10:50:43 mobi=
phil wrote:<br>
>>> For example, the expression<br>
>>><br>
>>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type->member<br>
>>><br>
>>> Is an lvalue and could be assigned to. But that doesn't me=
an that it is<br>
>>> assigned to, so the operator-> would have no choice but to =
copy and assume<br>
>>> that you do.<br>
>><br>
>> well, if you are directly accessing members, you would compromise =
the<br>
>> implementation of COW, wouldn't you?<br>
><br>
> How is accessing a member different from calling a member function? Ei=
ther the<br>
> inner object knows it's under COW or it does.<br>
><br>
> If it does, then the operator-> is irrelevant. The member functions=
implement<br>
> the COW.<br>
<br>
</span>I think there may be confusion here between how QSharedDataPointer w=
orks<br>
and how the OP's class works. The OP's class appears to be an *exte=
rnal*<br>
pointer to a shared object, such that choice of whether or not to detach<br=
>
happens where the *user* uses the object.<br>
<br>
QSharedDataPointer on the other hand is a special type of PIMPL pointer.<br=
>
The object held by this is never directly accessible to the user, and<br>
from the user's perspective, COW objects are *always* copied (in Qt<br>
terminology, they are "implicitly shared", where the "implic=
it" means<br>
that the sharing/COW is normally invisible to the user).<br>
<br>
So, for example, QString is a PIMPL class that uses QSharedDataPointer<br>
to reference it's private data. If the user calls a const method on<br>
QString (e.g. isEmpty()), the const operator-> is used, and no copy occu=
rs.<br>
<br>
So I think the confusion is because Thiago is thinking "member access&=
quot;<br>
in terms of QString accessing a member of QStringData, whereas the OP is<br=
>
thinking of the application accessing a member of 'A', where 'A=
' is a<br>
public class with a pointer instance being tracked by 'Cow'.<br>
<br>
This latter approach does indeed have the sorts of issues that the OP<br>
raises, because the determination if a detach needs to occur must be<br>
made by the caller (i.e. the user's application) rather than the method=
s<br>
of the COW object. The advantage of course is that this can be<br>
retrofitted to any class, whereas QSharedDataPointer is an intrusive<br>
property of the COW class. The disadvantage... is that it has the issues<br=
>
that the OP raised, which is to say essentially that there is no sane<br>
way to implement an operator-> for it currently that just Does The Right=
<br>
Thing.</blockquote><div><br></div><div>Thanks for your patience and time to=
explain the difference. I completely agree with your clarification, at lea=
st what concerns my point.=C2=A0<br></div><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;padding-left:1ex">(A work-around i=
s to only provide data() and constData() methods,<br>
where the former always detaches, and give up on the simplicity of '-&g=
t;'.)<br></blockquote><div>did you mean data() and constData() on the i=
nternal wrapped class, or for the COW wrapper itself?=C2=A0<br></div><div><=
br></div><div><br></div><div><br></div><div><br></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 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--047d7b343c9c7da9c1050e6feb3c--
.
Author: Matthew Woehlke <mw_triad@users.sourceforge.net>
Date: Fri, 06 Feb 2015 15:09:43 -0500
Raw View
On 2015-02-06 13:52, mobi phil wrote:
>> (A work-around is to only provide data() and constData() methods,
>> where the former always detaches, and give up on the simplicity of '->'.)
>
> did you mean data() and constData() on the internal wrapped class, or for
> the COW wrapper itself?
....for the wrapper itself, i.e. instead of operator->.
(As I understand, your original objective is to be able to automagically
choose between a detaching and non-detaching operator-> based on the RHS
of the '->'. We can't do that currently, so the only 'correct' way I can
think of to make your Cow class "work correctly" is to force the user to
specify. As I understand it, your objective is to improve that situation.)
--
Matthew
--
---
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/.
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Fri, 06 Feb 2015 14:21:56 -0800
Raw View
On Friday 06 February 2015 15:09:43 Matthew Woehlke wrote:
> (As I understand, your original objective is to be able to automagically
> choose between a detaching and non-detaching operator-> based on the RHS
> of the '->'. We can't do that currently, so the only 'correct' way I can
> think of to make your Cow class "work correctly" is to force the user to
> specify. As I understand it, your objective is to improve that situation.)
And the discussion derailed when I stated that RHS isn't enough for what the
OP wanted in the end: you can't tell whether the non-const RHS will be used in
a const context. When there are const and non-const overloads available, the
compiler will always choose the non-const one for a non-const object (cf.
"begin" functions in the containers).
In other words, if I write:
for (auto it = container->begin(); it != container->end(); ++it)
;
I might be calling the non-const begin() and end(), which will cause a detach,
even though I never actually modify the container.
If you wanted to avoid the detach, you'd have to write:
for (auto it = container->cbegin(); it != container->cend(); ++it)
But if you've done that, then it's unnecessary to have operator-> do the work.
The work can reside in begin() and end().
In my opinion, this request adds too little new benefit to be worth it.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--
---
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/.
.
Author: mobi phil <mobi@mobiphil.com>
Date: Sat, 7 Feb 2015 01:23:25 +0100
Raw View
--047d7b343c9ca9d305050e748bf5
Content-Type: text/plain; charset=UTF-8
>
> > (As I understand, your original objective is to be able to automagically
> > choose between a detaching and non-detaching operator-> based on the RHS
> > of the '->'. We can't do that currently, so the only 'correct' way I can
> > think of to make your Cow class "work correctly" is to force the user to
> > specify. As I understand it, your objective is to improve that
> situation.)
>
> And the discussion derailed when I stated that RHS isn't enough for what
> the
> OP wanted in the end: you can't tell whether the non-const RHS will be
> used in
> a const context. When there are const and non-const overloads available,
> the
> compiler will always choose the non-const one for a non-const object (cf.
> "begin" functions in the containers).
>
> In other words, if I write:
>
> for (auto it = container->begin(); it != container->end(); ++it)
> ;
>
> I might be calling the non-const begin() and end(), which will cause a
> detach,
> even though I never actually modify the container.
>
> If you wanted to avoid the detach, you'd have to write:
>
> for (auto it = container->cbegin(); it != container->cend(); ++it)
>
> But if you've done that, then it's unnecessary to have operator-> do the
> work.
> The work can reside in begin() and end().
>
> In my opinion, this request adds too little new benefit to be worth it.
>
Dear Thiago,
while Matthew Woehlke for instance correctly understood my point, you still
fail to see that I correctly understand how the compiler interprets the
story. It was just an observation that if the compiler would be able to
reason in the context of the "->" operator (or for the sake of avoiding
confusion lets call it "$#A#$$!" operator ) about the right side,
constructs that I mentioned would be possible. Unfortunately there are not
so many operators available, and the language is not ready to allow the
implementation of such a construct. While you fail to see this and you are
still thinking in terms of current implementation of the "->" operator, you
conclusion of too "little benefit" is so far without any support. If you
did not understand the problem fully please refrain to draw the conclusion
that it adds too little benefit. At the end of the day I would not care if
this would be o function, what i care is to have the mechanism to reason
about the type of member methods/functions. As Ville Voutilainen mentioned,
probably such a story would be possible to implement using the proposed
reflection framework, or with my yet another non-sense proposal about
"generalized templates" or "compile time C++".
--
---
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/.
--047d7b343c9ca9d305050e748bf5
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote 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;paddi=
ng-left:1ex"><span class=3D"">> (As I understand, your original objectiv=
e is to be able to automagically<br>
> choose between a detaching and non-detaching operator-> based on th=
e RHS<br>
> of the '->'. We can't do that currently, so the only &#=
39;correct' way I can<br>
> think of to make your Cow class "work correctly" is to force=
the user to<br>
> specify. As I understand it, your objective is to improve that situati=
on.)<br>
<br>
</span>And the discussion derailed when I stated that RHS isn't enough =
for what the<br>
OP wanted in the end: you can't tell whether the non-const RHS will be =
used in<br>
a const context. When there are const and non-const overloads available, th=
e<br>
compiler will always choose the non-const one for a non-const object (cf.<b=
r>
"begin" functions in the containers).<br>
<br>
In other words, if I write:<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 for (auto it =3D container->begin(); it !=3D=
container->end(); ++it)<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ;<br>
<br>
I might be calling the non-const begin() and end(), which will cause a deta=
ch,<br>
even though I never actually modify the container.<br>
<br>
If you wanted to avoid the detach, you'd have to write:<br>
<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 for (auto it =3D container->cbegin(); it !=
=3D container->cend(); ++it)<br>
<br>
But if you've done that, then it's unnecessary to have operator->=
; do the work.<br>
The work can reside in begin() and end().<br>
<br>
In my opinion, this request adds too little new benefit to be worth it.<br>=
</blockquote><div><br></div><div>Dear Thiago,=C2=A0</div><div><br></div><di=
v>while Matthew Woehlke for instance correctly understood my point, you sti=
ll fail to see that I correctly understand how the compiler interprets the =
story. It was just an observation that if the compiler would be able to rea=
son in the context of the "->" operator (or for the sake of av=
oiding confusion lets call it "$#A#$$!" operator ) about the righ=
t side, constructs that I mentioned would be possible. Unfortunately there =
are not so many operators available, and the language is not ready to allow=
the implementation of such a construct. While you fail to see this and you=
are still thinking in terms of current implementation of the "->&q=
uot; operator, you conclusion of too "little benefit" is so far w=
ithout any support. If you did not understand the problem fully please refr=
ain to draw the conclusion that it adds too little benefit. At the end of t=
he day I would not care if this would be o function, what i care is to have=
the mechanism to reason about the type of member methods/functions. As=C2=
=A0Ville Voutilainen mentioned, probably such a story would be possible to =
implement using the proposed reflection framework, or with my yet another n=
on-sense proposal about "generalized templates" or "compile =
time C++".</div><br class=3D""><table cellpadding=3D"0" class=3D"" sty=
le=3D"font-size:13px"><tbody><tr class=3D""><td class=3D"" style=3D"width:4=
67px"><br></td></tr></tbody></table><div><br></div><div><br><br><br></div><=
table cellpadding=3D"0" class=3D"" style=3D"font-size:13px"><tbody><tr clas=
s=3D""><td class=3D"" style=3D"width:447px"><br></td></tr></tbody></table><=
/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 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--047d7b343c9ca9d305050e748bf5--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Fri, 06 Feb 2015 18:30:28 -0800
Raw View
On Saturday 07 February 2015 01:23:25 mobi phil wrote:
> while Matthew Woehlke for instance correctly understood my point, you still
> fail to see that I correctly understand how the compiler interprets the
> story. It was just an observation that if the compiler would be able to
> reason in the context of the "->" operator (or for the sake of avoiding
> confusion lets call it "$#A#$$!" operator ) about the right side,
> constructs that I mentioned would be possible. Unfortunately there are not
> so many operators available, and the language is not ready to allow the
> implementation of such a construct. While you fail to see this and you are
> still thinking in terms of current implementation of the "->" operator, you
> conclusion of too "little benefit" is so far without any support. If you
> did not understand the problem fully please refrain to draw the conclusion
> that it adds too little benefit. At the end of the day I would not care if
> this would be o function, what i care is to have the mechanism to reason
> about the type of member methods/functions. As Ville Voutilainen mentioned,
> probably such a story would be possible to implement using the proposed
> reflection framework, or with my yet another non-sense proposal about
> "generalized templates" or "compile time C++".
My point is that even if there were an operator that did what you proposed, it
would IMHO be of little value.
There would be more value if the constness or not could be determined by
further operations down the line.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
--
---
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/.
.
Author: mobi phil <mobi@mobiphil.com>
Date: Sat, 7 Feb 2015 10:30:36 +0100
Raw View
--001a113f8f8a8f3d31050e7c3077
Content-Type: text/plain; charset=UTF-8
>
> My point is that even if there were an operator that did what you
> proposed, it
> would IMHO be of little value.
>
> While it would not be of little value for you, would be of great value for
others. Maybe it would bother you that a simpler COW construct could be
implemented than the one in Qt.
> There would be more value if the constness or not could be determined by
> further operations down the line.
>
So you are contradicting yourself. While the conclusion of the thread is
more or less exactly this this would be value but no value... maybe you can
decide yourself.
--
---
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/.
--001a113f8f8a8f3d31050e7c3077
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote 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;paddi=
ng-left:1ex">My point is that even if there were an operator that did what =
you proposed, it<br>
would IMHO be of little value.<br>
<br></blockquote><div>While it would not be of little value for you, would =
be of great value for others. Maybe it would bother you that a simpler COW =
construct could be implemented than the one in Qt.</div><div>=C2=A0</div><b=
lockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-le=
ft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pad=
ding-left:1ex">
There would be more value if the constness or not could be determined by<br=
>
further operations down the line.<br></blockquote><div><br></div><div>So yo=
u are contradicting yourself. While the conclusion of the thread is more or=
less exactly this this would be value but no value... maybe you can decide=
yourself.</div><div><br></div><div><br></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 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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--001a113f8f8a8f3d31050e7c3077--
.