220 32090 <4259d7dc-f060-dc27-5004-37bf4726e456@wanadoo.fr> article Path: news.gmane.org!.POSTED!not-for-mail From: "Vicente J. Botet Escriba" Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Decomposition of std::complex. Date: Fri, 14 Apr 2017 19:01:55 +0200 Lines: 1844 Approved: news@gmane.org Message-ID: <4259d7dc-f060-dc27-5004-37bf4726e456@wanadoo.fr> References: <74a45396-2e35-4231-86b9-4caceb531239@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------------405F0B4D6009C044D992406E" X-Trace: blaine.gmane.org 1492189320 27953 195.159.176.226 (14 Apr 2017 17:02:00 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 14 Apr 2017 17:02:00 +0000 (UTC) User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDH67CONY4PBBBMBYTDQKGQEMM2NSRY@isocpp.org Fri Apr 14 19:01:55 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-lf0-f69.google.com ([209.85.215.69]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cz4bb-0007AK-Cw for gclcip-std-proposals@m.gmane.org; Fri, 14 Apr 2017 19:01:55 +0200 Original-Received: by mail-lf0-f69.google.com with SMTP id p10sf14230159lfe.11 for ; Fri, 14 Apr 2017 10:02:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-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=u9A7y+OArsz/J0NwD8K6nfahgAQxY89YbZo5KXdvwrA=; b=yBO641uIDjq5sLw85HDPOnVCJ+qcKxZXinPlTcvIhU6FF/WkPBn4yKq0UkSHIS0Q5z 0R1s3jDxCAYx006PdEcHDRtC6A4ND3i1gv1coqyB+FoqeBuFSrblQJDfJ9s/taLmALa+ DpSnXR4uCy+c7iPWR3o5hwXX2O4I8P9io8hy8LLxYc/405CAtdEcRd7K4+1BAEG+FK8n r0VOV9gyYYwrYCFkMOC7AAsf1cG+JN9X/ox6W8k4MCTUg5mz8b7ud6yprHJg0pw1gtAU Uwqd3kK9wnoj6gBN8QGukPI7z8TI8xEJ5xGqWMtHlVUzamAxtgiEjzsbWuOpZsVvHaOo zP6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-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=u9A7y+OArsz/J0NwD8K6nfahgAQxY89YbZo5KXdvwrA=; b=Gih5syfeQ3m2vRU29C0+U8H+S5eD7WSTfP1Ubp5Tyuh2otn4ZfrQhX+9pLqAO1inV5 MLaZzpp8/6HUo3BD02DXLajo067VFUeOmOTypBp+TliI4y2d10rGPHQyVQAJ9X86apVW eQ8FXt466+/iGuDL/UYL2Oke9AAOYl+169Pes8XoSCmzmXefZnA7KKQzgpJ+mM+NOxQN /HRiYDDs82XVSfKvgo8kKauDI9FAHwlR6SLhnAkWfPWbw1KYYxeaLnNSFCId5Utcscs1 QeRYbEGpY1zFeFIaJuNDoWZlXJZHjO21FgRwkDiiP6xj+fYg97y/i2Qne5kUqy4AQWik 2ygw== X-Gm-Message-State: AN3rC/4KEI/yjh0uk60DtACZlCXB5ra4Ottc2wIGiwMy7/k9qr6XbwHl OBwgE9je8pSnTQ== X-Received: by 10.46.0.230 with SMTP id e99mr955225lji.15.1492189320970; Fri, 14 Apr 2017 10:02:00 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.28.208.1 with SMTP id h1ls341595wmg.16.gmail; Fri, 14 Apr 2017 10:01:57 -0700 (PDT) X-Received: by 10.28.69.147 with SMTP id l19mr8175553wmi.91.1492189317147; Fri, 14 Apr 2017 10:01:57 -0700 (PDT) Original-Received: from smtp.smtpout.orange.fr (smtp03.smtpout.orange.fr. [80.12.242.125]) by mx.google.com with ESMTPS id i124si4177997wmd.116.2017.04.14.10.01.56 for (version=TLS1 cipher=AES128-SHA bits=128/128); Fri, 14 Apr 2017 10:01:57 -0700 (PDT) Received-SPF: neutral (google.com: 80.12.242.125 is neither permitted nor denied by best guess record for domain of vicente.botet@wanadoo.fr) client-ip=80.12.242.125; Original-Received: from imac-de-vicente-botet-escriba.home ([81.53.17.208]) by mwinf5d79 with ME id 8H1v1v00L4VM3XV03H1vAj; Fri, 14 Apr 2017 19:01:56 +0200 X-ME-Helo: imac-de-vicente-botet-escriba.home X-ME-Auth: dmljZW50ZS5ib3RldEB3YW5hZG9vLmZy X-ME-Date: Fri, 14 Apr 2017 19:01:56 +0200 X-ME-IP: 81.53.17.208 In-Reply-To: <74a45396-2e35-4231-86b9-4caceb531239@isocpp.org> X-Original-Sender: vicente.botet@wanadoo.fr X-Original-Authentication-Results: mx.google.com; spf=neutral (google.com: 80.12.242.125 is neither permitted nor denied by best guess record for domain of vicente.botet@wanadoo.fr) smtp.mailfrom=vicente.botet@wanadoo.fr Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: 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:32090 Archived-At: This is a multi-part message in MIME format. --------------405F0B4D6009C044D992406E Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Le 14/04/2017 =C3=A0 00:11, 3dw4rd@verizon.net a =C3=A9crit : > In many uses of std::complex > one wants to capture the real and imaginary parts in separate=20 > variables either to use them in subsequent calculations or to modify=20 > them individually. > There are many options: > > These options reflect an over-encapsulation of std::complex, which=20 > everyone agrees is a struct with two floating point numbers, real part=20 > and imaginary part, in that order. > Attempting to use a decomposition declaration for a complex number is=20 > an error because of the pretension (ostensibly for C compatibility)=20 > the complex numbers are opaque. Humm, it is not so opaque as you can get the representation as a c-array. This means that we should already be able to apply structured binding=20 using the cast |auto&[p,q]=3D|||reinterpret_cast(z)|; | Nevertheles I agree with you that your proposal makes this cleaner and=20 more explicit. Complex should be a ProductType. > > The rvalue and lvalue decomposition of std::complex can be=20 > accomplished with a simple pure-library extension: > Provide a tuple interface to std::complex. > > | > // Tuple interface to class template complex. > #define__cxx_lib_tuple_complex 201705 > > // Declare tuple_size. > template > classtuple_size; > > // Partial specialization for std::complex. > template > structtuple_size> > :publicintegral_constant{}; > > // Declare tuple_element. > template > classtuple_element; > > // Partial specialization for std::complex. > template > structtuple_element<_Int,std::complex> > { > static_assert(_Int <2,"index is out of bounds"); > typedefRealTptype; > }; > > // Decompose complex as rvalues. > template > constexprconstRealTp > get(conststd::complex&z) > { > static_assert(_Int <2,"index is out of bounds"); > return_Int =3D=3D0?z.real():z.imag(); > } > > // Decompose complex as lvalues. > template > constexprRealTp& > get(std::complex&z) > { > static_assert(_Int <2,"index is out of bounds"); > autow =3Dreinterpret_cast(z); > return_Int =3D=3D0?w[0]:w[1]; > } > > | > I believed that this reinterpret_cast was UB, but as you note below, it=20 is defined by the standard. > > Then we have the following behavior: > > | > template > void > test_complex_decomp() > { > std::complexz(1,2); > > auto[x,y]=3Dz; > std::cout <<"z =3D "< std::cout <<"z parts:"<<' '< > | |I'm not sure if you believe this implies a call to get to decomponse as=20 rvalues, but it isn't. It just copies the complex to a temporary, ||and then calls get on this=20 temporary. | > | > z.real(3); > z.imag(4); > std::cout <<"z =3D "< std::cout <<"z parts:"<<' '< > std::complexw(1,2); > std::cout <<"w =3D "< auto&[p,q]=3Dw; > > | |I'm not sure if you believe this implies a call to get to decomponse as=20 lvalues, but it isn't. ||It just takes store a reference to the complex in a temporary, and=20 then calls get on this temporary reference. | > | > | > | > w.real(3); > w.imag(4); > std::cout <<"w =3D "< std::cout <<"w parts:"<<' '<

