220 37512 article Path: news.gmane.org!.POSTED!not-for-mail From: "'Edward Catmur' via ISO C++ Standard - Future Proposals" Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Allowing std::complex's magic permission for other types Date: Wed, 28 Mar 2018 07:17:27 +0000 Lines: 168 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/alternative; boundary="089e082d4ae844f16b056873cde2" X-Trace: blaine.gmane.org 1522221340 27964 195.159.176.226 (28 Mar 2018 07:15:40 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 28 Mar 2018 07:15:40 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDZLZTXF7UJBBEUD5XKQKGQE6F5Q25Y@isocpp.org Wed Mar 28 09:15:36 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-wr0-f198.google.com ([209.85.128.198]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f15Iy-00079N-8y for gclcip-std-proposals@m.gmane.org; Wed, 28 Mar 2018 09:15:32 +0200 Original-Received: by mail-wr0-f198.google.com with SMTP id 31sf705194wrr.2 for ; Wed, 28 Mar 2018 00:17:40 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1522221460; cv=pass; d=google.com; s=arc-20160816; b=ZtKxQqFK74jKmqATDlzDTcneFg7y05SZAcSU1ABPXdhi01JCrgaygYazh2r418ZJ9R wkmWWRAvP3+3eA6CeAFE+PCZTjtE2Ajp8s6L5LQWt0kJiK/jGqZajE5B7dkm6La+hj+j b1SlETiWUldGpIJhg6WaF2bm9NGNJWmBYSjQsVzxxak+9c+JKPWTDqmOZ7+9NdAr7MTd 3QLTM0ZNLLZjbNuC7sDCcOa4JMXN3kXHWtPKB8NQ8nwbqrv8J8QmAR+D+4pWYZNBidP2 wCiFQnBpDN3OXOFFXhPWzLvk7VTbIkdqSrSw1sIpw+flFDPO2Lie/UjnLYBE3NShTA8q Ntsg== 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=WGY4f7IBuvR5c3ZBGTeolbEO5Op0rhTzdBHH3TCSPNU=; b=F5ryu29btFPVTsMFgI326Jxa48krz5sZjXBaTvfbYpF9mPCllGD3fTCa8/IoaLr2NW T1FrjqK6CnXTTGIr0wpsPGR91KSjHEdIw9bwuGfIDLxm6l24TOdR1w9NblAjU0b4K694 fPkUjRBolpi4lZ5OtpWdNScbDvBHOQTEx+3NEM8YRLO468HN8npyvcizwk5njXKT4Tr5 FXbsW8urgUZWtFRnROHmt7MmRkYwnoeL4lUmj5BEgrvd6g5Zbd+XzVnU2/BwCf4oy8tI +e8KqTC0TptMeRCV8oHHEx4TJoPTjCTZciADTxcYM13UOfqzDQ+3UdILHMcTZyN+R4QL apvg== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@googlemail.com header.s=20161025 header.b=n9rlF/aK; spf=pass (google.com: domain of ecatmur@googlemail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=ecatmur@googlemail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=googlemail.com 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=WGY4f7IBuvR5c3ZBGTeolbEO5Op0rhTzdBHH3TCSPNU=; b=XmU2P6pw1hBvH/W5kDR7k2HkArJaSNnbyWhsy4Qq1mSBtp9Y+2O5+09kFrnikM/Sn6 HTWCO5MrZSmkc7eQZ01mhomM16v9xvHkWGsppTYOXSwfeHTdhXFrO/Mq+EvLMSJuh4Du UtXi5S2xt5aPXT89Mq5OZLHf5FZq4+dmnVo9Wt5Hj8YT7/E4/DQT19JE3la1rZYINLtV eY1VpF1l9e/7Fk5qTgAChtNOtU0FOdlNq/QlLvK+VO1AjOfxgdMIx6Q9YV6EgwGwDY5n iNEgFScvWfFwjYA+GrTCnOikMJ0Pi+Yu19SfN9wSXwpYFLI/NmfmSu3kWx0dqxbG+yt0 qCgQ== 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=WGY4f7IBuvR5c3ZBGTeolbEO5Op0rhTzdBHH3TCSPNU=; b=tDES5sW3HOBGOqptCL1aMFc1aVpQK5ZGmTIW4s0X1w3+M9gHv3Pj7w9YxHFoC52duS 8UrEakjz0CvXqdeFMs9XcIDD4nqWW6r9WxXnP2OtpNaqNMj96g6rpuGmCU8P0FT184E7 b3SHLxmJtWgclGhml3AHmHIyU8xw+izJraIXg5O3YuPVL7KX11Y3Qxa+eRqjxi26VofU KJAhgN0g4gsoqwEDLVhNAa57BlT6gcelSq83KCZ7U/kfv4jjf2XK9HVqWpZ2I5DW5Qr2 Qs4Y4bBkcmJv73dBlGA6TiSwPS/4TbYvyL1Qsyxz3IoKZE2SPMFj6qEzUT4Ifbjt0DcZ LZoA== X-Gm-Message-State: AElRT7EUdmd0xA33uN2GU0ViVchvUvjDH1U99WSWuVAakDkeylYg0A6O zChwW4hkWO+uwBazh3NzU/I= X-Google-Smtp-Source: AG47ELsExtk+cjmPjJM8M847bHU2c/FJ6J5FJ95RGntlblrq20/ndZNGF/iSL/i4IsnfbhsKq50eIA== X-Received: by 10.28.26.147 with SMTP id a141mr2716186wma.12.1522221459977; Wed, 28 Mar 2018 00:17:39 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.28.59.137 with SMTP id i131ls693494wma.6.canary-gmail; Wed, 28 Mar 2018 00:17:38 -0700 (PDT) X-Received: by 10.28.214.199 with SMTP id n190mr1607603wmg.16.1522221458437; Wed, 28 Mar 2018 00:17:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1522221458; cv=none; d=google.com; s=arc-20160816; b=fTiaL83yS7+jZWpftKxVR4AIwNZMtM4dqJUKdxDm2t8wXJ35UABPimPkAa+RgrhDfo trwLXkatOK02HxcsLwFJ0fj8EM8l4PTj4TjCPfyaI1ExqzDhqb0LSG1I6x3BwjrYpZfZ iO9FMKflllhZkALwb5lfHnH3OcnwqVoeFqwELGNhFQi/3AHoE7BnUI7/CsPyv6Q3O50g GokpHjEPqocJCSTu3y277tZS3J8GYTcKs1nRP/KNA7mf5e6xp4C/dJWypBCRgoWTTxro Hj1NGWCHwOeRIfSjrf6iOACM05LlNd80HgzIcs4vxtNeO+ha5HWOzVPLqfyEuhLhb6Tu aZhw== 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=vAU3hYxLvc0kgvy+21NlOp8InJP6vdGgq8/jYtaoUzs=; b=aa/8gSMV0cF6P6OdP+mvuo/Ud+8ALWVbIEP4rTC86oaKuwC5PBAnjPmd+QdPwMMq0y P73QZAsxU/lsbbYHNy9nYoN6EPE3Cu9t91RvSyYMXI/tmu0ZrWTKbG9bI768UlrOeCmG phi/jo++1Ma5d3O1LuDKBe1ylPr+JNdOnzAJTUGIMmH1aW49NQKM5+3Rao6zTTRKVOLV meSU4dm4KB0POCoH+dxfI2XYpoBp8CJIRv/F/q5gCrTyIoHXPN+MJ9XyiMN1L1+GR+pp gA3+6zWUqitt+8EzGE2Mx9fyaVcoxW62+5+fadCL1TgPd54/unjD50gLoFL5lAuyu687 vKlA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@googlemail.com header.s=20161025 header.b=n9rlF/aK; spf=pass (google.com: domain of ecatmur@googlemail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=ecatmur@googlemail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=googlemail.com Original-Received: from mail-sor-f41.google.com (mail-sor-f41.google.com. [209.85.220.41]) by mx.google.com with SMTPS id r2sor804843wmc.67.2018.03.28.00.17.38 for (Google Transport Security); Wed, 28 Mar 2018 00:17:38 -0700 (PDT) Received-SPF: pass (google.com: domain of ecatmur@googlemail.com designates 209.85.220.41 as permitted sender) client-ip=209.85.220.41; X-Received: by 10.28.124.24 with SMTP id x24mr1720695wmc.6.1522221457927; Wed, 28 Mar 2018 00:17:37 -0700 (PDT) In-Reply-To: X-Original-Sender: ecatmur@googlemail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@googlemail.com header.s=20161025 header.b=n9rlF/aK; spf=pass (google.com: domain of ecatmur@googlemail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=ecatmur@googlemail.com; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=googlemail.com X-Original-From: Edward Catmur 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:37512 Archived-At: --089e082d4ae844f16b056873cde2 Content-Type: text/plain; charset="UTF-8" On Wed, 28 Mar 2018, 00:18 Myriachan, wrote: > 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 haveer than with compiler > magic. (Or compiler ignorance, which is how we've gotten away with it so > far.) > Right, so we can infer that MSVC allows treating an array of n struct of array of m T as an array of n*m T. If that ever changes they will need to add magic to their complex, but as it is MSVC's complex does not need magic. I suppose that means that they could expose the magic as a no-op, but how would you expose that the required class formation is struct of array of m T, rather than your (and clang's) struct of m T data members? And as for gcc, libstdc++ complex gets its magic from C _Complex. That means the magic it uses is already available to you, but is not useful to you as it only works for the case of 2 components. -- > You received this message because you are subscribed to a topic in the > Google Groups "ISO C++ Standard - Future Proposals" group. > To unsubscribe from this topic, visit > https://groups.google.com/a/isocpp.org/d/topic/std-proposals/HpRRF7RWzTY/unsubscribe > . > To unsubscribe from this group and all its topics, 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 > > . > -- 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/CAJnLdOanFv25KDw0fMu%3D-pZ%3D%2BTfis1rzOHXR_eZXUJX9ezAeTg%40mail.gmail.com. --089e082d4ae844f16b056873cde2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


