220 37489 article Path: news.gmane.org!.POSTED!not-for-mail From: Richard Smith Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Allowing std::complex's magic permission for other types Date: Tue, 27 Mar 2018 05:35:20 +0000 Lines: 199 Approved: news@gmane.org Message-ID: References: <6ec944b3-16c3-4f00-b0c9-a449a522d4ac@isocpp.org> <2111ede0-62c6-4a41-8df3-f506d07f09f2@isocpp.org> <627b1086-2f31-402a-92b0-223bf15d33b5@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="001a113acf404395de05685e42d9" X-Trace: blaine.gmane.org 1522128814 28737 195.159.176.226 (27 Mar 2018 05:33:34 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 27 Mar 2018 05:33:34 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDVNBJG4YAIBBKFQ47KQKGQE4SS64VY@isocpp.org Tue Mar 27 07:33:30 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-wm0-f69.google.com ([74.125.82.69]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f0hEf-0007P6-P0 for gclcip-std-proposals@m.gmane.org; Tue, 27 Mar 2018 07:33:29 +0200 Original-Received: by mail-wm0-f69.google.com with SMTP id b76sf5431597wmg.9 for ; Mon, 26 Mar 2018 22:35:37 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1522128937; cv=pass; d=google.com; s=arc-20160816; b=CmZKdVs5EPrWxM+XkhXOxSQT3i7aB7GN8DQR4KwJfjobf+PpDOtzmrCPae8S2Hay7u c7LWPuUdYoV69jh4WaPoLT4/BS8QUo2daPmLJU5LJXK+uG2PWfwnjSnOcMkOYxImppXl cbohKnoxF3CAovDHVQFnFhqqQTE+mZ3EYrDfAEAXfQ9KQaG4sbMrqc8qGbkSxylAmKaS Xji+oft/hgM6VaQKpEDeT5oi2EHTgQSBFNvj5L5AazTAV6ohXXwvKF1Cy672PAqw1G9x Mdyrl0tsqyRlO3dhlV4068hYEkh3Wn3FtoVu0QuTWlZVf2twrBoKglJdqz7O1BvyK9EX hGIA== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:to:subject:message-id:date :from:in-reply-to:references:mime-version:arc-authentication-results :arc-message-signature:dkim-signature:arc-authentication-results; bh=pAW0opYRYCMEUvik9RpiCunqtW3REg+jJqUswALGH28=; b=VDKIqL2IEdkZbElqC022u6Ztlbdrn5nimsm77KdNx1KlFf2PSkr4l6ke7MU9PTWiDr kfIAzl/9DCBdecusNpRV/dyMo3kim+wiEHH4Jve7LLJimMVsIuZAElheVaRiL+whj3rW 246xQRLsN0y62U8rsETL7/6KQvuetMdqU5pZRxzYaP8wDmKmwSIDKjGP1V4oy8aZMArE PGXKH4uOuN3E2d3zSwHZ2tyyNLm+AD8iwkGX0rzkJJ8LYPBMxoZ84MKmA8/fMBfNNNEG gJRh2GmKTWixtupmFdzG74w+db7DAbaUXQ0e0FeJugOABXxLA4/2NbCpF3N60fybtMmN sCVg== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@metafoo.co.uk header.s=default header.b=igP73xnI; spf=neutral (google.com: 81.27.85.19 is neither permitted nor denied by best guess record for domain of richard@metafoo.co.uk) smtp.mailfrom=richard@metafoo.co.uk DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :x-original-sender:x-original-authentication-results:reply-to :precedence:mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=pAW0opYRYCMEUvik9RpiCunqtW3REg+jJqUswALGH28=; b=FD2vsINDVfSAQixFXbxwnugCvfzP7sqS1pdoIh/ALmZ6VpSNDjWP6y738nc8Sq/zxC E8rV4p5s+VAbxQLujt0mTenHOvuR31kVTevk1tUCZBRYMQEzpoPxA302PS8D4vPpT2hV zhtaAjWczaHnPpu1FTgkUDEkkFGge0FHv/S4tQNNmJPKpODaN4aACw0moZJZ1zYLGXgL Cvewph3C7cn90UacAp7chkUK5Poi7tf2pBCjARH9QFNHLf/veV8Uo+dOQhW0w5GBGTQI aQncj2agSZTVauzTb+3tfZ5hIsLykzzPhzX2NL4xlva5n3EpSxzM3qYlCmtfvMx3xHKy 9RSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to: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=pAW0opYRYCMEUvik9RpiCunqtW3REg+jJqUswALGH28=; b=HQkYvoLajoqPHBPyiY1ShkpCSP93IxnUzn5D2E7jMxKlaTa4B1X4PLfdqdzHIMNTgn A0tVXIJBDXzhzZL+OnEKwyiqsMcUKWyJ1JVxnzC4+NRrg2lXH0cDctKhwksmtE8eriTF /70c5rgfgmZI3NeXRaNCRpFugELM5kYsXCezZUXJb78ODzzB+n+Zb0TZYMDPAq9fFB3G xf9z2aeptr6NYpQxo8ngAz+swHM6lXTHjXEaYvjfwzAOK3SBrL/YSH3pPxkl7u0ulJZX B7XUjWSp7mpVS2TM1kpv0JOSdS20OYGXaUMfG3JldLnmSu3Y+uIVLkRM0+1/ItkoGaob S7NQ== X-Gm-Message-State: AElRT7GI1J8Wa+PGBSWd+zGiEqJ5it/yqLvkgY5OkGM1dA9UxGIEX5Dw CNz868WeZjWxHB7QJ+etZOoaaA== X-Google-Smtp-Source: AG47ELuBnWizPg7TlgZeK6uIcEcU9gMCPB/7OH6QPZt2iQcwxVTqz6pQP4tz5esuNbeF+JgfBsfaZw== X-Received: by 10.28.247.4 with SMTP id v4mr2351080wmh.1.1522128937235; Mon, 26 Mar 2018 22:35:37 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.223.135.56 with SMTP id a53ls68100wra.4.gmail; Mon, 26 Mar 2018 22:35:35 -0700 (PDT) X-Received: by 10.223.151.69 with SMTP id r63mr31519313wrb.47.1522128935922; Mon, 26 Mar 2018 22:35:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1522128935; cv=none; d=google.com; s=arc-20160816; b=wlNwZ7ElPZAo2IsRtlD53d9gp6hmNSuR+kACfak6RoXjtYsiPXN8BRgeHaFKo/OZ7t 5EXhNrUIZk77fiBPQ4sXKShIpgyWVv9AW4+T6s+5hYPgnVi48Z4lXP15Sc6saAetAArf gvQZDYLuS00/1NLItjwcHryByMWfPEev87b3xqvEKxRwI3r0FT5yw658V/UfqnfWp8he iGl7vfDdR7SH+8Af2oLnOV9r7TmnAQWqusVsKpLWIkqvRjBNVrEJgfJ2GcCXNkz4vxYV vmAlmMNcb7jhPZGKJnV+Zl0uIfc2TWCvFeItIik+zYp41pzoKc4ycXoFYANIeweBKHlp GSMA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :dkim-signature:arc-authentication-results; bh=UVvoRwsueNGNNhD17+nCY/+6c7epE72fxzdO8zTJONQ=; b=JkEVr/EcTDmXrcWNKegCQd5/FYKX9LNt/vUL07HRSb6K9UNwF2IXtjNZH+o1imeb/q 2Vbp3qa0nGm03nRb2Keow2ZKidEGe4/DJL+MWQuxmNTWH+mnQW2nIuvLFgGoIwB7jkY5 qSdkdoPn7MoBQZPUW+/6DvJ4eD7Q6VgDewWMpEsI6A7PA/g1UF3ad7o2OszY0S+5ika8 gssWrgRlS9naa/x4vBkr0yImEGh5QYExciLq3O8K9QaWGW1HEAlBd+BFqMvq+EBol4VB ijiXZhqiaRkGZx8enQr/vt3y/aUoJhNn24carSr13DQD7+ZgkevQ+DSzKnLt+R66plFZ DENg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@metafoo.co.uk header.s=default header.b=igP73xnI; spf=neutral (google.com: 81.27.85.19 is neither permitted nor denied by best guess record for domain of richard@metafoo.co.uk) smtp.mailfrom=richard@metafoo.co.uk Original-Received: from uk12.easy-internet.co.uk (uk12.easy-internet.co.uk. [81.27.85.19]) by mx.google.com with ESMTPS id c48si336584wrc.469.2018.03.26.22.35.35 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 26 Mar 2018 22:35:35 -0700 (PDT) Received-SPF: neutral (google.com: 81.27.85.19 is neither permitted nor denied by best guess record for domain of richard@metafoo.co.uk) client-ip=81.27.85.19; Original-Received: from mail-oi0-f50.google.com ([209.85.218.50]:43688) by uk12.easy-internet.co.uk with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89_1) (envelope-from ) id 1f0hGe-00029C-0B for std-proposals@isocpp.org; Tue, 27 Mar 2018 06:35:34 +0100 Original-Received: by mail-oi0-f50.google.com with SMTP id u84-v6so8920100oie.10 for ; Mon, 26 Mar 2018 22:35:32 -0700 (PDT) X-Received: by 10.202.87.18 with SMTP id l18mr16594839oib.186.1522128931491; Mon, 26 Mar 2018 22:35:31 -0700 (PDT) In-Reply-To: <627b1086-2f31-402a-92b0-223bf15d33b5@isocpp.org> X-Gmail-Original-Message-ID: X-OutGoing-Spam-Status: No, score=0.1 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - uk12.easy-internet.co.uk X-AntiAbuse: Original Domain - isocpp.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - metafoo.co.uk X-Get-Message-Sender-Via: uk12.easy-internet.co.uk: authenticated_id: metafooc/from_h X-Authenticated-Sender: uk12.easy-internet.co.uk: richard@metafoo.co.uk X-Source: X-Source-Args: X-Source-Dir: X-Original-Sender: richard@metafoo.co.uk X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@metafoo.co.uk header.s=default header.b=igP73xnI; spf=neutral (google.com: 81.27.85.19 is neither permitted nor denied by best guess record for domain of richard@metafoo.co.uk) smtp.mailfrom=richard@metafoo.co.uk 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:37489 Archived-At: --001a113acf404395de05685e42d9 Content-Type: text/plain; charset="UTF-8" On Mon, 26 Mar 2018, 16:53 Edward Catmur, wrote: > > > On Monday, 26 March 2018 22:59:34 UTC+1, Myriachan wrote: >> >> On Monday, March 26, 2018 at 1:39:55 PM UTC-7, Nicol Bolas wrote: >>> >>> >>> >>> On Monday, March 26, 2018 at 4:26:58 PM UTC-4, Myriachan wrote: >>>> >>>> I would like to propose that C++ get a mechanism by which the magical >>>> ability of std::complex * to be reinterpret_cast to T * could be allowed >>>> for other classes. >>>> >>>> A simple case of this is a vector4 type: >>>> >>>> struct vector3 { float x; float y; float z; float w; }; >>>> >>>> The performance difference is strong enough that our project actually >>>> gets a much larger performance *increase* from using >>>> -fno-strict-aliasing versus -fstrict-aliasing with the changes required for >>>> compliance. >>>> >>> > I'm not sure that any such magical ability necessarily exists. Contrary to > the note at cppreference, which does not appear to be derived from any > standards text, the libstdc++ implementation of each specialization > complex has a single NSDM of type __complex__ Fp, that is the > corresponding C type _Complex Fp, which is magic at a language level - they > are specified in section 6.2.5 of ISO/IEC 9899, alongside the other > built-in types. It would likewise be perfectly reasonable for an > implementation to use an array Fp[2] as the NSDM, in which case there would > be no need for any magic AIUI. > > Have you looked at how other standard libraries satisfy this requirement? > > Indeed, other than having to rewrite member variable accesses to member > function calls, is there anything preventing you using a float[4] as the > single NSDM of your vector4 type? > > >> What does strict aliasing have to do with this? The strict aliasing rule >>> is not what prevents you from being able to do this cast. Indeed, nothing >>> prevents you from doing the cast. Since `vector4` is standard layout, the >>> standard *guarantees* that its first subobject shall have the same address >>> as the object itself. So the cast is OK. >>> >>> What isn't OK is the pointer arithmetic that follows, >>> >> >> -fstrict-aliasing breaks our code, even though you're correct that it's >> not an aliasing problem. -fstrict-aliasing seems to enable optimizations >> around pointer arithmetic undefined behavior, and there's no >> -fallow-evil-pointer-arithmetic option. >> >> or the assumption that there is no padding between the elements. >>> >> >> The padding isn't a problem, because a simple static_assert can verify >> that your compiler isn't putting any padding. Such code would be portable >> to any implementation that doesn't put padding. >> >> > It would be a strange implementation indeed that placed padding between or > after members of the same type. I'm not even sure that it's allowed, > alignas excepted. > It is allowed, and ASan has a mode that does this to detect out-of-bounds accesses within a class. Melissa >> > -- > 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. > To view this discussion on the web visit > https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/627b1086-2f31-402a-92b0-223bf15d33b5%40isocpp.org > > . > -- 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. To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAOfiQq%3D-4tNw6mt19ri9L8V2JP8Dh_OPt38WL-%3D10dkEVnYOGA%40mail.gmail.com. --001a113acf404395de05685e42d9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
= On Mon, 26 Mar 2018, 16:53 Edward Catmur, <ed@catmur.co.uk> wrote:


