220 5289 <7955cba4-906f-40b4-ae6d-7ef9dfe59181@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: Fri, 5 Jul 2013 01:34:18 -0700 (PDT) Lines: 145 Approved: news@gmane.org Message-ID: <7955cba4-906f-40b4-ae6d-7ef9dfe59181@isocpp.org> References: <63c352e7-5289-4bfa-9f1a-65cd55478391@isocpp.org> <87a9m1j53t.fsf@euclid.axiomatics.org> <3b278ff7-0487-48db-a1e8-6cf8ff7db5b1@isocpp.org> <87hag9bzmo.fsf@euclid.axiomatics.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_4586_765730.1373013258557" X-Trace: ger.gmane.org 1373013260 17820 80.91.229.3 (5 Jul 2013 08:34:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 5 Jul 2013 08:34:20 +0000 (UTC) Cc: tomaszkam@gmail.com, gdr@axiomatics.org To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDNPVXXG6IGBBC4K3KHAKGQE5VV7KUQ@isocpp.org Fri Jul 05 10:34:21 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vb0-f71.google.com ([209.85.212.71]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Uv1TA-00011W-Q8 for gclcip-std-proposals@m.gmane.org; Fri, 05 Jul 2013 10:34:21 +0200 Original-Received: by mail-vb0-f71.google.com with SMTP id f12sf2534864vbg.10 for ; Fri, 05 Jul 2013 01:34:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-beenthere:date:from:to:cc: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=JwW5mkJYwWKvaIMYBn5MzB3kdZcNtxNMkvwA0CN+I1A=; b=OD1qgwrHdE3Lh9Ot03H6MviA7+ksIXOrvkNTm6r7Er+rUWRz+brpAiYCjhzT3o9P+D jmRa4nx2vjOIuSXy+5nz5XlNgWUfM2/oPRPNDRrVllFwzIYAvfjCY+vYScILk0DssxY2 AyyqnpLXh3TdlwlanJtV9yqvCzi3aaE1PrKAevF2vFq7o2Uf6Zovhqk0AjrhqEpB9tHY 30C4UxuHuXiRIwqzrChzozgnXecqxgTOMRpUVaO5BvTJS/55AercHN0jE3OPzeuTwhuF dTC4rnYsjUSgkvQHdqbBLQrKfnMb/5pl0wp71Qn4AwyTiDrVC/8XxHUMdOIhrcmUXmd5 tw2Q== X-Received: by 10.236.54.8 with SMTP id h8mr4782529yhc.11.1373013259781; Fri, 05 Jul 2013 01:34:19 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.49.109.36 with SMTP id hp4ls975661qeb.33.gmail; Fri, 05 Jul 2013 01:34:18 -0700 (PDT) X-Received: by 10.49.13.71 with SMTP id f7mr202898qec.31.1373013258944; Fri, 05 Jul 2013 01:34:18 -0700 (PDT) In-Reply-To: <87hag9bzmo.fsf@euclid.axiomatics.org> 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:5289 Archived-At: ------=_Part_4586_765730.1373013258557 Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable W dniu pi=B1tek, 5 lipca 2013 01:43:10 UTC+2 u=BFytkownik Ville Voutilainen= =20 napisa=B3: > > > I recommend testing that the implementation actually does that, then, and= =20 > changing the wording to say that > it really requires implicit convertibility. > =20 > It was tested against that case. =20 > > No, but it does no harm, and gives a sane result. Doing the opposite does= =20 > no harm either in this > case, but it does harm in the case of the original "struct weird".=20 > Prefering operator* seems sane > in all cases. Perhaps that's why the current INVOKE does it. > > I would harm in case of: struct weird3 { C operator*(); operator C&(); }; =20 > =20 > INVOKE doesn't model just free-standing functions. It has to make some=20 > compromises to support the variety of things > it supports, one of those compromises being that it can't model=20 > free-standing functions exactly. > > For my perspective it does. I see the mem_fn as converting the member=20 function M (Class::*)(Args...) cv ref to be invokable as free=20 standing-function M (Class cv ref, Args...) (if ref is missing there should= =20 be & and && versions), exactly the same as it used for doing an overload=20 resolution. In addition it supports pointers to Class and pointer-like=20 types. W dniu pi=B1tek, 5 lipca 2013 02:48:31 UTC+2 u=BFytkownik Gabriel Dos Reis= =20 napisa=B3: > > It is a wrapper around integer, shouldn't it have that conversion?=20 > I don't see a point to have that class to act both as a integer and an=20 iterator. I see it would be pretty useful in case of STL algorithms and=20 container, but they will use only operator* to extract the value, not the= =20 conversions operator. I don't see a point in using it in the context when= =20 the simple integer will be enough. Maybe I miss something. --=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_4586_765730.1373013258557 Content-Type: text/html; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable

W dniu pi=B1tek, 5 lipca 2013 01:43:10 UTC+2 u=BFytkownik Ville Vou= tilainen napisa=B3:

I recommend testi= ng that the implementation actually does that, then, and changing the wordi= ng to say that
it really requires implicit convertibility. 
It was tested against = that case.
 

No, but it= does no harm, and gives a sane result. Doing the opposite does no harm eit= her in this
case, but it does harm in the case of the original "struct weird". Preferin= g operator* seems sane
in all cases. Perhaps that's why the c= urrent INVOKE does it.

I w= ould harm in case of:
struct weird3
{
  C operator*();
&nb= sp; operator C&();
};
 
 <= /div>
INVOKE doesn't model just free-standing functions. It = has to make some compromises to support the variety of things
it support= s, one of those compromises being that it can't model free-standing functio= ns exactly.


For my perspective it does. I = see the mem_fn a= s converting the member function M (Class::*)(Args...) cv ref to be invokable as free stand= ing-function M (Class c= v ref, Args...) (if ref is missing there should be & and && versions), exactly the same as it used for doing an overload=20 resolution. In addition it supports  pointers to Class and pointer-lik= e types.

W dniu pi=B1tek, 5 lipca 2013 02:48:31 UTC+2 u=BFytkownik G= abriel Dos Reis napisa=B3:
It i= s a wrapper around integer, shouldn't it have that conversion?

I don't see a point to have that class to act bot= h as a integer and an iterator. I see it would be pretty useful in case of = STL algorithms and container, but they will use only operator* to extract t= he value, not the conversions operator. I don't see a point in using it in = the context when the simple integer will be enough. Maybe I miss something.=

--
 
---
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_4586_765730.1373013258557-- .