220 35340 <2941cf7e-74cf-4a52-b3df-b0c90192bca2@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Joe Loser Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Metaclasses, code injection, and compilation limits. Date: Sat, 11 Nov 2017 18:02:55 -0800 (PST) Lines: 151 Approved: news@gmane.org Message-ID: <2941cf7e-74cf-4a52-b3df-b0c90192bca2@isocpp.org> References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_3425_793406109.1510452176057" X-Trace: blaine.gmane.org 1510452178 26981 195.159.176.226 (12 Nov 2017 02:02:58 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 12 Nov 2017 02:02:58 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCN4TIPJ7IBBBUOXT3IAKGQEVHNCA5Q@isocpp.org Sun Nov 12 03:02:53 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ua0-f198.google.com ([209.85.217.198]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eDhbn-0006hM-AB for gclcip-std-proposals@m.gmane.org; Sun, 12 Nov 2017 03:02:51 +0100 Original-Received: by mail-ua0-f198.google.com with SMTP id 108sf3559554uaf.1 for ; Sat, 11 Nov 2017 18:02:58 -0800 (PST) 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 :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=U2zHvZow6Xedw1HGZeOcbp42Iue2iBiIY4sjvM65wD8=; b=T3iQe2kiq+xh796L48CbxQUcIMRxrI3lG59DcmORyKHVeaFkgwV2kAHV7fPBZKztwR DUJ4nLCQrPF1RMWPIejJYUjSTR93OwvmHexA5gLo1/kxx25yggbezXk9oQae+P3BpYxf OKqWGShhOi314Cq7k25S5tPUZE/NPkaFchryz0hdjcL1PKKjoCdwvdDXjoElpW5fJUmJ Qr2k48SINTO2nrRLetYHiobmYS/pEfGvQT6uwkROkQa80qUuonF/MUE4hVbAzEaDhVIQ nKu0/rD3ebBT5gJd7OGUIN45bj1zM2q+hAuHVJAe/X8gy9Q/SIWbKi0Z3/nahiDGWq0/ PBVw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:message-id:in-reply-to:references:subject:mime-version :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=U2zHvZow6Xedw1HGZeOcbp42Iue2iBiIY4sjvM65wD8=; b=pz30UUY0PaHFgn4B57usKK7anrqjDj+ta9nvy3SYdqH7oKwAt4iiJWwOQvTISTxqcb biXgT/iDNgyH4wDSCfiYh+YHoNI/wgEBOI4zJBQveq88oIM6Mc7W+QUpZHlwdnAQms3A i+iDYsy9x3l5YIyYdyNgfKo7lJ2Es8imb87XHLMgTu+N2nR5t+NPvWE/882FfmhgO0yR ruxlWOO/tGUcm3s/E/mfXOSQF2qijVtBZf9KV36Zg49YfsdA1qsjJ4JMP4F1ZUNhYiEy VnKHZtQXchPQpI1NI3ir6SHCxai2ALfLxahy0GTIT1lhLdND1sRgKnJEeiblvIkv0VeE LYLQ== 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=U2zHvZow6Xedw1HGZeOcbp42Iue2iBiIY4sjvM65wD8=; b=Z7rc3hFY2skxlMB7cgJIGYZKm7i3S/yWmbLkeq3sKcWiqnF86s92hZ7d904fDSyg8T CeXTx7zLyeIVBFt57zVlxeSaj7VMmQ14iwb3f8GtQE0/+FFEezKAvSRYYMTiKxUjWhcD q5MHtUWh1fgjqh9AoDkb5h2773euQkQZRie27tfBvAupw3zhc43838X8SsWbCaLi8WS5 XchA4Z2SFDt5/WKkrWFFM61g30UotJMVnXYjMTgcrhS6b/qIM+MXfvH3Mh7KGJdURJYA 36SXgxDtXSd300l9ORqWNsMA2FUnrH72XQPcBqCkrRvu7ZjkY0uO7Eu1nl2zPYQQoZm/ XXBA== X-Gm-Message-State: AJaThX6kel7KJGOjLx4ibWCiWoERQABAuRChdxRyn7K2nn5JQdw10FAF S/hxzZLqVG69qpLtuWjVcW8f6Q== X-Google-Smtp-Source: ABhQp+Svfg5tVjBppaU0gPVE+A5mPQ8f3gKvnkWWEF9/i0qsGJbuRI28RFyL+cQUsH5NHocHze4IBQ== X-Received: by 10.176.7.214 with SMTP id d22mr7205914uaf.78.1510452178387; Sat, 11 Nov 2017 18:02:58 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.159.54.115 with SMTP id s48ls8360050uad.0.gmail; Sat, 11 Nov 2017 18:02:57 -0800 (PST) X-Received: by 10.31.48.78 with SMTP id w75mr622275vkw.12.1510452176655; Sat, 11 Nov 2017 18:02:56 -0800 (PST) In-Reply-To: X-Original-Sender: joeloser93@gmail.com 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:35340 Archived-At: ------=_Part_3425_793406109.1510452176057 Content-Type: multipart/alternative; boundary="----=_Part_3426_700537112.1510452176058" ------=_Part_3426_700537112.1510452176058 Content-Type: text/plain; charset="UTF-8" I like the idea of being able to query limitations at compile-time, especially as compile-time costs keep going up with certain features. On Friday, November 10, 2017 at 10:43:29 PM UTC-5, Nicol Bolas wrote: > > Code injection reflection and metaclasses has good potential for creating > reusable packets of code for us. However, there are certain possibilities > that concern me about the efficiency, or even the possibility, of making > such code. > > One idea that was floated for a proposal is a simple function that > determines if an enumeration object contains one of its enumerators. This > has many uses, including allowing a value-safe cast from a raw integer to > an enum. > > Reflection with code injection can certainly implement such a function. My > concern is exactly *how* it gets implemented. > > Let's say you implement it with metacode that looks something like this: > > if((test == ) || ... || false) > return true; > return false; > > `` in this example is something that acts like a parameter > pack, which contains all of the enumerators in the enum. Ignore the actual > syntax here. The point is that you're testing all of the enumerators in one > full expression. > > Some enumerations are big. *Really* big. Like thousands of them. And > compilers have limitations as to how big of an expression they can actually > evaluate. The standard only requires 256 parenthesized expressions, while > we can have 4096 enumerators in an enumeration. That's a pretty wide > disparity. > > Now obviously there's more than one way to skin a cat. You can implement > this tester in a number of different ways. You can even implement it in > different ways based on the number of enumerators. > > The thing that seems clear to me is that a good implementation of this > meta-function would rely on aspects of the compiler that cannot be > determined. And I don't relish the idea of having a metafunction do a > compile-time sort on an thousand-entry enumeration in order to determine > ranges to do comparisons with. Granted, this is all cutting edge stuff, so > maybe it compiles to efficient code. > > I guess my overall point is that, as these features start nearing the > standard, it would be good to take a look at how compile-time limitations > start impacting implementations of code injection. And most importantly, if > there are some low-hanging fruit features that can better be implemented by > the standard library (behind which may be compiler intrinsic) than by user > metafunctions. > > We may even want to give users the ability to query some compile-time > limitations. If they're going to have to live within them, having a > constexpr query for them would probably be a good idea. > > -- 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/2941cf7e-74cf-4a52-b3df-b0c90192bca2%40isocpp.org. ------=_Part_3426_700537112.1510452176058 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I like the idea of being able to query limitations at comp= ile-time, especially as compile-time costs keep going up with certain featu= res.=C2=A0

