220 32608 <423c4520-1f50-4761-8d02-edfbaaf94827@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: constexpr ternary (was: Re: relaxing rules for ternary operator. Allow incompatible types.) Date: Tue, 23 May 2017 11:20:17 -0700 (PDT) Lines: 221 Approved: news@gmane.org Message-ID: <423c4520-1f50-4761-8d02-edfbaaf94827@isocpp.org> References: <1b5ee8eb-53df-4e98-af2f-829c7bc2e5b2@isocpp.org> <85b404a7-bc13-4737-b71d-c5afc6b4157b@isocpp.org> <3491692.i123ijHHWq@tjmaciei-mobl1> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_3573_203431118.1495563617295" X-Trace: blaine.gmane.org 1495563619 28597 195.159.176.226 (23 May 2017 18:20:19 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 23 May 2017 18:20:19 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBC7YTI72XQOBBYP2SHEQKGQES2YEWAQ@isocpp.org Tue May 23 20:20:15 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-yw0-f199.google.com ([209.85.161.199]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dDEPl-0007Gj-NU for gclcip-std-proposals@m.gmane.org; Tue, 23 May 2017 20:20:13 +0200 Original-Received: by mail-yw0-f199.google.com with SMTP id f204sf96071644ywc.15 for ; Tue, 23 May 2017 11:20:19 -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 :x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=YJZqfJlV/vJeFApvj9/0bmDnS/fbiaa2bGDpkQzklTI=; b=cTcyoE7tdGpaf0yvcS3vjpIhngbBpvjNxp+VmvesByUFFOQQ2a0bWsY9jjsZyH4uwF LLlmv89JsxXs7C5vHiqYKt9dUPFZ36ZSx40j236JZ2jli8r80X5I2e/z+90J913hCjMV F8cvZNdUOTru4SsSxYVyRws9AyxpptGQkLj7lmvp8U+L1HU02m2yRyz99jCEjnQ9VNLo QYrL/6a72ZgUl+fD3shumPYhFQvvANNP8SIvU0K9sICTAs8GzplLib7bVQyjmGTJJKy4 iHmCIfMPIRf7INY11Blsx+FOZR5bmRNeAiXA6wSd+KmWbfds78MlOiIl0OyjrI7Kgvkk q4SA== 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=YJZqfJlV/vJeFApvj9/0bmDnS/fbiaa2bGDpkQzklTI=; b=SsDw5pY5WCcKnnYaKJ52M6HoS7vUsuC0c9OooC4HSddmv7SAlE2/1CY5D1SdM/poGw seA2wHgcIfHbUAuuhKHL++woyYPvq3QoEPjjxJrbn9lfUgrAqG8Ve7XGiS1Di85KWzP9 2g9ZVMlvCRQIOqMSYmZI8rpf8aVUkUoLx0zAgT1t9EBD60+yxwI74V6yVtOprwBViNzt pcPTc1jArYHJz2umqzMVdRwazy3FdtsIcp4STgZFIuxxDteuIAWpXfPPz1+7vJ96VlJX SdFnm1M5KTDouj/MEamwrQtqATohUSpxbQmQ0EGoHCtsL3Ee+/HYB2RGGBWI8+bxQpQ9 zpDQ== X-Gm-Message-State: AODbwcBTAXlqZvpNhA3AoNFY//sQ1XFBqN4xvvjTAJxg80f3lHI03CaO 4VlEIS1B0cfKCqp0 X-Received: by 10.129.168.4 with SMTP id f4mr8561650ywh.169.1495563618650; Tue, 23 May 2017 11:20:18 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.17.206 with SMTP id y14ls6336641oty.43.gmail; Tue, 23 May 2017 11:20:17 -0700 (PDT) X-Received: by 10.157.17.23 with SMTP id g23mr116334ote.4.1495563617781; Tue, 23 May 2017 11:20:17 -0700 (PDT) In-Reply-To: <3491692.i123ijHHWq@tjmaciei-mobl1> 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:32608 Archived-At: ------=_Part_3573_203431118.1495563617295 Content-Type: multipart/alternative; boundary="----=_Part_3574_123225151.1495563617295" ------=_Part_3574_123225151.1495563617295 Content-Type: text/plain; charset="UTF-8" Sorry. This was misleading. I know that we cannot avoid the exponential growth. My point is, that there is no accidental exponential growth, because the programmer has to explicitly denote the usage with the [[generic]] attribute. Am Dienstag, 23. Mai 2017 16:47:49 UTC+2 schrieb Thiago Macieira: > > On Tuesday, 23 May 2017 01:07:52 PDT ma.kalbfuss via ISO C++ Standard - > Future > Proposals wrote: > > The hiding of type errors and unwanted exponential growth of the code > size > > could be avoided by using an attribute or a different operator symbol. > > Please ignore the attribute name and the choosen symbol for now. They > are > > only placeholers. > > > > auto x = runtime_condition [[generic]] ? A{} : B{}; > > > > or > > > > auto x = runtime_condition ?? A{} : B{}; > > > > This way, the programmer has to tell the compiler that he want to use > the > > generic version. No unexpected exponential growth and no hidden type > > errors. Maybe this is too much for the upcomming standard. There is no > room > > for such an extension. The list of must have features is already too > long. > > There is not much room left besides Concepts and Modules, anyway. So > this > > will be a proposal for a later standard. I think there are more cases, > > whrere this technique could be applied. These cases are not explored > yet. > > You're missing the point that the code growth is not optional. > > It doesn't matter how you mark this new syntax, the fact that we have a > variable whose type cannot be determined at compile time means that > there's > runtime overhead. > > With proper reflection, the generic type on the left side can be entirely > impemented in library code, with no compiler magic, with dispatcher > functions > to A and B depending on the stored type. For example, it would generate: > > template > struct Generic > { > typeinfo *ti; > void *target; > > Generic(A *object) : ti(typeinfo(A)), target(object) {} > Generic(B *object) : ti(typeinfo(B)), target(object) {} > > int f() > { > return ti == typeinfo(A) ? > static_cast(target)->f() : > static_cast(target)->f(); > } > }; > > Then if you have Generic x, whenever you do: > x.f(); > > then the correct function is called. > > But there was an overhead, since every call now checks the typeinfo. This > avoids the exponential growth of code, but it does increase the code > nonetheless and introduces a runtime overhead. > > -- > Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org > Software Architect - Intel Open Source Technology Center > > -- 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/423c4520-1f50-4761-8d02-edfbaaf94827%40isocpp.org. ------=_Part_3574_123225151.1495563617295 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sorry. This was misleading. I know that we cannot avoid th= e exponential growth. My point is, that there is no accidental exponential = growth, because the programmer has to explicitly denote the usage with the = [[generic]] attribute.

