220 23519 <568C3EC7.8070900@wanadoo.fr> article Path: news.gmane.org!not-for-mail From: "Vicente J. Botet Escriba" Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: n4428 and Tuple-like access interface reflection Date: Tue, 5 Jan 2016 23:08:07 +0100 Lines: 169 Approved: news@gmane.org Message-ID: <568C3EC7.8070900@wanadoo.fr> References: <56770133.7070701@wanadoo.fr> <5681D877.3010101@wanadoo.fr> <43daa6cd-e152-43c1-ab51-0661779d344b@isocpp.org> <568942A9.80700@wanadoo.fr> <568B0DA1.3080704@wanadoo.fr> <7d4bd204-e4c3-4f60-8be5-63d8127daf74@isocpp.org> <487ea013-6fcb-4d2e-8bc7-8fe96cdbf0a9@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------------070800010509000506090405" X-Trace: ger.gmane.org 1452031705 25276 80.91.229.3 (5 Jan 2016 22:08:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 5 Jan 2016 22:08:25 +0000 (UTC) Cc: mwoehlke.floss@gmail.com To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDH67CONY4PBBSH5WC2AKGQEN72VJFI@isocpp.org Tue Jan 05 23:08:16 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-lf0-f69.google.com ([209.85.215.69]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aGZly-0001tm-Fu for gclcip-std-proposals@m.gmane.org; Tue, 05 Jan 2016 23:08:10 +0100 Original-Received: by mail-lf0-f69.google.com with SMTP id y184sf193445394lfc.3 for ; Tue, 05 Jan 2016 14:08:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=SERTqg9HRf4aPLW3x/Az5mJCGe1OCEcut6+9pon8irs=; b=yfFudYNF+YL5c1nOvO+jF3V35zId7Ey4ZIZvnIUma/PitW9yFxvJy6yzt8gzI6YvN5 igVlEn5Yzsn9Lj94adOVO3uP918h9nlp7QRR2K3QeF3T66vy7bVAhLrjkGDrPVKzS97a ksTHmf5NP49McLYpS1FnCTU8HU8OyvXRH4vEwD+pL0tHajO1a6dqysNWRYBT6FYsKNsf 0ZZFTdxBRoH14xcib1+BxRhh0cOcDHjXsRS4uSYhNycmr1UhWCTtYCfxGmbbegNVTOwz YvLnkmJApP8EXTqtqaEGrM8Kxo1kbueohIy28vt94zewfo4ec1DbPh+Lqg0BwtYcBdVk wDxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=SERTqg9HRf4aPLW3x/Az5mJCGe1OCEcut6+9pon8irs=; b=RK/r+5Lpa7ekkQ+BlxTF30tBM7MDwCaAdOxuU8a9T0Q0syu5SdFcWynT9C5dseuCbf Ucl5Y2255kwmUU961wKxG0TjwLKsdpf/YBckgYQoAkzHAJt+Ob8nArk/DR3wmaKRQw9U vdm1K+ITsKQShWWrX+9PkGBs+VQF9CV1b8JYsM3WffVLqBRKxIiNPQruUKrIcU15DzkW YDlWCfONeYY0jpb41a1n2k9JmDsdzBhMdVfuPPUMAZPeCiQ/oa31uF06Jg7CoCwrgGVk Z3W0uclTq8HoAv/M9wcLDwPnn1W9GGGMQGuQiRUh3xMSoutJc7soX6I/ubFoxFyfeRLN fN X-Gm-Message-State: ALoCoQlSUzEoj8WwkRBYD5KRUIfDA97xBXmyatj3P+3yCpiL2709gAyxntt1CnPZGmpe2llOCsinGekR6LmNzLw6WQM9tKyZ4A== X-Received: by 10.112.130.42 with SMTP id ob10mr8656947lbb.2.1452031689632; Tue, 05 Jan 2016 14:08:09 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.28.217.138 with SMTP id q132ls242744wmg.11.canary; Tue, 05 Jan 2016 14:08:08 -0800 (PST) X-Received: by 10.28.85.129 with SMTP id j123mr6790592wmb.77.1452031688550; Tue, 05 Jan 2016 14:08:08 -0800 (PST) Original-Received: from smtp.smtpout.orange.fr (smtp02.smtpout.orange.fr. [80.12.242.124]) by mx.google.com with ESMTPS id n16si155212109wjw.236.2016.01.05.14.08.08 for (version=TLS1 cipher=AES128-SHA bits=128/128); Tue, 05 Jan 2016 14:08:08 -0800 (PST) Received-SPF: neutral (google.com: 80.12.242.124 is neither permitted nor denied by best guess record for domain of vicente.botet@wanadoo.fr) client-ip=80.12.242.124; Original-Received: from new-host.home ([2.10.6.67]) by mwinf5d49 with ME id 2N871s00H1SlsaA03N87Eu; Tue, 05 Jan 2016 23:08:08 +0100 X-ME-Helo: new-host.home X-ME-Auth: dmljZW50ZS5ib3RldEB3YW5hZG9vLmZy X-ME-Date: Tue, 05 Jan 2016 23:08:08 +0100 X-ME-IP: 2.10.6.67 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 In-Reply-To: <487ea013-6fcb-4d2e-8bc7-8fe96cdbf0a9@isocpp.org> X-Original-Sender: vicente.botet@wanadoo.fr X-Original-Authentication-Results: mx.google.com; spf=neutral (google.com: 80.12.242.124 is neither permitted nor denied by best guess record for domain of vicente.botet@wanadoo.fr) smtp.mailfrom=vicente.botet@wanadoo.fr 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: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:23519 Archived-At: This is a multi-part message in MIME format. --------------070800010509000506090405 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Le 05/01/2016 19:20, Nicol Bolas a =C3=A9crit : > On Tuesday, January 5, 2016 at 11:38:11 AM UTC-5, Matthew Woehlke wrote: > > On 2016-01-05 11:00, Nicol Bolas wrote: > > On 2016-01-04 22:08, Ville Voutilainen wrote: > >>> The question is why would you check for an aggregate? > >> > >> The goal is that get would be implicitly defined for any > "aggregate". > >> It should *not* be defined however for types that have non-public > >> NSDM's. The question is how to achieve this. > >> > >> I should note that one answer is "compiler magic". If a > standard trait > >> is going to be a problem, that may be a strong argument to use > compiler > >> magic rather than a portable library solution. > > > > Well, reflection of any kind, which this whole idea relies on, > is going to > > require compiler magic. > > True. The question could be better expressed as whether the compiler > magic provides get *directly* (as in, there may be no visible > declaration of the generic form of such), or whether get is > (visibly, > in the standard library) implemented with the help of traits (which > themselves are compiler magic, but have broader applicability). > > > I say let the whole thing be compiler magic. It'd probably be faster=20 > to compile that way if the compiler can just use intrinsics or=20 > whatever to enumerate the members of the struct. > Thanks to all for your help. Could we conclude then that the generation=20 should be done when - (1) no private or protected non-static data members and - (2) no base classes ? Do you see a better characterization? We can let the answer to whether it is the compiler that generates them or = if they are generated using some missing type trait or reflection traits as= an open question. Vicente --=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 https://groups.google.com/a/isocpp.org/group/std-propos= als/. --------------070800010509000506090405 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Le 05/01/2016 19:20, Nicol Bolas a =C3=A9crit=C2=A0:
On Tuesday, January 5, 2016 at 11:38:11 AM UTC-5, Matthew Woehlke wrote:
On 2016-01-05 11:00, Nicol Bolas wrote:
> On 2016-01-04 22:08, Ville Voutilainen wrote:
>>> The question is why would you check for an aggregate?
>>
>> The goal is that get<N> would be implicitly defined for any "aggregate".
>> It should *not* be defined however for types that have non-public
>> NSDM's. The question is how to achieve this.
>>
>> I should note that one answer is "compiler magic". If a standard trait
>> is going to be a problem, that may be a strong argument to use compiler
>> magic rather than a portable library solution.
>
> Well, reflection of any kind, which this whole idea relies on, is going to
> require compiler magic.

True. The question could be better expressed as whether the compiler
magic provides get<N> *directly* (as in, there may be no visible
declaration of the generic form of such), or whether get<N> is (visibly,
in the standard library) implemented with the help of traits (which
themselves are compiler magic, but have broader applicability).

I say let the whole thing be compiler magic. It'd probably be faster to compile that way if the compiler can just use intrinsics or whatever to enumerate the members of the struct.

Thanks to all for your help. Could we conclude then that the generation should be done when
   - (1) no private or protected non-static data members=
 and
   - (2) no base classes=20
?

Do you see a better characterization?

We can let the answer to whether it is the compiler that generates them or =
if they are generated using some missing type trait or reflection traits as=
 an open question. =20


Vicente

--

---
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 https://groups.google.com/a/isocpp.org/group/std-proposals= /.
--------------070800010509000506090405-- .