= On Wed, 28 Mar 2018, 00:18 Myriachan, <myriachan@gmail.com> wrote:
On Monday, March 26, 2018 at 5:03:29 PM UTC-7, Bo Pe= rsson wrote:
On 2018-03-26 22:26, My= riachan 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 haveer= than with compiler magic.=C2=A0 (Or compiler ignorance, which is how we= 9;ve gotten away with it so far.)
<= div dir=3D"auto">
Right, so we can infer that MS= VC allows treating an array of n struct of array of m T as an array of n*m = T. If that ever changes they will need to add magic to their complex, but a= s it is MSVC's complex does not need magic.=C2=A0

I suppose that means that they could expose t= he magic as a no-op, but how would you expose that the required class forma= tion is struct of array of m T, rather than your (and clang's) struct o= f m T data members?=C2=A0

And as for gcc, libstdc++ complex gets its magic from C _Complex. That me= ans the magic it uses is already available to you, but is not useful to you= as it only works for the case of 2 components.=C2=A0

--
You received this message because you are subscribed to a topic in the Goog= le Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this topic, visit https://groups.google.com/a/isocpp.org/d/topic/std-pr= oposals/HpRRF7RWzTY/unsubscribe.
To unsubscribe from this group and all its topics, 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-propo= sals/e85dfb30-f3ff-4769-90d2-373efceda1e6%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/CAJnLdOanFv= 25KDw0fMu%3D-pZ%3D%2BTfis1rzOHXR_eZXUJX9ezAeTg%40mail.gmail.com.
--089e082d4ae844f16b056873cde2-- .