220 37568 article Path: news.gmane.org!.POSTED!not-for-mail From: =?UTF-8?B?5p2O5Lyf?= Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: add the metafunction scope Date: Fri, 30 Mar 2018 14:07:38 +0800 Lines: 274 Approved: news@gmane.org Message-ID: References: <5e47cc81-4834-4a68-8925-717fb2ec8612@isocpp.org> <20180330054757.GA2396@noemi> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="94eb2c033e44a84c5f05689b0e85" X-Trace: blaine.gmane.org 1522389938 19675 195.159.176.226 (30 Mar 2018 06:05:38 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 30 Mar 2018 06:05:38 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCJ5X27PZQERBK5I67KQKGQEMRFT7BY@isocpp.org Fri Mar 30 08:05:34 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qt0-f200.google.com ([209.85.216.200]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f1nAK-00050I-Ua for gclcip-std-proposals@m.gmane.org; Fri, 30 Mar 2018 08:05:33 +0200 Original-Received: by mail-qt0-f200.google.com with SMTP id g2sf5636259qtp.5 for ; Thu, 29 Mar 2018 23:07:40 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1522390060; cv=pass; d=google.com; s=arc-20160816; b=CRvbnlTJBD0ASyKt8Ly8uwAv9QfhkcvRMr2kLZxVx/BBRFmv5hOD4Tem63H8OqUPI2 hexgMLmtiGTvFfcjx1CBHzU1bHMhwK2g1YekjqbGaqYfts3oLc7Kp+1yMKJqvasQF6Hx FhxNdXJ+OJg6pG45KiplBvAXDuCPxWF4sw5dN0lufBzQzJFpsISW7y2w7X0qvgWFYBf6 T503oZOZpd3jRgrSdu4py34cpDHsVRQ2fkMM22rOt3meWcpF83f9uWsfn/UZ51DWhK/Z SKS2nvLrjY+ka0cA0nAzL7hPMGQlWGSl+TxehIyYYbaItjeYhaWBY9kJMk4zI7zqnere vIDg== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:reply-to:to:subject:message-id:date :from:references:in-reply-to:mime-version:arc-authentication-results :arc-message-signature:dkim-signature:arc-authentication-results; bh=pZGvnCCUzo4cPfQH+x5jhx/v8gLoXYZPn8akZSwaW6I=; b=cOAGGnUuUvBvT0vw5FYdfEdVvWE+oEc1ywPRzDAiMyt+MAi2zsQwiio4mOqBhQT5Rh l5ubdNrWyr5KWUSENFUsoKUnoJolSWkgyuZnqMYMF3iqtV1BJWt5Oghfc15pMxp7HIA/ u+5c5pUPFXDKKjHlqczqwIwaI+CjI0wDgyxEmaYpI21c/8tTN24JuhsqxwP3Ru1B2E9T CmXRsG+CjRNSOKvH9uUBIptqs+tqAtkUH31lFJkjZBPc9QaAWeVWIK2hWq3HKidjashH VJhEbtBu1Zwv0L1xrPwN7IuEehobkMURUtNnHEU6JikSmqMexrUZwXbGoD/F183Sgn5D 25jQ== ARC-Authentication-Results: i=2; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=ZGfRmjMf; spf=pass (google.com: domain of liweifriends@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=liweifriends@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :x-original-sender:x-original-authentication-results:reply-to :precedence:mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=pZGvnCCUzo4cPfQH+x5jhx/v8gLoXYZPn8akZSwaW6I=; b=j+mV+OHuJh0DrEzZftV+9IaS+zngj4odOU2h9f52ZouCluNShjbxt4flbmAz0ff/j9 aSMoaZZ1CuvqVx3GdGoFsSB7DzwrApi7HcZ5QvS2S/uFdVI1fXueg9MTRlrmUDmqU1rW oLd+J5UsLtiUt2olkTXi3gxll4vUz7m+a5dbZqDPZepbY0WI93MS1wtgAfSBI155QVZS ACzdzHlvdkJXmL7PvepCDt2CoxTOw7H6F7DXh/x2MteDhS9UjkR4I2qEbw24S/WnOPXT wucFlIXbYUQtLcYKPATe8UM8oXPr2Szc7SB9stdw8aWzC6kV++We5bFPjfqMBfOUy1jH nqcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject: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=pZGvnCCUzo4cPfQH+x5jhx/v8gLoXYZPn8akZSwaW6I=; b=nbEGkoyDVM+v9tTH8IrAUa8jI/aDfe8ijlQblBl4oxqDlVFV/r51kYSUSeVuCgF9Qc McWoxjLy2qKyEXVgnFQKQwmzMSAsOG+1sZ8SCuankQQaJ0kk70jGrvEYiJM4Ho1dfJNg c6eQpu9jkmDQL4TrtnkE3dFafVMI0NTea85dAi/NIL94RRhPtFGLYb0s6+Q/MOmThska mcLWtbUBV7w8rfOkSIq8Q5iwLm3zPctiFHcFWnAo03ZzjD5NVt5vfu7jmfPESBdFiu1Y JnUfMo8abKkN9EoB6dpEdUrzO/qzMG5hy7Uv06XrnomupKCPTS3b2G3FmXBNzNATALqX bJsw== X-Gm-Message-State: AElRT7HM4Dtb8LYkR3TJ3WieuZbrxTrkAewrndcyVxgVrQmQA0n29Q8u 6e5h/s8Na36ZG8a3EbBRPhdFcg== X-Google-Smtp-Source: AIpwx49H4lK6krxUp7cP0j1TYU8+VWGQXFz/O6/CtsviBfaTrlz5S38VMP2zeI9lcWdnESicj0SYVA== X-Received: by 10.55.37.203 with SMTP id l72mr15863523qkl.20.1522390059988; Thu, 29 Mar 2018 23:07:39 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.200.38.97 with SMTP id v30ls5056422qtv.4.gmail; Thu, 29 Mar 2018 23:07:39 -0700 (PDT) X-Received: by 10.200.2.153 with SMTP id p25mr15941513qtg.229.1522390059247; Thu, 29 Mar 2018 23:07:39 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1522390059; cv=none; d=google.com; s=arc-20160816; b=GvIcxu1P0Vt82ejLOEBbFBGXJU4e9p09K9L8qcEe5ufI5HfftE7+4HBNjWSoniFpLV J1jqmBzh+yBuK14c1FX8cD23VW5r0apH8OGcFlJOtSfGdZLmKv7e/7PSti8VkUwOhGBw SWkLFLIlwhSQdhn8cpYHyrjDjafXBt6OptfnMqfcnB0BqXt1oxcepehTSjwz5R43pCpb N9lh/LOslTpo9UncyBeBatN/zKBVAZFAU9PJGfs2dV0Q0auhU7RqWEhmyFB6Xt5bduBp C+14dq307SGWuab2S+DpmVITJV+Coo9Qhb8l+2slT5strlwhToIJY+s58jQj1xaFPPYu aciw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=to:subject:message-id:date:from:references:in-reply-to:mime-version :dkim-signature:arc-authentication-results; bh=yztk60JEKozs1iJVbLDPwo/Gi7QITwLfimi07A1HdBM=; b=HXb+Cz6Pz2RuXF74cgMcxB6VjBhGQre28GMMzTYcRsD7qBwWehKnt/jvFXRVv/AxoC 8J83kG8Sh3IAL1ukYIiuMAj8WU22WMhLzlbE1otLSuxu3CHfRFcDoHOhHq6xGjk4gIoX ii+uUIVlDCXPB8T+mPsP1AUptJse+v5L4hQlOqmciYPXvc7TOVrz2awiw6QWIyobfRlo Tu1GmVwq7869i2vGSVMo4mmuaufHU46droZvkKx+zfCWH3eKWSIXfHvd1Ujxpe7xCBCE ME3y0Gp8dvbMNy8NQh0JzCt+O7cf2ZOp5V2OQOFOP1XT8fluDQsiPeURl1zajDnubUcT sMXQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=ZGfRmjMf; spf=pass (google.com: domain of liweifriends@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=liweifriends@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Original-Received: from mail-sor-f41.google.com (mail-sor-f41.google.com. [209.85.220.41]) by mx.google.com with SMTPS id x20sor6672212qtb.87.2018.03.29.23.07.39 for (Google Transport Security); Thu, 29 Mar 2018 23:07:39 -0700 (PDT) Received-SPF: pass (google.com: domain of liweifriends@gmail.com designates 209.85.220.41 as permitted sender) client-ip=209.85.220.41; X-Received: by 10.200.63.6 with SMTP id c6mr16001494qtk.286.1522390058682; Thu, 29 Mar 2018 23:07:38 -0700 (PDT) Original-Received: by 10.200.30.20 with HTTP; Thu, 29 Mar 2018 23:07:38 -0700 (PDT) In-Reply-To: <20180330054757.GA2396@noemi> X-Original-Sender: liweifriends@gmail.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=ZGfRmjMf; spf=pass (google.com: domain of liweifriends@gmail.com designates 209.85.220.41 as permitted sender) smtp.mailfrom=liweifriends@gmail.com; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Spam-Checked-In-Group: std-proposals@isocpp.org 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:37568 Archived-At: --94eb2c033e44a84c5f05689b0e85 Content-Type: text/plain; charset="UTF-8" Hi Magnus: Thanks for your response. I'd like to explain about your points: 1. Ain't RemoveConstReference out of scope at the point of "using ResType"? For the oroginal code, after calculating the type of ResType, the compiler keeps the information of RemoveConstReference::tmp and RemoveConstReference::type. They are useless any more. The metafunction scope just tells the compiler to remove RemoveConstReference::tmp and RemoveConstReference::type (for example, from its symbol table) during compile time. 2. If, on the other hand you put "using ResType" before the closing brace of the metafunction clause then ResType would become undefined right after it's definition and that also is unusable. For the most of time, we doing a compile time calculation, we just want to calculate some type/value results for further usage. Therefore, the common usage of metafunction is as follows: metafunction {...} Caller of metafunction, such as "using ResType" in the above code The caller must located out of the metafunction scope, otherwise it might be removed after the compile time calculation. 3. As a final thoght this sounds a lot like a namespace with an unutterable name, how does your metafunction compare to a namespace? It is definitely not a namespace. If we write the code as follows: namespace { template struct RemoveConstReference { using tmp = typename std::remove_const::type; using type = typename std::remove_reference::type; }; } using ResType = typename RemoveConstReference::type; During compile time, the compiler would still maintain the information about [namespace]::RemoveConstReference::tmp and [namespace]:: RemoveConstReference::type even after it finishes the calculation of ResType, which might be a waste of a compile time memory. Thanks Wei 2018-03-30 13:47 GMT+08:00 Magnus Fromreide : > On Thu, Mar 29, 2018 at 07:01:03PM -0700, liweifriends@gmail.com wrote: > > > > For a program that heavily depends on compile time calculation, this > might > > be a serious problem, since the compiler might store a lot of such > > "useless" information during compile, this will increase the memory > useage > > of the compiler and slow down the compile procedure. > > > > To solve this problem, I think we should introduce an "metafunction" > scope, > > as follows: > > > > metafunction > > { > > template > > struct RemoveConstReference > > { > > using tmp = typename std::remove_const::type; > > using type = typename std::remove_reference::type; > > }; > > } > > > > using ResType = typename RemoveConstReference::type; > > Your example does not make any sense. > > Ain't RemoveConstReference out of scope at the point of "using ResType"? > > > the RemoveConstReference is included inside this scope, so after the > > calculation of ResType, the compiler might remove all the information > > generated inside this scope. This will save the memory of the compiler > and > > speed up the compile procedure. > > If, on the other hand you put "using ResType" before the closing brace of > the metafunction clause then ResType would become undefined right after > it's > definition and that also is unusable. > > As a final thoght this sounds a lot like a namespace with an unutterable > name, > how does your metafunction compare to a namespace? > > /MF > > -- > 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/20180330054757.GA2396%40noemi. > -- 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/CANNXMwZMCpDOHj-e_mEmWQ37QEtmT_%2Bto8oyDHUkiUjrpC4NFA%40mail.gmail.com. --94eb2c033e44a84c5f05689b0e85 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Magnus:

Thanks for your response= .. I'd like to explain about your points:

1.=20 Ain't RemoveConstReference out of scope at the point of "using Res= Type"?

For the oroginal code, after calculating the type of=20 ResType, the compiler keeps the information of=20 RemoveConstReference<const int&>= ::tmp and RemoveConstReference<c= onst int&>::type. They are useless any more. The metafunction= scope just tells the compiler to remove=20 RemoveConstReference<c= onst int&>::tmp and=20 RemoveConstReference<c= onst int&>::type (for example, from its symbol table) during compile time.

2.= =20 If, on the other hand you put "using ResType" before the closing = brace of=C2=A0 the metafunction clause then ResType would become undefined right after it&= #39;s definition and that also is unusable.
For the most of time, we doing a compile time calculation, w= e just want to calculate some type/value results for further usage. Therefo= re, the common usage of=20 metafunction is as follows:

metafunction {...}
Caller of metafunction, such as=20 "using ResType" in the above cod= e

The caller must located out of the metafunction scope, = otherwise it might be removed after the compile time calculation.

3= ..=20 As a final thoght this sounds a lot like a namespace with an unutterable na= me, how does your metafunction compare to a namespace?
It is definitely not a namespace. If we write the code as fo= llows:
namespace {
=C2=A0=C2=A0 template <typename = T>
=C2=A0=C2=A0 struct RemoveConstReference
=C2=A0=C2=A0 {
=C2= =A0=C2=A0 =C2=A0=C2=A0 using tmp =3D typename std::remove_const<T>::t= ype;
=C2=A0=C2=A0 =C2=A0=C2=A0 using type =3D typename std::remove_reference<= tmp>::type;
=C2=A0=C2=A0 };
}

using ResType =3D typena= me RemoveConstReference<const int&>::type;

During compile time, the compiler would still maintain t= he information about [namespace]::RemoveConstRefer= ence<const int&= amp;>::tmp and=20 [namespace]::RemoveConstReference<const int&>= ;::type even after it finishes the calculation of=20 ResType, which might be a waste of a compile time = memory.

Thanks

Wei

=

2018-03-30 = 13:47 GMT+08:00 Magnus Fromreide <magfr@lysator.liu.se>:<= br>
On Thu, Mar 29, 2018 at = 07:01:03PM -0700, liweifriends@gm= ail.com wrote:
>
> For a program that heavily depends on compile time calculation, this m= ight
> be a serious problem, since the compiler might store a lot of such
> "useless" information during compile, this will increase the= memory useage
> of the compiler and slow down the compile procedure.
>
> To solve this problem, I think we should introduce an "metafuncti= on" scope,
> as follows:
>
> metafunction
> {
> template <typename T>
> struct RemoveConstReference
> {
>=C2=A0 =C2=A0 =C2=A0using tmp =3D typename std::remove_const<T>::= type;
>=C2=A0 =C2=A0 =C2=A0using type =3D typename std::remove_reference<tm= p>::type;
> };
> }
>
> using ResType =3D typename RemoveConstReference<const int&>:= :type;

Your example does not make any sense.

Ain't RemoveConstReference out of scope at the point of "using Res= Type"?

> the RemoveConstReference is included inside this scope, so after the > calculation of ResType, the compiler might remove all the information<= br> > generated inside this scope. This will save the memory of the compiler= and
> speed up the compile procedure.

If, on the other hand you put "using ResType" before the c= losing brace of
the metafunction clause then ResType would become undefined right after it&= #39;s
definition and that also is unusable.

As a final thoght this sounds a lot like a namespace with an unutterable na= me,
how does your metafunction compare to a namespace?

/MF

--
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-propo= sals+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/isoc= pp.org/d/msgid/std-proposals/20180330054757.GA2396%40noemi.

--
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 h= ttps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANNXMwZMCpDOHj= -e_mEmWQ37QEtmT_%2Bto8oyDHUkiUjrpC4NFA%40mail.gmail.com.
--94eb2c033e44a84c5f05689b0e85-- .