220 37493 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: Tue, 27 Mar 2018 05:42:03 -0700 (PDT) Lines: 106 Approved: news@gmane.org Message-ID: References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_18019_1477038113.1522154523740" X-Trace: blaine.gmane.org 1522154402 25523 195.159.176.226 (27 Mar 2018 12:40:02 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 27 Mar 2018 12:40:02 +0000 (UTC) Cc: bop@gmb.dk To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDZLZTXF7UJBBHHY5DKQKGQENKKBAFA@isocpp.org Tue Mar 27 14:39:58 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ua0-f198.google.com ([209.85.217.198]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f0ntO-0006XD-G3 for gclcip-std-proposals@m.gmane.org; Tue, 27 Mar 2018 14:39:58 +0200 Original-Received: by mail-ua0-f198.google.com with SMTP id v4sf8357644uaj.4 for ; Tue, 27 Mar 2018 05:42:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc: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=9b7MVbCAzs/9AZYWdQ/DSPl8bzr4tQD+WVrLmc35uLs=; b=GClSPWH2E8wUolev6liPeMzHAOYqbQzgnssISARJJ/ONRHxjDPR8AlZYERxr5sZ/rr BbpX4alhdaNF5He8rNW780BryvVUGgJogeu06m/u/JxwzwlbAH9e66rqezbQw3ENPjBx fjkhxpQyoQHYU0/7mSwbs4J/o/m3MNZzW2yFjmnIDScK6CY5a2S7r/xL0DLJpWt5un32 B26vOZi5l+Ewp5/EmLqkjrn0c1BIshf+MKkzrQ+U0gS5AzkzQNRw9YJ1DF7c+K4ijaPG pDzjTMpHrheR7mVwUPS+U/ZZfcZ8LnKsrYgdUSMYPo/7MOKmPGTFH7mRGbafFppMRWII OEqA== 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:cc: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=9b7MVbCAzs/9AZYWdQ/DSPl8bzr4tQD+WVrLmc35uLs=; b=ktmo7bCScDNl1nEMOEF6nL2bLx93/QAJizu2cQV976B82kXbqOHDkwvJuahQQSp/8S ZWX31IMvTaJWMSiTB+wArUylrC7onJ7qo4GPornduG0nTCEcZIUlUs8YMEdhlrLHSkYF 2iLaOB6JHYyqVFdRDLjQIoJ181v4Nz38eEimXDcDCLreGPaSUzgCRF+ErIjuGBky7atR Nw2swsSQoqpvOfQy85tEOOHprLU/SL4qf29nRcfGNEC79vvywtl4c7qNBDfys5mQh3gJ QgTl0S+22z5gOzTO4cc7AiuT90QC32iZVRwRBvb1U34LRCFMezyujm25jNffAH+UO1PN 75SQ== X-Gm-Message-State: AElRT7EPSFjWqyv+4p32d4vSWdy4UFSmcCrKFAAvLd8Sm4hHjbbQITzC oLIbOiBo2UxaTtf34QbtZnSHUA== X-Google-Smtp-Source: AG47ELvhCnxXmbMMKr6YMUwPn4NsMVyoCj9iNRuSYtnRAgvAh29MKLRuB3ozUZ+2tWi2GIJvd0zqtA== X-Received: by 10.31.216.198 with SMTP id p189mr18648813vkg.90.1522154525942; Tue, 27 Mar 2018 05:42:05 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.31.160.67 with SMTP id j64ls570527vke.21.gmail; Tue, 27 Mar 2018 05:42:04 -0700 (PDT) X-Received: by 10.31.157.18 with SMTP id g18mr5355812vke.2.1522154524357; Tue, 27 Mar 2018 05:42:04 -0700 (PDT) In-Reply-To: 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:37493 Archived-At: ------=_Part_18019_1477038113.1522154523740 Content-Type: multipart/alternative; boundary="----=_Part_18020_473006291.1522154523740" ------=_Part_18020_473006291.1522154523740 Content-Type: text/plain; charset="UTF-8" On Tuesday, 27 March 2018 01:03:29 UTC+1, Bo Persson wrote: > > On 2018-03-26 22:26, 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. > > > > This is not what the std::complex magic requires from the compiler. > > At least one implementation (MSVC) instead stores a two element array, > which does away with any potential padding and also makes pointer > arithmetic reasonable. > Thanks. I've updated http://en.cppreference.com/w/cpp/numeric/complex (section "Implementation notes") to reflect that MSVC uses the array strategy and that magic is not needed for pointer arithmetic in that case. nb. I'm making an unwarranted but I believe reasonable assumption that the belief that complex is necessarily magic can be traced back to resources like cppreference, and in any case can be successfully challenged there. -- 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/bf65a7d6-c289-4a6b-8da0-c72c97d5a082%40isocpp.org. ------=_Part_18020_473006291.1522154523740 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tuesday, 27 March 2018 01:03:29 UTC+1, Bo Persson wrot= e:
On 2018-03-26 22:26, Myriach= an wrote:
> I would like to propose that C++ get a mechanism by which the magi= cal=20
> ability of std::complex<T> * to be reinterpret_cast to T * c= ould be=20
> allowed for other classes.
>=20
> A simple case of this is a vector4 type:
>=20
> struct vector3 { float x; float y; float z; float w; };
>=20
> The performance difference is strong enough that our project actua= lly=20
> gets a much larger performance /increase/ from using=20
> -fno-strict-aliasing versus -fstrict-aliasing with the changes req= uired=20
> for compliance.
>=20

This is not what the std::complex magic requires from the compiler.

At least one implementation (MSVC) instead stores a two element array,= =20
which does away with any potential padding and also makes pointer=20
arithmetic reasonable.

Thanks. I've updated http://en.cpprefe= rence.com/w/cpp/numeric/complex (section "Implementation notes") = to reflect that MSVC uses the array strategy and that magic is not needed f= or pointer arithmetic in that case.

nb. I'm ma= king an unwarranted but I believe reasonable assumption that the belief tha= t complex is necessarily magic can be traced back to resources like cpprefe= rence, and in any case can be successfully challenged there.

--
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/bf65a7d6-c289-4a6b-8da0-c72c97d5a082= %40isocpp.org.
------=_Part_18020_473006291.1522154523740-- ------=_Part_18019_1477038113.1522154523740-- .