220 37508 article Path: news.gmane.org!.POSTED!not-for-mail From: Myriachan Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Allowing std::complex's magic permission for other types Date: Tue, 27 Mar 2018 16:17:56 -0700 (PDT) Lines: 103 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_4095_396938688.1522192676957" X-Trace: blaine.gmane.org 1522192556 14655 195.159.176.226 (27 Mar 2018 23:15:56 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 27 Mar 2018 23:15:56 +0000 (UTC) Cc: bop@gmb.dk To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDKLT4PURQHRBJNC5PKQKGQEYCTVNQY@isocpp.org Wed Mar 28 01:15:52 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ua0-f197.google.com ([209.85.217.197]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f0xol-0003iO-ID for gclcip-std-proposals@m.gmane.org; Wed, 28 Mar 2018 01:15:51 +0200 Original-Received: by mail-ua0-f197.google.com with SMTP id t34sf430292uat.3 for ; Tue, 27 Mar 2018 16:17:59 -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=Yom3sa57VN4OqplbpDtZ2kjsLWxtujQMaR8XofiSm/o=; b=JfZW6E7+QIQkBAxmFup4peVQERo+JV8u2mnIoglT4tmGBkuT2QwiU/KnvV9dfntcK0 lt/O2By8Jzygr5ZR0aomhZq3+S3BOOgXXXv2lhqAp/1zCXXlREMjVP18xoXhH1eJ78JQ nizndpTv5qbe28HE2JrY/PDFGeWzmWDX8JUn7uFXQN1Jkc/aLvqK+/h8vPRf1z2jgHFU DyQNl5KRXvjp3Lm7pPzP1VPBCiNFakyJIEM75BJvWj7UWD2JbxzHG4PHbwVhKBceWdmD H5mpdmAMFKum73oCdTto/026aJUabCKXwedYrNrRDRGg06421L5EkM4wdnX7NZnDBIaf aFkw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; 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=Yom3sa57VN4OqplbpDtZ2kjsLWxtujQMaR8XofiSm/o=; b=fGbtY1Si8JZHabs1+lC4bRP0sMEtR668ZcDaxL3zcOYpF+EYTYWR4MtdBlX0EnOLrx hW2ImZmOcheYIECWfpYv2nS0mkI6Omy4Dn+iKb7NkbQsAY2jurJeuk6nXp+rf+j+4g+a F5RdysW5IX/xYPfNZCtqVhnbzps9PASYLc87ejTMr3sMAE1ztczgeK/7Ht9Hy5+PIHen QBqpLOhpQzbwkT3konKYC+oYM6SxBwDLmUAhc3o4SktiIi1dnUEQrZwThB7GFnAt3ORg xpk/GabXA7QynfTlMWoO7+dQs8aEz2S14SLxZm/WYYBMh2rin4pSwuIp1GSK1I3Ho7sI HA7A== 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=Yom3sa57VN4OqplbpDtZ2kjsLWxtujQMaR8XofiSm/o=; b=JcC4FH247wDT4LwSu/jr0+NO8Jei1scG0RygL6Ik6CHq+U2kKBrEtGtJCaB+5vKHbs GF6TgRrUe4Bb3mPbR1qDHIXy9wgRIzf9EkQ5EfkmQc2STvor4/n7nnNa8A9TYA+9TBOd WsmDH/NKC9mEtKKJthb52ySOfvltuXXM/Otyh62CHBOI3gyE6Gi5RJLxNwo0eMpUh31w uLi/3Mmiz9EBxwGhO6bxX74vnycDP52u7FFsyX23UWKVqe8HKko4m7q0WhWNtyqizt3j OyVKwr144gz7bonudIboBPj7Sm9tVy2+PyUeJCy2qrTuNUdiEvIMGvHu9orSrEFjmH63 7xDQ== X-Gm-Message-State: AElRT7HcHUgkJvnGAz1IT4nwxjbwu3N3RUR9EmvZ2pS8U+JCqkRSWa7w MmuxrWHwtGZW3rpAO2ZRq8zxJQ== X-Google-Smtp-Source: AG47ELtmyaYHUD5/eXEP4dY6LX1f8LYA/wTW6sBTiJX8n4TaJQC76DXmCnNEtcvDH0FV3FG+N+ynqw== X-Received: by 10.176.28.75 with SMTP id o11mr19888062uaj.81.1522192678973; Tue, 27 Mar 2018 16:17:58 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.31.151.8 with SMTP id z8ls1510875vkd.9.gmail; Tue, 27 Mar 2018 16:17:57 -0700 (PDT) X-Received: by 10.31.32.148 with SMTP id g142mr871569vkg.1.1522192677459; Tue, 27 Mar 2018 16:17:57 -0700 (PDT) In-Reply-To: X-Original-Sender: myriachan@gmail.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: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:37508 Archived-At: ------=_Part_4095_396938688.1522192676957 Content-Type: multipart/alternative; boundary="----=_Part_4096_194246022.1522192676957" ------=_Part_4096_194246022.1522192676957 Content-Type: text/plain; charset="UTF-8" On Monday, March 26, 2018 at 5:03:29 PM UTC-7, 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. > The C++ Standard rules state that you can treat an array of std::complex as an array of float of double the number of elements. That is, you can do pointer arithmetic on a float * that crosses complex objects. That cannot be done other than with compiler magic. (Or compiler ignorance, which is how we've gotten away with it so far.) -- 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/e85dfb30-f3ff-4769-90d2-373efceda1e6%40isocpp.org. ------=_Part_4096_194246022.1522192676957 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Monday, March 26, 2018 at 5:03:29 PM UTC-7, Bo Persson = wrote:
On 2018-03-26 22:26, Myr= iachan 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.

The C++ Standard rules state that you can treat a= n array of std::complex<float> as an array of float of double the num= ber of elements.=C2=A0 That is, you can do pointer arithmetic on a float * = that crosses complex<float> objects.=C2=A0 That cannot be done other = than with compiler magic.=C2=A0 (Or compiler ignorance, which is how we'= ;ve gotten away with it so far.)

--
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/e85dfb30-f3ff-4769-90d2-373efceda1e6= %40isocpp.org.
------=_Part_4096_194246022.1522192676957-- ------=_Part_4095_396938688.1522192676957-- .