220 32542 <5d084b24-5fd4-4a81-968f-aa8561b19e09@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: ma.kalbfuss@web.de Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: relaxing rules for ternary operator. Allow incompatible types. Date: Sun, 21 May 2017 02:15:21 -0700 (PDT) Lines: 499 Approved: news@gmane.org Message-ID: <5d084b24-5fd4-4a81-968f-aa8561b19e09@isocpp.org> References: <1b5ee8eb-53df-4e98-af2f-829c7bc2e5b2@isocpp.org> <9064929.QEV8q21eIZ@tjmaciei-mobl1> <99350a9e-0c6b-468d-9761-f2b2b052275e@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_2087_1113621356.1495358121806" X-Trace: blaine.gmane.org 1495358124 16622 195.159.176.226 (21 May 2017 09:15:24 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 21 May 2017 09:15:24 +0000 (UTC) Cc: ma.kalbfuss@web.de To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBC7YTI72XQOBBKVVQXEQKGQERHCYKUA@isocpp.org Sun May 21 11:15:19 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-it0-f70.google.com ([209.85.214.70]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dCMxJ-0004Ar-Rk for gclcip-std-proposals@m.gmane.org; Sun, 21 May 2017 11:15:18 +0200 Original-Received: by mail-it0-f70.google.com with SMTP id s131sf74067498itd.6 for ; Sun, 21 May 2017 02:15:23 -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:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=k4f8w6hau4zksiqgTa9OTrfslgGCu3B2WU10AIXh+iM=; b=QPoMtczqU4ZdvpnKq5awgq6lztG6CBDOSWotfhh1dI7CD2LNAi6NQECrnb1Ko/6oHM oVBpOwr7YsEFCiIUQ/BLTGv+7uR9bXZdb5GCwMxlmH0h6wOMhgZj/X9t2UxWWuLIjbeq 9TnGXFgWMMCN6I6iC/dbT6AaDjaDq0ZY/oicHKtom3GzhdixZ0Eg49/gfCYtBVvlqSpa ctkw5WZjMfPG0Jz4t997QsZnR0XO6nI5FGn7qVY7E2SSwvn8WwRW9EtkvnjQ+BxZ0bgz YrCLm51cUcrVRoplnjshlSW4YqytGixopgMwHk6dpwRcw5yyVie9O6tKmNGOWqLVWSXI Y+MQ== 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=k4f8w6hau4zksiqgTa9OTrfslgGCu3B2WU10AIXh+iM=; b=BIJA3e7sKIKs6YjuP1oEgkbYqGS0wBzZMv9U/lS040/Ay+5e3QR27R44k4vsEFnqNk CGO8+7gzhkNe3eQm9nmotOayZUmbRC/1l0j461gBmg8SbumMuwe6D8flc5ShiY3YhQdA XQd755947uO0xE9GcyC7Uhw72KxIBm5sw0l+1AH5HN1Lrafb6nT0qCazQo3XFU+IkCp+ h4k/oStWr4N/9N3hTVOamQqKoSuz9xRTamId1E4ikKp4kHx+PCU4GvVJgB2JLxWkPHSJ QalJYoyVeO3wDVtfk3fbFjYJSpwe8KrMwbWSMUYvrldke/IpyXo3DBgMLNgj3j2UEcjk +SFw== X-Gm-Message-State: AODbwcDmLJgrcRBFRt1YxroH5ezgebY3lMxh7hOs99OC3yJ9yi5/c8pe 60aOsXheh1xh0c/3 X-Received: by 10.36.105.21 with SMTP id e21mr6883549itc.19.1495358123196; Sun, 21 May 2017 02:15:23 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.11.145 with SMTP id 17ls1988681oth.36.gmail; Sun, 21 May 2017 02:15:22 -0700 (PDT) X-Received: by 10.157.45.79 with SMTP id v73mr371504ota.20.1495358122341; Sun, 21 May 2017 02:15:22 -0700 (PDT) In-Reply-To: <99350a9e-0c6b-468d-9761-f2b2b052275e@isocpp.org> X-Original-Sender: ma.kalbfuss@web.de 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:32542 Archived-At: ------=_Part_2087_1113621356.1495358121806 Content-Type: multipart/alternative; boundary="----=_Part_2088_1911461960.1495358121807" ------=_Part_2088_1911461960.1495358121807 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The coresponding assembly code without iostream to avoid unecessary=20 complexity: A::doit(): push rbp mov rbp, rsp mov QWORD PTR [rbp-8], rdi nop pop rbp ret B::doit(): push rbp mov rbp, rsp mov QWORD PTR [rbp-8], rdi nop pop rbp ret main: push rbp mov rbp, rsp sub rsp, 16 mov BYTE PTR [rbp-1], 1 cmp BYTE PTR [rbp-1], 0 je .L9 nop lea rax, [rbp-2] mov rdi, rax call A::doit() mov eax, 0 jmp .L8 ..L9: nop lea rax, [rbp-3] mov rdi, rax call B::doit() mov eax, 0 ..L8: leave ret Am Sonntag, 21. Mai 2017 11:03:45 UTC+2 schrieb ma.ka...@web.de: > > I revisited your statement, that this isn't possible, because the type=20 > would be determined at runtime. I have to disagree, now. It is possible = at=20 > compile time. > > Look at the following code: > > auto x =3D runtime_condition ? A{} : B{}; > x.doit(); > > This is not going to work, as you stated. But you could write the=20 > following instead: > > auto f =3D [&](auto x) { x.doit(); }; > runtime_condition ? f(A{}) : f(B{}); > > The code, following the ternary statement is moved into a generic lambda. > auto x =3D runtime_condition ? A{} : B{}; > > The generic lambda is instantiated two times, for each branch. Depending= =20 > on runtime_condition, > only one instance is executed. The statement > > auto x =3D runtime_condition ? A{} : X{}; > > could introduce the following code inside the current scope twice, like= =20 > the generic lambda did. Ones for each type. > Depending on the runtime_condition, the code pointer is moved to the firs= t=20 > or the second instantiaton with a jump. > > The following C++ code snippet describes roughly how the generated code= =20 > could look like. > > #include > > struct A{ void doit(){ std::cout << "A::doit" << std::endl; } }; > struct B{ void doit(){ std::cout << "B::doit" << std::endl; } }; > > int main() > { > auto runtime_condition =3D true; > > if(runtime_condition) > goto ternary_branch_1; > else > goto ternary_branch_2; > > ternary_branch_1: > A __instance1__; > __instance1__.doit(); > return 0; > ternary_branch_2: > B __instance2__; > __instance2__.doit(); > return 0; > } > > > > > > > > Am Samstag, 20. Mai 2017 21:29:56 UTC+2 schrieb Thiago Macieira: >> >> On s=C3=A1bado, 20 de maio de 2017 10:41:56 PDT ma.ka...@web.de wrote:= =20 >> > Hi Guys,=20 >> >=20 >> > I had the following situation:=20 >> >=20 >> > I have a Group of StaticSet classes with a compatible interface but=20 >> > distinct in there concrete type. empty_set is not an intervall!=20 >> > I tried the following:=20 >> >=20 >> >=20 >> > auto dec_digit =3D make_interval('0', '0' + std::min(base, DECIMAL_BAS= E)=20 >> - 1);=20 >> > auto upper_digit =3D (base > DECIMAL_DIGIT) ? make_interval('A', 'A' += =20 >> (base=20 >> > - 1 - DECIMAL_BASE)) : empty_set;=20 >> > auto lower_digit =3D (base > DECIMAL_DIGIT) ? make_interval('a', 'a' += =20 >> (base=20 >> > - 1 - DECIMAL_BASE)) : empty_set;=20 >> >=20 >> >=20 >> > Wouldn't it be possible to allow such code, especially in conjunction= =20 >> with=20 >> > concepts?=20 >> >> No. lower_digit must have exactly one type, determined at compile-time.= =20 >> What=20 >> you're asking for would cause the type to be determined at runtime, whic= h=20 >> is=20 >> not possible in C++.=20 >> >> Alternatives:=20 >> * convert empty_set to make_interval's type=20 >> * convert either to a common type (which you need to be explicit about,= =20 >> so it=20 >> won't work with auto)=20 >> * use std::variant=20 >> >> --=20 >> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org=20 >> Software Architect - Intel Open Source Technology Center=20 >> >> --=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/5d084b24-5fd4-4a81-968f-aa8561b19e09%40isocpp.or= g. ------=_Part_2088_1911461960.1495358121807 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The coresponding assembly code without iostream to avoid u= necessary complexity:

A::doit()= :
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 push =C2=A0 =C2=A0rbp
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 mov =C2=A0 =C2=A0 rbp, rsp
=C2=A0 =C2=A0 =C2=A0 =C2=A0 mov =C2=A0 =C2=A0 QWORD PTR [rbp-8], rdi
=C2=A0 =C2=A0 =C2=A0 =C2=A0 nop
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 pop =C2=A0 =C2=A0 rbp
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ret
B= ::<= span style=3D"color: #000;" class=3D"styled-by-prettify">doit():
=C2=A0 =C2=A0 =C2=A0 =C2=A0= push =C2=A0 =C2=A0rbp
=C2=A0 =C2=A0 =C2=A0 =C2=A0 mov =C2=A0 =C2=A0 rbp= , rsp
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 mov =C2=A0 =C2=A0 QWORD PTR [rbp-8], rdi=C2=A0 =C2=A0 =C2=A0 =C2=A0 nop
=C2=A0 =C2=A0 =C2=A0 =C2=A0 pop =C2=A0= =C2=A0 rbp
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ret
main:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 push =C2= =A0 =C2=A0rbp
=C2=A0 =C2=A0 =C2=A0 =C2=A0 mov =C2=A0 =C2=A0 rbp, rsp
=C2=A0 =C2=A0 =C2=A0= =C2=A0 su= b =C2=A0 = =C2=A0 rsp= , <= span style=3D"color: #066;" class=3D"styled-by-prettify">16
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 mov =C2=A0 =C2=A0 BYTE PTR [rbp-1= ],<= span style=3D"color: #000;" class=3D"styled-by-prettify"> 1
=C2=A0 =C2=A0 =C2=A0 =C2=A0 cmp = =C2=A0 =C2=A0 BYTE PTR [rbp-1], 0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 je =C2=A0 =C2= =A0 =C2=A0= ..L9
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 nop
=C2=A0 =C2=A0 =C2=A0 =C2=A0 lea =C2=A0 =C2= =A0 rax, [rbp-2]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 mov =C2=A0 =C2=A0 rdi= , rax
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 call =C2=A0 =C2=A0A::doit()=C2=A0 =C2=A0 =C2=A0 =C2=A0 mov =C2=A0 =C2=A0 eax, 0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 jmp =C2=A0 =C2=A0 .L8
.L9:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 nop
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 lea =C2=A0 =C2=A0 rax, [rbp= -3]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 mov = =C2=A0 =C2=A0 rdi, r= ax
=C2=A0 =C2=A0 =C2=A0 =C2=A0 call =C2=A0 =C2=A0B::doit()
=C2=A0 =C2=A0 =C2=A0 =C2=A0 mov =C2=A0 =C2=A0 eax<= /span>, 0
.L8:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 leave
=C2=A0 =C2=A0 =C2=A0 =C2=A0= ret