On Monday, 26 March 2018 22:59:34 UTC+1, Myriach= an wrote:
On Monda= y, March 26, 2018 at 1:39:55 PM UTC-7, Nicol Bolas wrote:


On Monday, March 26, 2018 a= t 4:26:58 PM UTC-4, Myriachan wrote:
I would like to propose that C++ get a mechanism by which= the magical ability of std::complex<T> * to be reinterpret_cast to T= * could be allowed for other classes.

A simple case of this is a ve= ctor4 type:

struct vector3 { float x; float y; float z; float w; };<= br>
The performance difference is strong enough that our project actuall= y gets a much larger performance increase from using -fno-strict-ali= asing versus -fstrict-aliasing with the changes required for compliance.
=C2=A0
I'm not sure that any such magical ability necessarily exists. Contrar= y to the note at cppreference, which does not appear to be derived from any= standards text, the libstdc++ implementation of each specialization comple= x<Fp> has a single NSDM of type __complex__ Fp, that is the correspon= ding C type _Complex Fp, which is magic at a language level - they are spec= ified in section 6.2.5 of ISO/IEC 9899, alongside the other built-in types.= It would likewise be perfectly reasonable for an implementation to use an = array Fp[2] as the NSDM, in which case there would be no need for any magic= AIUI.

Have you looked at how other standard libra= ries satisfy this requirement?

