220 32085 <74a45396-2e35-4231-86b9-4caceb531239@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: 3dw4rd@verizon.net Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Decomposition of std::complex. Date: Thu, 13 Apr 2017 15:11:28 -0700 (PDT) Lines: 698 Approved: news@gmane.org Message-ID: <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/mixed; boundary="----=_Part_1178_2054269446.1492121488413" X-Trace: blaine.gmane.org 1492121489 24303 195.159.176.226 (13 Apr 2017 22:11:29 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 13 Apr 2017 22:11:29 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCS2FYFYXYEBBEPPX7DQKGQESAO76WY@isocpp.org Fri Apr 14 00:11:24 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-io0-f199.google.com ([209.85.223.199]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cymxY-0006BT-8c for gclcip-std-proposals@m.gmane.org; Fri, 14 Apr 2017 00:11:24 +0200 Original-Received: by mail-io0-f199.google.com with SMTP id l21sf59601174ioi.2 for ; Thu, 13 Apr 2017 15:11:30 -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: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=wGNIMWIn75eo7dzUw+lssjdL+9v06fmqKcWCgVc9IKc=; b=WkznPiyHbtw0u0eNIMYMW06Vc1iOaLvDUPTgQypC5lErz9pKQJcVDg+y+ArE9t/X4Y qq5gp8vlcVqyEq7nJA/n4HKppg1XTyp/b/OpposFQyw7kqIosUZuI/5CeFGpcFbAgIfp Kdath4GwRtRcC91JJdHyeKhZQBXHzTy2fygH+/dW1SL+A0KRAGJ9rr56g9tjWBugyXSv OvWE2BI2OwQ1nR8eJLYZuPb+gKOHVJiU7YaL7QMMpjeSlA9s5gat+OIPfhmJze+izyGt ejwAO3Q44KypbsiNCoy6QdsuVGLTbtmKxsD13T+t/mYUzVRYgIdflr1rpoBjjx2BAVSe SELw== 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: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=wGNIMWIn75eo7dzUw+lssjdL+9v06fmqKcWCgVc9IKc=; b=ZBu+AAFc3A6TRQHpelwaVd6Wb5Abze1n9F7mlTj2K0xMn+DyUptSXhIorMY2zAR9Sm DEdU8X+5qNSE814WOJB0Q51Up/2ftA0qV9lt0YucY/3jNq4rOyJW87Gz+yjgcCXcw8JS 0YAfHHPdRPFKAfaxFaOZMrXvqVu5VlwRL1K2XDZ33sNq5hHO1ObcfUhz1ntaqOAg25ly vj8+Rufd30nZP56PkTuE2WAWxedI0Qsh/KN8Q29wf7jkle4ZwYicKXBzf5WemO3/JfVG T35m2pdBSnxXq2l5A3qVBmi9PTDNVp+ahI+beo83tho83Oxj68YYtfeidz5/3VtZQhoh RJDw== X-Gm-Message-State: AN3rC/4sUAtxBeYTwkrHuEvybtpyByXRgVi4J4HfnaeWoQgO4uvFnEMm z8No3VPevhYrMg== X-Received: by 10.36.16.82 with SMTP id 79mr9967394ity.18.1492121489936; Thu, 13 Apr 2017 15:11:29 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.14.36 with SMTP id c33ls3275670otc.28.gmail; Thu, 13 Apr 2017 15:11:29 -0700 (PDT) X-Received: by 10.157.23.39 with SMTP id i39mr66700ota.8.1492121488878; Thu, 13 Apr 2017 15:11:28 -0700 (PDT) X-Original-Sender: 3dw4rd@verizon.net 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:32085 Archived-At: ------=_Part_1178_2054269446.1492121488413 Content-Type: multipart/alternative; boundary="----=_Part_1179_908813261.1492121488415" ------=_Part_1179_908813261.1492121488415 Content-Type: text/plain; charset=UTF-8 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. The rvalue and lvalue decomposition of std::complex can be 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 class tuple_size; // Partial specialization for std::complex. template struct tuple_size> : public integral_constant { }; // Declare tuple_element. template class tuple_element; // Partial specialization for std::complex. template struct tuple_element<_Int, std::complex> { static_assert(_Int < 2, "index is out of bounds"); typedef RealTp type; }; // Decompose complex as rvalues. template constexpr const RealTp get(const std::complex& z) { static_assert(_Int < 2, "index is out of bounds"); return _Int == 0 ? z.real() : z.imag(); } // Decompose complex as lvalues. template constexpr RealTp& get(std::complex& z) { static_assert(_Int < 2, "index is out of bounds"); auto w = reinterpret_cast(z); return _Int == 0 ? w[0] : w[1]; } Then we have the following behavior: template void test_complex_decomp() { std::complex z(1, 2); auto [x, y] = z; std::cout << "z = " << z << '\n'; std::cout << "z parts:" << ' ' << x << ' ' << y << '\n'; z.real(3); z.imag(4); std::cout << "z = " << z << '\n'; std::cout << "z parts:" << ' ' << x << ' ' << y << '\n'; std::complex w(1, 2); std::cout << "w = " << w << '\n'; auto& [p, q] = w; w.real(3); w.imag(4); std::cout << "w = " << w << '\n'; std::cout << "w parts:" << ' ' << p << ' ' << q << '\n'; p = -5; q = -6; std::cout << "w = " << w << '\n'; std::cout << "w parts:" << ' ' << p << ' ' << q << '\n'; return; } int main() { test_complex_decomp(); return 0; } ------------------- z = (1,2) z parts: 1 2 z = (3,4) z parts: 1 2 w = (1,2) w = (3,4) w parts: 3 4 w = (-5,-6) w parts: -5 -6 ------------------- The static cast, ugly as it is, is required to be valid by conforming implementations of complex. 29.5 Complex numbers [complex.numbers] p4, specifically 4.1-4.3. This solution elegantly isolates user code from this wart. -- 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/74a45396-2e35-4231-86b9-4caceb531239%40isocpp.org. ------=_Part_1179_908813261.1492121488415 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
In many uses of std::complex
one wants to capture the = real and imaginary parts in separate variables either to use them in subseq= uent 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 declar= ation for a complex number is an error because of the pretension (ostensibl= y for C compatibility) the complex numbers are opaque.

The rvalue an= d lvalue decomposition of std::complex can be accomplished with a simple pu= re-library extension:
Provide a tuple interface to std::complex.

=
=C2=A0 <= /span>// Tuple in= terface to class template complex.
#define __cxx_lib_tuple_complex 201705

=C2=A0 // Declare tuple_size.
=C2=A0 template<typename RealTp>
=C2=A0 =C2=A0 class tuple_size;

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

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

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

=C2=A0 = // Decompose comp= lex as rvalues.
=C2=A0 template<st= d::= size_t _Int, typename RealTp>
=C2=A0 =C2=A0 constexpr const RealTp=
=C2=A0 =C2=A0 get(const std::complex<RealTp>& z)
=C2=A0 =C2=A0 {
=C2=A0 =C2=A0 =C2=A0 static_assert(_Int < 2= , <= span style=3D"color: #080;" class=3D"styled-by-prettify">"index is out= of bounds");=C2=A0 =C2=A0 =C2=A0 return _Int =3D=3D 0= ? z.real() : z.imag();
=C2=A0 =C2=A0 }

=C2=A0 // Decompose complex as lvalues.=
=C2=A0= template<= /span><= std::size_t _Int, typename RealTp>
=C2=A0 =C2=A0 constexpr RealTp&= amp;
= =C2=A0 =C2=A0 get(std::complex<RealTp>& z)
=C2=A0 =C2=A0 {
=C2=A0 =C2=A0 =C2=A0 static_assert(_Int < 2= , <= span style=3D"color: #080;" class=3D"styled-by-prettify">"index is out= of 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<= /span>];
=C2=A0 =C2=A0 <= /span>}



Then we have the following behavior:

= template<typename 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';

=C2=A0 =C2=A0 z.real(3);
=C2=A0 =C2=A0 z.imag(4);
=C2=A0 =C2=A0 st= d::= cout << "z =3D " << z << '\n';
=C2=A0 =C2=A0 std::cout << "z parts:" << ' &#= 39; <<<= span style=3D"color: #000;" class=3D"styled-by-prettify"> x << ' ' << y << '\n';

=C2=A0 =C2=A0 std::complex<Tp&= gt; w(1, 2);
=C2=A0 =C2=A0 std::cout << "= w =3D " <<= ; w <<<= span style=3D"color: #000;" class=3D"styled-by-prettify"> '\n';
=C2=A0 =C2=A0 auto& [p, q] =3D w;

=C2=A0 =C2=A0 w.real(3);<= br>=C2=A0 =C2=A0 w.i= mag(4);
=C2=A0 =C2=A0 std::cout << "w =3D " << w << '\n';
=C2=A0 =C2=A0 std::cout << = "w pa= rts:"= <<<= /span> ' ' << 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 <<<= span style=3D"color: #000;" class=3D"styled-by-prettify"> '\n';
=C2=A0 =C2=A0 std::cout << "w parts:" << ' ' << p << = ' '= ; <= span style=3D"color: #660;" class=3D"styled-by-prettify"><< q << '\n';

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

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

<= br>
-------------------
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.29.5 Complex numbers [complex.numbers] p4, specifically 4.1-4.3.
This s= olution elegantly isolates user code from this wart.

--
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/74a45396-2e35-4231-86b9-4caceb531239= %40isocpp.org.
------=_Part_1179_908813261.1492121488415-- ------=_Part_1178_2054269446.1492121488413-- .