Am Sonntag, 21. Mai 2017 = 11:03:45 UTC+2 schrieb ma.ka...@web.de:
I revisited your statement, that this isn't p= ossible, because the type would be determined at runtime. I have to disagre= e, now.=C2=A0 It is possible at compile time.

Look at the following = code:

auto x =3D runtime_condition ? A= {} : B{};
x.doit();

This is not going to work, as you stated. But you could write= the following instead:

auto f = =3D [&](au= to x) {= x.doit(); };
runtime_condition = ? f(A{}) : f(B{});

The code, following the = ternary statement is moved into a generic lambda.
auto x =3D runtime_condition ? A{}= : B{};=

The generic lambda is instantiated two times, for each branch.= Depending on runtime_condition,
only one instance is executed. The stat= ement

auto x =3D runtime_condition ? A{} : X{};

could introduce the = following code inside the current scope twice, like the generic lambda did.= Ones for each type.
Depending on the runtime_condition, the code pointe= r is moved to the first or the second instantiaton with a jump.

The following C++ code snippet describes roughly how the generate= d code could look like.

#include <iostream>

struct A{ void doit(){ std::cout << "A::doit"= ; <&= lt; std= ::endl;= } };
struct B{ void doit(){ std::cout << "B::doi= t" << std::endl; = } };

in= t main(= )
{<= /span>
=C2=A0 =C2=A0 auto runtime_condition <= span style=3D"color:#660">=3D true;

=C2=A0 =C2=A0 if(ru= ntime_condition)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = goto ternary_branch_1;
=C2=A0 =C2=A0 else
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 goto ternary_branch_2;<= /span>

ternary_branch_1:
=C2=A0 =C2=A0 A __in= stance1__;
=C2=A0 =C2=A0 __instance1__.doit();
=C2=A0 =C2=A0 return 0;=
ternary_branch_2:
=C2=A0 =C2=A0 B __instance2__;
=C2=A0 =C2=A0 __instance2__<= /span>.doit();
=C2= =A0 =C2=A0 return 0;
}







Am Samstag, 20. M= ai 2017 21:29:56 UTC+2 schrieb Thiago Macieira:
On s=C3=A1bado, 20 de maio de 2017 10:41:56 PDT ma.ka...@web.de wrote:
> Hi Guys,
>=20
> I had the following situation:
>=20
> I have a Group of StaticSet classes with a compatible interface bu= t
> distinct in there concrete type. empty_set is not an intervall!
> I tried the following:
>=20
>=20
> auto dec_digit =3D make_interval('0', '0' + std::m= in(base, DECIMAL_BASE) - 1);
> auto upper_digit =3D (base > DECIMAL_DIGIT) ? make_interval(= 9;A', 'A' + (base
> - 1 - DECIMAL_BASE)) : empty_set;
> auto lower_digit =3D (base > DECIMAL_DIGIT) ? make_interval(= 9;a', 'a' + (base
> - 1 - DECIMAL_BASE)) : empty_set;
>=20
>=20
> Wouldn't it be possible to allow such code, especially in conj= unction with
> concepts?

No. lower_digit must have exactly one type, determined at compile-time.= What=20
you're asking for would cause the type to be determined at runtime,= which is=20
not possible in C++.

Alternatives:
* convert empty_set to make_interval's type
* convert either to a common type (which you need to be explicit about,= so it=20
=C2=A0 =C2=A0won't work with auto)
* use std::variant<interval, decltype(empty_set)>

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center

--
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/5d084b24-5fd4-4a81-968f-aa8561b19e09= %40isocpp.org.
------=_Part_2088_1911461960.1495358121807-- ------=_Part_2087_1113621356.1495358121806-- .