> p =3D-5; > q =3D-6; > std::cout <<"w =3D "< std::cout <<"w parts:"<<' '<

> return; > } > > int > main() > { > test_complex_decomp(); > return0; > } > > | > > > ------------------- > z =3D (1,2) > z parts: 1 2 > z =3D (3,4) > z parts: 1 2 > w =3D (1,2) > w =3D (3,4) > w parts: 3 4 > w =3D (-5,-6) > w parts: -5 -6 > ------------------- > > The static cast, ugly as it is, is required to be valid by conforming=20 > implementations of complex. Are you talking of the reinterpret_cast? > 29.5 Complex numbers [complex.numbers] p4, specifically 4.1-4.3. > This solution elegantly isolates user code from this wart. I believe that you need const/non const lvalue/rvalue decomposition, but=20 maybe I'm wrong. |template constexprconstRealTp&& get(const std::complex&& z) { static_assert(_Int <2,"index is out of bounds"); return_Int =3D=3D0?z.real():z.imag(); } | ||template constexprRealTp&& get(std::complex&& z) { static_assert(_Int <2,"index is out of bounds"); return_Int =3D=3D0?z.real():z.imag(); } | // Decompose complex as lvalues. template constexprRealTp& get(std::complex&z) { static_assert(_Int <2,"index is out of bounds"); autow =3Dreinterpret_cast(z); return_Int =3D=3D0?w[0]:w[1]; } | |// Decompose complex as lvalues. template constexprRealTpconst& get(const std::complex&z) { static_assert(_Int <2,"index is out of bounds"); autow =3Dreinterpret_cast(z); return_Int =3D=3D0?w[0]:w[1]; } | Vicente --=20 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 e= mail 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/4259d7dc-f060-dc27-5004-37bf4726e456%40wanadoo.f= r. --------------405F0B4D6009C044D992406E Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Le 14/04/2017 =C3=A0 00:11, 3dw4rd@verizon.net a =C3=A9crit=C2=A0:
In many uses of std::complex
one wants to capture the real and imaginary parts in separate variables either to use them in subsequent calculations or to modify them individually.
There are many options:

These options reflect an over-encapsulation of std::complex, which everyone agrees is a struct with two floating point numbers, real part and imaginary part, in that order.
Attempting to use a decomposition declaration for a complex number is an error because of the pretension (ostensibly for C compatibility) the complex numbers are opaque.
Humm, it is not so opaque as you can get the representation as a c-array.

This means that we should already be able to apply structured binding using the cast

=C2=A0 =C2=A0 auto& [p, q] =3D = reinterpret= _cast<= Tp(&)[2]>(z);

Nevertheles I agree with you that your proposal makes this cleaner and more explicit. Complex should be a ProductType.

The rvalue and lvalue decomposition of std::complex can be accomplished with a simple pure-library extension:
Provide a tuple interface to std::complex.

=C2=A0 // Tuple interface to class template complex.
#define __cxx_lib_tuple_complex 201705

=C2=A0 // Declare tuple_size.<= span style=3D"color: #000;" class=3D"styled-by-prettify">
=C2=A0 template<typenam= e RealTp<= /span>>
=C2=A0 =C2=A0 class tuple_size;

=C2=A0 // Partial specialization for std::complex.
=C2=A0 template<typenam= e RealTp<= /span>>
=C2=A0 =C2=A0 struct tuple_size<std::complex= <RealTp<= /span>>>= ;
=C2=A0 =C2=A0 : public<= /span> integral_constant<std::size_t<= /span>, 2> { };

=C2=A0 // Declare tuple_element.
=C2=A0 template<std::size_t _Int, typenam= e RealTp<= /span>>
=C2=A0 =C2=A0 class tuple_element;