On Friday, November 10, 2017 at 10:43:29 PM UTC-5, Nicol = Bolas wrote:
C= ode injection reflection and metaclasses has good potential for creating re= usable packets of code for us. However, there are certain possibilities tha= t concern me about the efficiency, or even the possibility, of making such = code.

One idea that was floated for a proposal is a simple function = that determines if an enumeration object contains one of its enumerators. T= his has many uses, including allowing a value-safe cast from a raw integer = to an enum.

Reflection with code injection can certainly implement s= uch a function. My concern is exactly how it gets implemented.
Let's say you implement it with metacode that looks something like th= is:

if((test =3D=3D <enumerators>) || ... || false)
=C2=A0 return<= span style=3D"color:#000"> true;
return false;
=

`<enumerators>` in this example is something that ac= ts like a parameter pack, which contains all of the enumerators in the enum= .. Ignore the actual syntax here. The point is that you're testing all o= f the enumerators in one full expression.

Some enumerations are big.= Really big. Like thousands of them. And compilers have limitations = as to how big of an expression they can actually evaluate. The standard onl= y requires 256 parenthesized expressions, while we can have 4096 enumerator= s in an enumeration. That's a pretty wide disparity.

Now obvious= ly there's more than one way to skin a cat. You can implement this test= er in a number of different ways. You can even implement it in different wa= ys based on the number of enumerators.

The thing that seems clear to= me is that a good implementation of this meta-function would rely on aspec= ts of the compiler that cannot be determined. And I don't relish the id= ea of having a metafunction do a compile-time sort on an thousand-entry enu= meration in order to determine ranges to do comparisons with. Granted, this= is all cutting edge stuff, so maybe it compiles to efficient code.

= I guess my overall point is that, as these features start nearing the stand= ard, it would be good to take a look at how compile-time limitations start = impacting implementations of code injection. And most importantly, if there= are some low-hanging fruit features that can better be implemented by the = standard library (behind which may be compiler intrinsic) than by user meta= functions.

We may even want to give users the ability to query some = compile-time limitations. If they're going to have to live within them,= having a constexpr query for them would probably be a good idea.

--
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/2941cf7e-74cf-4a52-b3df-b0c90192bca2= %40isocpp.org.
------=_Part_3426_700537112.1510452176058-- ------=_Part_3425_793406109.1510452176057-- .