220 5296 <31ef7d9e-69ec-4e05-9b5a-82cbb2dd866a@isocpp.org> article Path: news.gmane.org!not-for-mail From: tomaszkam@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Extend defition of INVOKE for member pointers to support types convertible to target class. Date: Thu, 4 Jul 2013 16:03:13 -0700 (PDT) Lines: 181 Approved: news@gmane.org Message-ID: <31ef7d9e-69ec-4e05-9b5a-82cbb2dd866a@isocpp.org> References: <63c352e7-5289-4bfa-9f1a-65cd55478391@isocpp.org> <17744472-4dd0-4bb3-8f28-87f9d5e22a44@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_4380_8677070.1372978993126" X-Trace: ger.gmane.org 1373032296 22939 80.91.229.3 (5 Jul 2013 13:51:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 5 Jul 2013 13:51:36 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDNPVXXG6IGBBZE63OHAKGQEXQITD3A@isocpp.org Fri Jul 05 15:51:37 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-gh0-f197.google.com ([209.85.160.197]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Uv6QA-0005oS-Ld for gclcip-std-proposals@m.gmane.org; Fri, 05 Jul 2013 15:51:34 +0200 Original-Received: by mail-gh0-f197.google.com with SMTP id r20sf2598905ghr.0 for ; Fri, 05 Jul 2013 06:51:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-beenthere:date:from:to:message-id:in-reply-to:references:subject :mime-version:x-original-sender:reply-to:precedence:mailing-list :list-id:x-google-group-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe:content-type; bh=sYVGpLVqT2HWw+QZ19Rgi94mCzcgGQXoAu0w7WB4E4E=; b=V/VUD6i5iyVAUTElEprS7HIYshB/yk6jIAwZnQlwd1GPKgGhcaCnSEj1sDyd6Obrw4 BAa36VPt0g9YpWjuFQ3/gEGEyd/ifBZB7POgLDvu1mrnt+jUGJ3iFqXMJGF+zdVJ1Vg9 AoDoTKYke/2UkMMobqrzi/qlIXRAuL74Iag9c4ARgM3fALYotOG2mKVTsc6wiXBquHRA CvkYkBrb9Y1omYFYMleiCUpb5Sz/mM9MczhgQcfgVslVoz/oyJnXhzAUpkxbsdhRXNVC ikHt17GfctnHDNpfvP05RW8srGYHSJqBYNdyvls+Mpg6zMgeOR1/3TDcBw3vfREF1Or7 a2Eg== X-Received: by 10.236.111.40 with SMTP id v28mr5229106yhg.27.1373032293822; Fri, 05 Jul 2013 06:51:33 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.49.14.169 with SMTP id q9ls975306qec.88.gmail; Fri, 05 Jul 2013 06:51:32 -0700 (PDT) X-Received: by 10.224.37.3 with SMTP id v3mr5489085qad.2.1373032292438; Fri, 05 Jul 2013 06:51:32 -0700 (PDT) Original-Received: by 10.224.52.77 with SMTP id h13msqag; Thu, 4 Jul 2013 16:03:13 -0700 (PDT) X-Received: by 10.49.4.201 with SMTP id m9mr180615qem.15.1372978993543; Thu, 04 Jul 2013 16:03:13 -0700 (PDT) In-Reply-To: X-Original-Sender: tomaszkam@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:5296 Archived-At: ------=_Part_4380_8677070.1372978993126 Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable W dniu pi=B1tek, 5 lipca 2013 00:52:31 UTC+2 u=BFytkownik Ville Voutilainen= =20 napisa=B3: > > On 5 July 2013 01:33, > wrote: > > >> Define INVOKE (f, t1, t2, ..., tN) as follows: >>>> -- (static_cast(t1).*f)(t2, ..., tN) when f is a pointer to a memb= er=20 >>>> function of a class T and t1 is convertible to TR where TR is viable= =20 >>>> reference type for f. >>>> >>> In the case of downcast t1 (being a base class of T) wouldn't be=20 >> convertible (implictly) to any of TR. The implementation do the same thi= ngs. >> > > Thanks. I am not well-versed with INVOKE, it would be helpful if it said= =20 > somewhere that the conversion must be > implicit. Specifying it in terms of static_cast suggests otherwise, so=20 > perhaps that could be said directly > in the wording? > > To be clear. That is the intent of may wording and that is how my=20 implementation works. I think the standard uses term is convertible in the= =20 context of implicit conversions. =20 > For current wording this kind of classes will go trough the (*t).*f path.= =20 >> In my proposed implementation there will be dis-ambiguity between path= =20 >> using conversion operator and the path going via operator*, so it will b= e=20 >> no longer valid. Also I find such weird, because they merge the=20 >> pointer-to-C semantics with a obejct-of-type-C semantics, so in my opini= on=20 >> there is nothing wrong to make them ambiguous in cases of calling member= =20 >> function of C. >> >> > Well, I think going through the (*t).*f path makes a lot of sense,=20 > compared to going via the conversion operator > which makes no sense to me, because it creates a temporary anyway. Having= =20 > such a nonsense conversion > be ambiguous with the operator* thus doesn't make much sense to me either= ..=20 > In other words, I have a lot > of preference for operator* being preferred to conversion functions. I=20 > also happen to think that having this > conversion support is worth breaking that kind of classes, because as I= =20 > said, I don't find them weird. The > standard may not include any such classes, but I have seen such code in= =20 > the wild. > > Then what about the class: struct weird2 { C& operator*(); operator C&(); };=20 Is there any reason to prefer operator* over the conversion to reference=20 operator? For my perspective it isn't. In addition personally I would prefer to always choose a conversions operator over=20 operator*, because it will be used in case of free standing functions that takes C (or reference) as argument. This difference= =20 in the personal tates confirms myself that such cases should be ambiguous. --=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_4380_8677070.1372978993126 Content-Type: text/html; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable

