220 37479 <6ec944b3-16c3-4f00-b0c9-a449a522d4ac@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Allowing std::complex's magic permission for other types Date: Mon, 26 Mar 2018 13:39:55 -0700 (PDT) Lines: 81 Approved: news@gmane.org Message-ID: <6ec944b3-16c3-4f00-b0c9-a449a522d4ac@isocpp.org> References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_15556_1354457546.1522096795603" X-Trace: blaine.gmane.org 1522096679 24437 195.159.176.226 (26 Mar 2018 20:37:59 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 26 Mar 2018 20:37:59 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBHFV4XKQKGQEZOQSWHI@isocpp.org Mon Mar 26 22:37:55 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 1f0YsN-0006CR-7O for gclcip-std-proposals@m.gmane.org; Mon, 26 Mar 2018 22:37:55 +0200 Original-Received: by mail-ua0-f199.google.com with SMTP id g19sf5241041uan.20 for ; Mon, 26 Mar 2018 13:39:57 -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=94rVdgwCfk4ThxO52NlKLlNZuM1oupouTWTxVLNeir0=; b=lR9oyk3cMpq+tL3ZBNi/I4oWV+O3efdtopxOleYrRyyD4wSf1/sYCZESrUN4cUja8l vfjRrEm4dswTUxn0P1WG7LlP99YmAiGj7gxdE7GfbEBqraAaEaMlMJNXaRLtXScvnJGD QAIIoWdN7K083M9uNCTmEKkLru73dYe7CML8p/dmsCKq+YMmDNyckuA1ydWHpnpELcdN yiEEW+Qm/6A5a55thrbLvc74jH7HJjaY6YzsxMTIBj+6jlCtleBmvb1WfLQLg7PLTZhy J5/I4w1nQi1y5KlyAzljEvbU6rMrIuhJb8nS0DIA2sXbbgZFJ+gl0i83V+jjvUdHz0P0 haSg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; 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=94rVdgwCfk4ThxO52NlKLlNZuM1oupouTWTxVLNeir0=; b=S9szBt0QsN/BEM7ugJK1CUhLV6s2V09xiG4JB/+dSwY79eEkNOfl+x/ntN3L9vWDn1 xZJoW42pfOl9z9Z+LPL7bnqVkmNUo7oVn8Q5aNsXh0bd8rd3o/EiHJMa/815G6U+rg9h PlGUY6lXM9NCjK1stJMjrjfc0xxXDIiS/mH27wdcvPY0RQLxQ9eXWHaCY9u64DxB/q/m 7z+DhMxIhbj3Xaq5PUouE1xe+mfJcrXZz9S2TOSfyz8Cax7gf27PIxGOO5ZN74/IT5a5 LoGejGyouiM+bgPT+Ww3CqwPx6rTkhvN8Iht2p4TZceK3Ftnt06UgfeZff+3K7eEpP4G UzVw== 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=94rVdgwCfk4ThxO52NlKLlNZuM1oupouTWTxVLNeir0=; b=h88fgd+sYcpgttkVrHtf5M5xuQw//EH7xpImAxC6hE9SP6GhkkAHZ6ERO8OXGKeXWK wUG0I+R9d2sraVDJOjWLG08MW5PRvsulWWYZ/FZkAePaoVdF68oKc6CGhEJkZzb8/Xbt OGfBbCscTd2nP7eH3TcrW0XdDZ5pbah7FyhWb/nEfxCiaS4u+yl4FRGxg/BFzCZ41nX+ gJTPzHjjj+LrR9rBWBPfpbhCy2nVCMwQXh+AWBWUSIbEZw1iHVNyo69+8NDDWygJfdIM d2nDeE0IGwsDG/tf4F4Br3Gnh7uqRPUz9hSUNDTAv7/S06TW2QjQGAkbljkkmqoAhgan xVOg== X-Gm-Message-State: AElRT7Gwzjv8Eh+5QR8Jy/sv+oXru0bIBjggS6KgyLrw8BOovM5WZoCX Pdj4+WonoGV8M8JKpwTddC9H2g== X-Google-Smtp-Source: AG47ELvCUBXoYt1cXEPgAQvTyP2CmmUezvRXQsTfKQRsPGpQQ8MQNVThdR8cyqlEc4wyzXBXp4tFyw== X-Received: by 10.31.161.14 with SMTP id k14mr17049133vke.68.1522096797322; Mon, 26 Mar 2018 13:39:57 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.31.86.129 with SMTP id k123ls8831367vkb.5.gmail; Mon, 26 Mar 2018 13:39:56 -0700 (PDT) X-Received: by 10.31.69.207 with SMTP id s198mr1258330vka.0.1522096795957; Mon, 26 Mar 2018 13:39:55 -0700 (PDT) In-Reply-To: X-Original-Sender: jmckesson@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:37479 Archived-At: ------=_Part_15556_1354457546.1522096795603 Content-Type: multipart/alternative; boundary="----=_Part_15557_596373869.1522096795603" ------=_Part_15557_596373869.1522096795603 Content-Type: text/plain; charset="UTF-8" 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. > 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, or the assumption that there is no padding between the elements. -- 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/6ec944b3-16c3-4f00-b0c9-a449a522d4ac%40isocpp.org. ------=_Part_15557_596373869.1522096795603 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Monday, March 26, 2018 at 4:26:58 PM UTC-4, Myr= iachan wrote:
= I would like to propose that C++ get a mechanism by which the magical abili= ty of std::complex<T> * to be reinterpret_cast to T * could be allowe= d for other classes.

A simple case of this is a vector4 type:
struct vector3 { float x; float y; float z; float w; };

The perform= ance difference is strong enough that our project actually gets a much larg= er performance increase from using -fno-strict-aliasing versus -fstr= ict-aliasing with the changes required for compliance.

What does strict aliasing have to do with this? The strict alias= ing 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 layou= t, the standard *guarantees* that its first subobject shall have the same a= ddress as the object itself. So the cast is OK.

What isn't OK is= the pointer arithmetic that follows, or the assumption that there is no pa= dding between the elements.

--
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/6ec944b3-16c3-4f00-b0c9-a449a522d4ac= %40isocpp.org.
------=_Part_15557_596373869.1522096795603-- ------=_Part_15556_1354457546.1522096795603-- .