220 37485 <627b1086-2f31-402a-92b0-223bf15d33b5@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Edward Catmur Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Allowing std::complex's magic permission for other types Date: Mon, 26 Mar 2018 16:53:37 -0700 (PDT) Lines: 163 Approved: news@gmane.org Message-ID: <627b1086-2f31-402a-92b0-223bf15d33b5@isocpp.org> References: <6ec944b3-16c3-4f00-b0c9-a449a522d4ac@isocpp.org> <2111ede0-62c6-4a41-8df3-f506d07f09f2@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_16167_1306440531.1522108417508" X-Trace: blaine.gmane.org 1522108296 13573 195.159.176.226 (26 Mar 2018 23:51:36 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 26 Mar 2018 23:51:36 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDZLZTXF7UJBBAUQ43KQKGQE2B6QRMQ@isocpp.org Tue Mar 27 01:51:32 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ua0-f199.google.com ([209.85.217.199]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f0btk-0003Rs-EP for gclcip-std-proposals@m.gmane.org; Tue, 27 Mar 2018 01:51:32 +0200 Original-Received: by mail-ua0-f199.google.com with SMTP id w9sf14173312uae.8 for ; Mon, 26 Mar 2018 16:53:40 -0700 (PDT) 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 :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=d7Q2POgFHWPW7XTYeS/K85lYdzMOwwnWb0uNjLtzxCE=; b=gq13MYp4KIOiPT6OO2Y/obEC5M25/RNrSF4iGMSot/5VVahIJhSGd1/zEI6LhI7u1b n09vwK+GsRzD6zWLD1zgy3Yag5s0b6hEVN44qGCQx9OUmpWO3/nxmVP5dtkSLR9UR8GM P6xunGWiCXdwFUcS21GUjp/qwqUZPHN/yTLLdQFwSKddHVR24xi4FpcbItO+rpsBQ/Cb 0V+IH2Q7zXsEw8jwn7os0JpwMpLk7Uh7QBL1zqtOwXw8zkON1zYjke+4FBXr5rfh76/R pHzRmSEtIdZBLeeBTggtpjIhJ4wNtvZsWx/D7hLNkyru+fTVCnKmtFGqiSC89cDrL+Wf ie3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; 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:list-subscribe:list-unsubscribe; bh=d7Q2POgFHWPW7XTYeS/K85lYdzMOwwnWb0uNjLtzxCE=; b=QRJ7HVPiE9xmRcxJBUK+4t7z/8BGOpjR+UkEEFGpq/E9eiN58YSRhsi+DUbsBzrnda ZQ5bf7fR7UeIcDaob4VVK9fdEKpGwYb7InAksfYJZMVT9AdG0cOTnCqJbT1VyNIn6uP4 tE5xRXcyCJWJEPyaUOiiMX4doz3fN2MB/G7EomulnbTQrJ1ctq5SWmM8bweK3k4e+F5y UaNWdfjAPLUWrWdjfoEWnSPUwwcVHhicYPVdtxpijvH/MKFnYoIC06wQRrIBhEd6zzjI K57RY76KpWSPq5sR82mJzo9hSR2BAQ0k1W21tyxGENLRo/FtZ9eiOm5xI3UeBIgVwxU/ BjkQ== X-Gm-Message-State: AElRT7HGBq/b15TiwhWlLzQ/tF+av0QjxQFfnatR2x+pO6i3uhzIL+wn aefW8zX+3ybGmExw/SqSOy1V+g== X-Google-Smtp-Source: AG47ELsJMVs/kYNCjjgBqgWVSWYvp7lrO2zlO6tVH/hUwLxtpGB7z5EPzDfpu/t90vS2g+m2TlIHUA== X-Received: by 10.31.48.143 with SMTP id w137mr17810576vkw.69.1522108419689; Mon, 26 Mar 2018 16:53:39 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.31.157.199 with SMTP id g190ls1787349vke.10.gmail; Mon, 26 Mar 2018 16:53:38 -0700 (PDT) X-Received: by 10.31.158.83 with SMTP id h80mr5070866vke.9.1522108418043; Mon, 26 Mar 2018 16:53:38 -0700 (PDT) In-Reply-To: <2111ede0-62c6-4a41-8df3-f506d07f09f2@isocpp.org> X-Original-Sender: ed@catmur.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:37485 Archived-At: ------=_Part_16167_1306440531.1522108417508 Content-Type: multipart/alternative; boundary="----=_Part_16168_1007763179.1522108417509" ------=_Part_16168_1007763179.1522108417509 Content-Type: text/plain; charset="UTF-8" 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. > 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. ------=_Part_16168_1007763179.1522108417509 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Monday, 26 March 2018 22:59:34 UTC+1, Myriachan= wrote:
On Mo= nday, 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 whi= ch 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 = vector4 type:

struct vector3 { float x; float y; float z; float w; }= ;

The performance difference is strong enough that our project actua= lly gets a much larger performance increase from using -fno-strict-a= liasing versus -fstrict-aliasing with the changes required for compliance.<= /div>
=C2=A0
I'm not sure that any such magical ability necessarily exists. Contr= ary to the note at cppreference, which does not appear to be derived from a= ny standards text, the libstdc++ implementation of each specialization comp= lex<Fp> has a single NSDM of type __complex__ Fp, that is the corresp= onding C type _Complex Fp, which is magic at a language level - they are sp= ecified in section 6.2.5 of ISO/IEC 9899, alongside the other built-in type= s. It would likewise be perfectly reasonable for an implementation to use a= n array Fp[2] as the NSDM, in which case there would be no need for any mag= ic AIUI.

Have you looked at how other standard lib= raries satisfy this requirement?

Indeed, other tha= n having to rewrite member variable accesses to member function calls, is t= here anything preventing you using a float[4] as the single NSDM of your ve= ctor4 type?=C2=A0
=C2=A0
What does strict aliasing have to do with this? The strict al= iasing rule is not what prevents you from being able to do this cast. Indee= d, nothing prevents you from doing the cast. Since `vector4` is standard la= yout, the standard *guarantees* that its first subobject shall have the sam= e 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&#= 39;s not an aliasing problem.=C2=A0 -fstrict-aliasing seems to enable optim= izations around pointer arithmetic undefined behavior, and there's no -= fallow-evil-pointer-arithmetic option.

or the assumption that there i= s no padding between the elements.

The= padding isn't a problem, because a simple static_assert can verify tha= t your compiler isn't putting any padding.=C2=A0 Such code would be por= table to any implementation that doesn't put padding.


It would be a strange implementation ind= eed that placed padding between or after members of the same type. I'm = not even sure that it's allowed, alignas excepted.
=C2=A0
Meliss= a

--
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/627b1086-2f31-402a-92b0-223bf15d33b5= %40isocpp.org.
------=_Part_16168_1007763179.1522108417509-- ------=_Part_16167_1306440531.1522108417508-- .