W dniu pi=B1tek, 5 lipca 2013 00:52:31 UTC+2 u=BFytkownik Ville Vou= tilainen napisa=B3:
On 5 July 2013 01:33, <toma...@gmail.com> wrote:


Define INVOKE (f, t1, t2, ..., tN) a= s follows:
— (static_cast<TR>(t1).*f)(t2, ..., tN) when f is a pointer to = a member function of a class T and t1 is convertible to TR where TR is viab= le reference type for f.
In the case of downcast t1 (being a base class of T) wouldn't be conve= rtible (implictly) to any of TR. The implementation do the same things.
=

Thanks. I am not well-versed with IN= VOKE, it would be helpful if it said somewhere that the conversion must be<= br>
implicit. Specifying it in terms of static= _cast suggests otherwise, so perhaps that could be said directly
in the = wording?

To be clear. That= is the intent of may wording and that is how my implementation works. I th= ink the standard uses term is convertible in the context of implicit conver= sions.
 
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
For current wording this kind of classes will go trough the (*t).*f pa= th. In my proposed implementation there will be dis-ambiguity between path = using conversion operator and the path going via operator*, so it will be n= o longer valid. Also I find such weird, because they merge the pointer-to-C= semantics with a obejct-of-type-C semantics, so in my opinion there is not= hing wrong to make them ambiguous in cases of calling member function of C.=


Well, I think going through the (*t).*f path makes a lot of sense, compare= d to going via the conversion operator
which makes no sense to me, because it creates a temporary anyway. Having s= uch a nonsense conversion
be ambiguous with the operator* thu= s doesn't make much sense to me either. In other words, I have a lot
of preference for operator* being preferred to conversion functi= ons. I also happen to think that having this
conversion suppo= rt is worth breaking that kind of classes, because as I said, I don't find = them weird. The
standard may not include any such classes, but I have seen such code in the= wild.


Then what about= the class:
struct w= eird2
{
  C& operator*();
  operator C&();
};=
Is there any reason to prefer operator* over the conversion to = reference operator? For my perspective it isn't. In addition
personally = I would prefer to always choose a conversions operator over operator*, beca= use it will be used in case of free
standing functions that takes C (or = reference) as argument. This difference in the personal tates confirms myse= lf that such
cases should be ambiguous.

--
 
---
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-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/<= /a>.
 
 
------=_Part_4380_8677070.1372978993126-- .