Am Dienstag, 23. Mai 2017 16:47:49 UTC+2 schr= ieb Thiago Macieira:
On Tuesday= , 23 May 2017 01:07:52 PDT ma.kalbfuss via ISO C++ Standard - Future=20
Proposals wrote:
> The hiding of type errors and unwanted exponential growth of the c= ode size
> could be avoided by using an attribute or a different operator sym= bol.
> Please ignore the attribute name and the choosen symbol for now. T= hey are
> only placeholers.
>=20
> auto x =3D runtime_condition [[generic]] ? A{} : B{};
>=20
> or
>=20
> auto x =3D runtime_condition ?? A{} : B{};
>=20
> This way, the programmer has to tell the compiler that he want to = use the
> generic version. No unexpected exponential growth and no hidden ty= pe
> errors. Maybe this is too much for the upcomming standard. There i= s no room
> for such an extension. The list of must have features is already t= oo long.
> There is not much =C2=A0room left besides Concepts and Modules, an= yway. So this
> will be a proposal for a later standard. I think there are more ca= ses,
> whrere this technique could be applied. These cases are not explor= ed yet.

You're missing the point that the code growth is not optional.

It doesn't matter how you mark this new syntax, the fact that we ha= ve a=20
variable whose type cannot be determined at compile time means that the= re's=20
runtime overhead.

With proper reflection, the generic type on the left side can be entire= ly=20
impemented in library code, with no compiler magic, with dispatcher fun= ctions=20
to A and B depending on the stored type. For example, it would generate= :

template <typename A, typename B>
struct Generic
{
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0typeinfo *ti;
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0void *target;

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Generic(A *object) : ti= (typeinfo(A)), target(object) {}
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Generic(B *object) : ti= (typeinfo(B)), target(object) {}

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0int f()
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0{
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0return ti =3D=3D typeinfo(A) ?=20
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= static_cast<A *>(target)->f() :
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= static_cast<B *>(target)->f();
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0}
};

Then if you have Generic<A, B> x, whenever you do:
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0x.f();

then the correct function is called.

But there was an overhead, since every call now checks the typeinfo. Th= is=20
avoids the exponential growth of code, but it does increase the code=20
nonetheless and introduces a runtime overhead.

--=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/423c4520-1f50-4761-8d02-edfbaaf94827= %40isocpp.org.
------=_Part_3574_123225151.1495563617295-- ------=_Part_3573_203431118.1495563617295-- .