Indeed, other than = having to rewrite member variable accesses to member function calls, is the= re anything preventing you using a float[4] as the single NSDM of your vect= or4 type?=C2=A0
=C2=A0
What does strict aliasing have to do with this? The strict aliasing = rule is not what prevents you from being able to do this cast. Indeed, noth= ing prevents you from doing the cast. Since `vector4` is standard layout, t= he standard *guarantees* that its first subobject shall have the same addre= ss as the object itself. So the cast is OK.

What isn't OK is the= pointer arithmetic that follows,

-fstric= t-aliasing breaks our code, even though you're correct that it's no= t an aliasing problem.=C2=A0 -fstrict-aliasing seems to enable optimization= s around pointer arithmetic undefined behavior, and there's no -fallow-= evil-pointer-arithmetic option.

or the assumption that there is no padding = between the elements.

The padding isn&= #39;t a problem, because a simple static_assert can verify that your compil= er isn't putting any padding.=C2=A0 Such code would be portable to any = implementation that doesn't put padding.


It would be a strange implementation indeed that plac= ed padding between or after members of the same type. I'm not even sure= that it's allowed, alignas excepted.

It is allowed, and ASan has a mo= de that does this to detect out-of-bounds accesses within a class.

Melissa

--
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. To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-propo= sals/627b1086-2f31-402a-92b0-223bf15d33b5%40isocpp.org.

--
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/CAOfiQq%3D-4t= Nw6mt19ri9L8V2JP8Dh_OPt38WL-%3D10dkEVnYOGA%40mail.gmail.com.
--001a113acf404395de05685e42d9-- .