=C2=A0 // Partial specialization for std::complex.
=C2=A0 template<std::size_t _Int, typenam= e RealTp<= /span>>
=C2=A0 =C2=A0 struct tuple_element<_Int, std::complex= <RealTp<= /span>>>= ;
=C2=A0 =C2=A0 {
=C2=A0 =C2=A0 =C2=A0 static_assert(_Int < 2, "index is out of bounds");
=C2=A0 =C2=A0 =C2=A0 typedef RealTp<= /span> type;
=C2=A0 =C2=A0 };

=C2=A0 // Decompose complex as rvalues.
=C2=A0 template<std::size_t _Int, typenam= e RealTp<= /span>>
=C2=A0 =C2=A0 constexpr const RealTp<= /span>
=C2=A0 =C2=A0 get(const std::complex= <RealTp<= /span>>&am= p; z)
=C2=A0 =C2=A0 {
=C2=A0 =C2=A0 =C2=A0 static_assert(_Int < 2, "index is out of bounds");
=C2=A0 =C2=A0 =C2=A0 return _Int <= /span>=3D=3D<= /span> 0 ? z.real() : z.imag();
=C2=A0 =C2=A0 }

=C2=A0 // Decompose complex as lvalues.
=C2=A0 template<std::size_t _Int, typenam= e RealTp<= /span>>
=C2=A0 =C2=A0 constexpr RealTp<= /span>&
=C2=A0 =C2=A0 get(std::complex= <RealTp<= /span>>&am= p; z)
=C2=A0 =C2=A0 {
=C2=A0 =C2=A0 =C2=A0 static_assert(_Int < 2, "index is out of bounds");
=C2=A0 =C2=A0 =C2=A0 auto w =3D reinter= pret_cast<RealTp<= /span>(&)= [2]>(<= /span>z);
=C2=A0 =C2=A0 =C2=A0 return _Int <= /span>=3D=3D<= /span> 0 ? w[0] : w[1];
=C2=A0 =C2=A0 }


I believed that this reinterpret_cast was UB, but as you note below, it is defined by the standard.


Then we have the following behavior:

template<typenam= e Tp>
=C2=A0 void
=C2=A0 test_complex_decomp()
=C2=A0 {
=C2=A0 =C2=A0 std::complex<Tp> z(1, 2);

=C2=A0 =C2=A0 auto [x, y] =3D z;
=C2=A0 =C2=A0 std::cout <<= ; "z =3D = " <<= ; z <<= ; '\n';
=C2=A0 =C2=A0 std::cout <<= ; "z parts:" << ' ' <<= ; x <<= ; ' ' <<= ; y <<= ; '\n';

I'm not sure if you believe this implies a call to get to decomponse as rvalues, but it isn't.
It just copies the complex to a temporary, and then calls get on this temporary.
=C2=A0 =C2=A0 z.real(3);
=C2=A0 =C2=A0 z.imag(4);
=C2=A0 =C2=A0 std::cout <<= ; "z =3D = " <<= ; z <<= ; '\n';
=C2=A0 =C2=A0 std::cout <<= ; "z parts:" << ' ' <<= ; x <<= ; ' ' <<= ; y <<= ; '\n';

=C2=A0 =C2=A0 std::complex<Tp> w(1, 2);
=C2=A0 =C2=A0 std::cout <<= ; "w =3D = " <<= ; w <<= ; '\n';
=C2=A0 =C2=A0 auto& [p, q] =3D w;

I'm not sure if you believe this implies a call to get to decomponse as lvalues, but it isn't.
It just takes store a reference to the complex in a temporary, and then calls get on this temporary reference.

=C2=A0 =C2=A0 w.real(3);
=C2=A0 =C2=A0 w.imag(4);
=C2=A0 =C2=A0 std::cout <<= ; "w =3D = " <<= ; w <<= ; '\n';
=C2=A0 =C2=A0 std::cout <<= ; "w parts:" << ' ' <<= ; p <<= ; ' ' <<= ; q <<= ; '\n';

=C2=A0 =C2=A0 p =3D -5;
=C2=A0 =C2=A0 q =3D -6;
=C2=A0 =C2=A0 std::cout <<= ; "w =3D = " <<= ; w <<= ; '\n';
=C2=A0 =C2=A0 std::cout <<= ; "w parts:" << ' ' <<= ; p <<= ; ' ' <<= ; q <<= ; '\n';

=C2=A0 =C2=A0 return;
=C2=A0 }

