220 15996 article Path: news.gmane.org!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: const T* operator->() const Date: Tue, 3 Feb 2015 10:40:19 -0800 (PST) Lines: 234 Approved: news@gmane.org Message-ID: References: <56a7727d-9839-45c9-be72-a6ecb61f38c9@isocpp.org> <467ea911-87a1-483d-8680-22429bfd7c34@isocpp.org> <71a46a6b-d0b5-4af7-b89c-fd67b505d22f@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_5159_94414491.1422988819657" X-Trace: ger.gmane.org 1422988826 15142 80.91.229.3 (3 Feb 2015 18:40:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 3 Feb 2015 18:40:26 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCEKFTV6ZUMBBFFMYSTAKGQEJJC442Y@isocpp.org Tue Feb 03 19:40:22 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pa0-f71.google.com ([209.85.220.71]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YIiOc-00029B-6q for gclcip-std-proposals@m.gmane.org; Tue, 03 Feb 2015 19:40:22 +0100 Original-Received: by mail-pa0-f71.google.com with SMTP id kq14sf534466332pab.2 for ; Tue, 03 Feb 2015 10:40:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :content-type:x-original-sender:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe; bh=36TXrIz8qsNWddc5ehjynRd9SxHOvoLaaXaawo08FLA=; b=oVWa9DCfSSeObXXmSNdjiVbiwwcUpMxaevsSFti71NYA7Jhcib2fwGNmNLt/Co6ssk BBnj4kPfoP+uI7MovrLbqJZbIJqk6oQNCU4YbJJiyI1Ng4nkf2zf/eSkjuFH4Kyv5k8z 50K1BMJPZ+/agiqLELzU4WjXVukFW/+5GcecCokdoyxJAnFJsdHFQXzXJfXtfyQm+p0A 2JUER8ANI0x8dayAv9PvMFzKSApZbKz5DCu6FkvOvJuEsDZWczkkPfKIBIiMzZbhxu0b Uof/dlTFDdlEI0eQ7GPGcOSr+0dwbSJEiLQ5m1CTrZzpnclNvTs+HTa8uSiXdJU0HjCZ 7hbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version:content-type:x-original-sender:reply-to :precedence:mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=36TXrIz8qsNWddc5ehjynRd9SxHOvoLaaXaawo08FLA=; b=GQ5VhvcYrS+ykkq26KaL68kivYa02A1m19Bem5t2E6ZcwyNoX/g9UtkiIyoO4zwZO0 wIQ4NChM/TwlX/ZCeijEU7owco5kI0Uosluj39VX1rpCBBuxcETi1KP2JxnG0w5iQ2Kz iwAqoJyDOxOmJtCf67sxztxr9aiTVY2/bFKzbpoSMRqfQ+uI4CP8O37+aBqsfbAUmWUM I96QRVy2PERg2b0Kz3B9TniXZO4PRdUGNciS66xIY+twcGyMZFo/wDplgy5CBUnAP9QD deziIYC+6mvHcy878QrzGKD87XYjC0TNi+xUhiEqWOx1aQ5/iPQZDhjySHDnevtke34B DE/g== X-Gm-Message-State: ALoCoQmPupAnxzSgQttGIQqzAWXTEbIgXtdptiuuwi4LPErLWyV8RuKD1uLxSKXV/eOx0qzzHhzH X-Received: by 10.66.150.33 with SMTP id uf1mr23112600pab.33.1422988821104; Tue, 03 Feb 2015 10:40:21 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.93.165 with SMTP id d34ls3283059qge.61.gmail; Tue, 03 Feb 2015 10:40:20 -0800 (PST) X-Received: by 10.140.106.8 with SMTP id d8mr313370qgf.7.1422988820125; Tue, 03 Feb 2015 10:40:20 -0800 (PST) In-Reply-To: <71a46a6b-d0b5-4af7-b89c-fd67b505d22f@isocpp.org> X-Original-Sender: jmckesson@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:15996 Archived-At: ------=_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 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 . 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


On Monday, February 2, 2015 at 5:58:36 PM UTC-5, A= rthur O'Dwyer wrote:


On Monday, February 2, 2015 at 8:32:43 AM UTC-8, mobiphil = wrote:
On Monday, F= ebruary 2, 2015 at 3:39:49 PM UTC+1, Ville Voutilainen wrote:
On 2 February 2015 at 16:27, mobiphil <mo...@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. Th= e idea was
> to have a Cow wrapper template around the classes used in my syste= m. The
> protocol would be: if a non const method is called on the object t= hen a copy
> is made (if necessary), otherwise just call the method. The idea w= as 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.

Indee= d, your expectation was simply wrong.
Consider:

class= Foo {<= span style=3D"color:#000">
    void member();
    void member() const;
    voi= d member() vol= atile;<= br>};
Foo foo;= foo->member();  // calls the non-`const` versi= on
c= onst Fo= o cfoo;= cfoo-&= gt;member();  // calls the `const` version
volatile Foo vfoo<= /span>; vfoo->memb= er(); &= nbsp;// calls the `volatile` version

Furthermore, you've forgotten that it's possi= ble to overload operator-> = (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 operator-> is being called.
c= lass Wi= dget {<= /span>
    Foo* operator-> () const;
    void member();
};

Widget= w; w->member();  // calls = Widget::member()
const Widget cw; cw->member();  // calls Widget::operator->() followed by Foo::membe= r()
HTH,
=E2=80=93Arthur

Um, I'm fairly sure that's n= ot true. 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.

And even if you did it the right way = around, it would be a compile error. Due to attempting to call a non= -const member function on a const object.

--

---
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposa= ls+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/<= /a>.
------=_Part_5160_1981418751.1422988819657-- ------=_Part_5159_94414491.1422988819657-- .