220 15966 <467ea911-87a1-483d-8680-22429bfd7c34@isocpp.org> article Path: news.gmane.org!not-for-mail From: mobiphil Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: const T* operator->() const Date: Mon, 2 Feb 2015 08:32:42 -0800 (PST) Lines: 214 Approved: news@gmane.org Message-ID: <467ea911-87a1-483d-8680-22429bfd7c34@isocpp.org> References: <56a7727d-9839-45c9-be72-a6ecb61f38c9@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1257_345340019.1422894762945" X-Trace: ger.gmane.org 1422894766 31193 80.91.229.3 (2 Feb 2015 16:32:46 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 2 Feb 2015 16:32:46 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDF3H34L74HRBK6NX2TAKGQED7ZEQ2I@isocpp.org Mon Feb 02 17:32:46 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-oi0-f69.google.com ([209.85.218.69]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YIJvZ-0001gs-8X for gclcip-std-proposals@m.gmane.org; Mon, 02 Feb 2015 17:32:45 +0100 Original-Received: by mail-oi0-f69.google.com with SMTP id i138sf374426130oig.0 for ; Mon, 02 Feb 2015 08:32:44 -0800 (PST) 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=/a4ETPHDjTowEwH76qZGl1fvebRayWrDjGCgXVuCwg8=; b=IJYtfQfvNR6XSCo/zl+oSs1stq3aBUHAPK0lueCs/LoBZ3LoeJ4AE0lCnbSHH22SZL d8sKW3W3XNTTnpOudmRtjiGOp5GGcB7FyVi1xGpplCelQfF6iFX5DP+O16N0XSr0e8hf WFULZr2bVMUjAKpUr6zjyuMXhuwNtCgBM+OFcqlRJdAYdPVE1yAlrhyW144fngntxIpV AZFZzgauVo8BR/uX7hio2l+nhP2CvH9zAwpqJmEMyrao1dZmBDdwLPFEJ86mqzWizE4M RjyxJtM+PEwR+CQb1LhZhA0t1rq1yHqsYJsY3gNE6jzucSX5H+zwe6Ch4R9UI2Glanwf uxoQ== X-Gm-Message-State: ALoCoQkyHvAn3MiF2qpjfaHHI6pU8lQWwgrOP+Ft6NAityjEn220ikdsqrGF/lr1CrcYuf2tbh/e X-Received: by 10.182.80.198 with SMTP id t6mr18433458obx.31.1422894764297; Mon, 02 Feb 2015 08:32:44 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.39.49 with SMTP id u46ls2567376qgu.3.gmail; Mon, 02 Feb 2015 08:32:43 -0800 (PST) X-Received: by 10.140.48.97 with SMTP id n88mr221409qga.35.1422894763412; Mon, 02 Feb 2015 08:32:43 -0800 (PST) In-Reply-To: X-Original-Sender: mobi@mobiphil.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:15966 Archived-At: ------=_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 > > 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 > > > > template > > 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 = Cow(); > > a->constFunc(); /* as constFunc is const, would expect the operator-> > > const to be used*/ > > > > const Cow ca = Cow(); > > 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 > will use the non-const Cow::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


On Monday, February 2, 2015 at 3:39:49 PM UTC+1, V= ille Voutilainen wrote:
On 2 Fe= bruary 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.
>
> 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") &= nbsp;;
>       }
> };
>
> class A {
>    public:
>       void func() {};
>       void constFunc() const  {};
> };
>
>
> int main()
> {
>    Cow<A> a =3D Cow<A>();
>    a->constFunc(); /* as constFunc is const, would ex= pect the operator->
> const to be used*/
>
>    const Cow<A> ca =3D 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 ca= se
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 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.


--

---
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_1258_1628885139.1422894762946-- ------=_Part_1257_345340019.1422894762945-- .