int
main()
{
=C2=A0 test_complex_decomp<double>();
=C2=A0 return 0;
}



-------------------
z =3D (1,2)
z parts: 1 2
z =3D (3,4)
z parts: 1 2
w =3D (1,2)
w =3D (3,4)
w parts: 3 4
w =3D (-5,-6)
w parts: -5 -6
-------------------

The static cast, ugly as it is, is required to be valid by conforming implementations of complex.
Are you talking of the reinterpret_cast?
29.5 Complex numbers [complex.numbers] p4, specifically 4.1-4.3.
This solution elegantly isolates user code from this wart.
I believe that you need const/non const lvalue/rvalue decomposition, but maybe I'm wrong.

=C2=A0 template<std::size_t _Int, typename= RealTp>
=C2=A0 =C2=A0 constexpr const RealTp&&
=C2=A0 =C2=A0 get(const std::complex<RealTp>&& z<= span style=3D"color: #660;" class=3D"styled-by-prettify">)
=C2=A0 =C2=A0 {
=C2=A0 =C2=A0 =C2=A0 static_assert(_Int < 2, "index is out o= f bounds");
=C2=A0 =C2=A0 =C2=A0 return _Int =3D=3D 0 ? z.real() : z.imag();
=C2=A0 =C2=A0 }


=C2=A0 template<= std<= span style=3D"color: #660;" class=3D"styled-by-prettify">::size_t _Int= , typename RealTp>=
=C2=A0 =C2=A0 constexpr RealTp&= &
=C2=A0 =C2=A0 get(std<= span style=3D"color: #660;" class=3D"styled-by-prettify">::complex<= RealTp>&& z)
=C2=A0 =C2=A0 {
=C2=A0 =C2=A0 =C2=A0 static_assert(_Int <= 2, "index is out of bounds");
=C2=A0 =C2=A0 =C2=A0 return _Int =3D=3D 0 ? z.real= () : z.imag= ();<= span style=3D"color: #000;" class=3D"styled-by-prettify">
=C2=A0 =C2=A0 }
=C2=A0 // Decompose complex as lvalues.
=C2=A0 template<std::size_t _Int, typename= RealTp>
=C2=A0 =C2=A0 constexpr RealTp&
=C2=A0 =C2=A0 get(std::complex<RealTp>& z)
=C2=A0 =C2=A0 {
=C2=A0 =C2=A0 =C2=A0 static_assert(_Int < 2, "index is out o= f bounds");
=C2=A0 =C2=A0 =C2=A0 auto w =3D reinterpret_cast<RealTp(&)[= 2]>(z);
=C2=A0 =C2=A0 =C2=A0 return _Int =3D=3D 0 ? w[0] : w[1];
=C2=A0 =C2=A0 }

=C2=A0 // Decompose complex as lvalues.
=C2=A0 template<std::size_t _Int, typename= RealTp>
=C2=A0 =C2=A0 constexpr RealTp const&
=C2=A0 =C2=A0 get(const std::complex<RealTp>& z)
=C2=A0 =C2=A0 {
=C2=A0 =C2=A0 =C2=A0 static_assert(_Int < 2, "index is out o= f bounds");
=C2=A0 =C2=A0 =C2=A0 auto w =3D reinterpret_cast<RealTp const(&)[<= /span>2]>(z);
=C2=A0 =C2=A0 =C2=A0 return _Int =3D=3D 0 ? w[0] : w[1];
=C2=A0 =C2=A0 }

Vicente

--
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/4259d7dc-f060-dc27-5004-37bf4726e456= %40wanadoo.fr.
--------------405F0B4D6009C044D992406E-- .