220 24982 article Path: news.gmane.org!not-for-mail From: "'Walt Karas' via ISO C++ Standard - Future Proposals" Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: "Components" template with implicitly defined partial specializations for all classes Date: Sat, 5 Mar 2016 17:17:36 -0800 (PST) Lines: 220 Approved: news@gmane.org Message-ID: References: <56D9E17F.2070202@wanadoo.fr> <2b0bcca0-0939-49f7-939b-4d688f8dfe34@isocpp.org> <324dbff9-84da-46f2-b2f3-3d9fe0cc2082@isocpp.org> <56DA88DF.90000@wanadoo.fr> <7e46c46d-2e18-4cec-92c1-4f4d7fbc786b@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_2249_1793260402.1457227056713" X-Trace: ger.gmane.org 1457227066 24722 80.91.229.3 (6 Mar 2016 01:17:46 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 6 Mar 2016 01:17:46 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDFLZXWOVYIBBMMK523AKGQEYOFSNII@isocpp.org Sun Mar 06 02:17:40 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yk0-f197.google.com ([209.85.160.197]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1acNKF-0008CM-SF for gclcip-std-proposals@m.gmane.org; Sun, 06 Mar 2016 02:17:40 +0100 Original-Received: by mail-yk0-f197.google.com with SMTP id m4sf106318013yke.2 for ; Sat, 05 Mar 2016 17:17:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :x-spam-checked-in-group:list-post:list-help:list-archive:sender :list-subscribe:list-unsubscribe; bh=ZPfyQRUpiYnTQybn0NcSyMaWgVpXLJOcSAcJKEkYUCc=; b=RFTRPJhaYKZXX8Ljs9gMdpGVnJUudHhlxFhrVjouiQu67xDdJu+biCBmRElUWbS+to 3fgYhb1bdx84Eja9BsiMIgDoyF8hQi2SejFkRL8eKcIXChjx8ZvR6Vm+qsnwAyoNuHF2 1uQfm05qfrWyHBMOCfmV77914N2bK1ddKKcAayZgjs7cbUUMuRrDcShK/T2GUyzDBYWM tKRxm45RgyOIDc+FRqThPyQyaGL0xcZ1a7Y/m2b6qEM16zZDrYkpgLnOwfDqQGN8jQSy 6EA2IbUEb7nQvBI44JBO37kxKDfhYYT8G++kXeTnzOMFjI0Y7sVEfayCOt3trVO5OEiG gajg== 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:x-original-sender:reply-to:precedence :mailing-list:list-id:x-spam-checked-in-group:list-post:list-help :list-archive:sender:list-subscribe:list-unsubscribe; bh=ZPfyQRUpiYnTQybn0NcSyMaWgVpXLJOcSAcJKEkYUCc=; b=hCUJxUf59yfhrhhoCbcr4CDA647+6d0lbq3TWPlrqIFODctN7q2wvsiLTsXEFO3tFw RP4Kv4jj4lKwKgmwmDc1w2y8opM9rqZvx8iA0h/JsxwYyzGsfSXz29qwtXQmYiYl/fWt kUmUJojdWBVTH/FqBMi57kW8jmAzLy36o3n95tznqNGdqCVNJKESYH+1SY1+6O2G8iOi qMOdSqG/1mrHts/+MsPjkTAoKqZ9RRMhtoPq/GmgDrq1h4VQ8KkTDXlMgtNTfD3RSlb9 /8VOxFaawcDEaC1g0nx1+q+/oKk2ctVwsrHaKxSKduBjeEGNbCp7DUU5O030N/6gvmoE 9YkQ== X-Gm-Message-State: AD7BkJK+jgbo0Rr8H59JxpI6GVPvUun6mk7HLpqpmL8O+uYztOH5O5vUdAi7U/hQkU8uyQ== X-Received: by 10.13.223.211 with SMTP id i202mr3339963ywe.4.1457227059035; Sat, 05 Mar 2016 17:17:39 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.142.42 with SMTP id rt10ls683096igb.17.canary; Sat, 05 Mar 2016 17:17:37 -0800 (PST) X-Received: by 10.50.103.68 with SMTP id fu4mr109409igb.9.1457227057706; Sat, 05 Mar 2016 17:17:37 -0800 (PST) In-Reply-To: <7e46c46d-2e18-4cec-92c1-4f4d7fbc786b@isocpp.org> X-Original-Sender: wkaras@yahoo.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Spam-Checked-In-Group: std-proposals@isocpp.org X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: Original-Sender: std-proposals@isocpp.org List-Subscribe: , List-Unsubscribe: , X-Original-From: Walt Karas Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:24982 Archived-At: ------=_Part_2249_1793260402.1457227056713 Content-Type: multipart/alternative; boundary="----=_Part_2250_1305679271.1457227056713" ------=_Part_2250_1305679271.1457227056713 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Saturday, March 5, 2016 at 7:27:24 PM UTC-5, Nicol Bolas wrote: > > On Saturday, March 5, 2016 at 7:09:11 PM UTC-5, Walt Karas wrote: >> >> On Saturday, March 5, 2016 at 2:21:06 AM UTC-5, Vicente J. Botet Escriba= =20 >> wrote: >>> >>> Le 05/03/2016 03:08, 'Walt Karas' via ISO C++ Standard - Future=20 >>> Proposals a =C3=A9crit : >>> >>> >>> >>> On Friday, March 4, 2016 at 8:22:12 PM UTC-5, Nicol Bolas wrote:=20 >>>> >>>> On Friday, March 4, 2016 at 2:53:26 PM UTC-5, Walt Karas wrote:=20 >>>>> >>>>> Personally I'm more interested in a generic endiance-swap function=20 >>>>> template. The books will be open in 2017, new features will be made,= I'm=20 >>>>> selfishly thinking of the needs on my own turf. But why not do it in= a way=20 >>>>> that is more general, provides for multiple needs? >>>>> >>>> >>>> Yes... that's what *reflection* will do. Your way is the more=20 >>>> special-case and restrictive way. >>>> >>> >>> Are there other papers proposing support for reflection, besides p0255r= 0=20 >>> ? >>> >>> >>> >>> >>> Yes, look at >>> >>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/. >>> >>> Vicente >>> >> >> I think it's a bad choice to not seriously consider a class=20 >> introspection/reflection capability that can support providing compariso= n=20 >> operators as library templates. Maybe these do, but it's not clear to m= e. >> > > ... why bother? With default operators=20 > ,= =20 > generating comparison operators won't be a significant use case for=20 > reflection. Now, that doesn't mean you won't want to do it sometimes. But= =20 > most of the time, no. > > Also, just because one reflection proposal doesn't have something doesn't= =20 > mean that others won't. Compile-time reflection is hard to get right. > Experience has shown that good layered architectures are generally=20 advantageous. A rule of thumb for a good layered architecture is to have= =20 one capability in a lower layer that supports multiple capabilities in a=20 higher layer. As opposed to supporting just one or some or all of those=20 multiple capabilities in the lower layer. The base language is the lowest= =20 layer of the C++ architecture. Therefore, I think it's likely to be better= =20 to have a capability in the base language that allows for support of=20 reasonably good generic comparison operators, generic stream input/output= =20 operators, generic std::hash, maybe generic JSON/XML input/output, etc=20 using library code above the base layer. --=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. To view this discussion on the web visit https://groups.google.com/a/isocpp= ..org/d/msgid/std-proposals/d6495758-627e-434d-a867-ed473d869f47%40isocpp.or= g. ------=_Part_2250_1305679271.1457227056713 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Saturday, March 5, 2016 at 7:27:24 PM UTC-5, Nicol Bola= s wrote:
On Sa= turday, March 5, 2016 at 7:09:11 PM UTC-5, Walt Karas wrote:
On Saturday, March 5, 2016 at 2:2= 1:06 AM UTC-5, Vicente J. Botet Escriba wrote:
=20 =20 =20
Le 05/03/2016 03:08, 'Walt Karas' via ISO C++ Standard - Future Proposals a =C3=A9crit=C2=A0:


On Friday, March 4, 2016 at 8:22:12 PM UTC-5, Nicol Bolas wrote:
On Friday, March 4, 2016 at 2:53:26 PM UTC-5, Walt Karas wrote:
Personally I'm more interested in a gene= ric endiance-swap function template.=C2=A0 The books will be op= en in 2017, new features will be made, I'm selfishly thinking of the needs on my own turf.=C2=A0 But why not do = it in a way that is more general, provides for multiple needs?

Yes... that's what reflection will do. Your way is the more special-case and restrictive way.

Are there other papers proposing support for reflection, besides p0255r0 ?

Yes, look at

http://www.open-std.org/jtc1/sc22/wg21/docs/pap= ers/2016/.

Vicente

I think it's a ba= d choice to not seriously consider a class introspection/reflection capabil= ity that can support providing comparison operators as library templates. = =C2=A0Maybe these do, but it's not clear to me.

... why bother? With default operators, generating comparison operators won't= be a significant use case for reflection. Now, that doesn't mean you w= on't want to do it sometimes. But most of the time, no.

Also, ju= st because one reflection proposal doesn't have something doesn't m= ean that others won't. Compile-time reflection is hard to get right.

Experience has shown that goo= d layered architectures are generally advantageous. =C2=A0A rule of thumb f= or a good layered architecture is to have one capability in a lower layer t= hat supports multiple capabilities in a higher layer. =C2=A0As opposed to s= upporting just one or some or all of those multiple capabilities in the low= er layer. =C2=A0The base language is the lowest layer of the C++ architectu= re. =C2=A0Therefore, I think it's likely to be better to have a capabil= ity in the base language that allows for support of reasonably good generic= comparison operators, generic stream input/output operators, generic std::= hash, maybe generic JSON/XML input/output, etc using library code above the= base layer.

--
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.
To view this discussion on the web visit https://groups.google.= com/a/isocpp.org/d/msgid/std-proposals/d6495758-627e-434d-a867-ed473d869f47= %40isocpp.org.
------=_Part_2250_1305679271.1457227056713-- ------=_Part_2249_1793260402.1457227056713-- .