220 37564 <5e47cc81-4834-4a68-8925-717fb2ec8612@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: liweifriends@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: add the metafunction scope Date: Thu, 29 Mar 2018 19:01:03 -0700 (PDT) Lines: 139 Approved: news@gmane.org Message-ID: <5e47cc81-4834-4a68-8925-717fb2ec8612@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_4691_154450286.1522375263801" X-Trace: blaine.gmane.org 1522375148 2019 195.159.176.226 (30 Mar 2018 01:59:08 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 30 Mar 2018 01:59:08 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCJ5X27PZQERBYFU63KQKGQELLUH2WY@isocpp.org Fri Mar 30 03:59:03 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ua0-f197.google.com ([209.85.217.197]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1f1jJi-0000KB-RX for gclcip-std-proposals@m.gmane.org; Fri, 30 Mar 2018 03:58:59 +0200 Original-Received: by mail-ua0-f197.google.com with SMTP id z27sf4911611uae.23 for ; Thu, 29 Mar 2018 19:01:06 -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:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=2l0dYBzQx5Cyoi0X+sHo8tLWomGSkKHTionRsFq9ZfE=; b=0hUuCMFMJk0z2rmMq5gjo662tXGCjn2582mjq7PtfDdDicjZJIyyoFfJVh9rBQgJse rjFBATR0lGxim1/CbPHF6nk88MbXL4by2EvewfSltBrkWXQZsTTE7XFki3+NBqOb24XB 8ycqh/NN7L54Hbf8FYIpm7WdFLvpMZcJPIvDPcfBUAUunkGBm7iZ9F/wN4Uadmz5cYV2 eGlJlcn5q/fGdI82iQ04SCcQEgPkqSvfkTc0yAq9GG1eRoe7zZumga3eTZhiRoOUZgkM qo7NvDJ9aVBB+yNJ4CqakmaL1bwNip34KZhqAnI9FzRkOAtET5ZFfWsrAWTPziFXl80t dZRA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:message-id:subject:mime-version:x-original-sender :reply-to:precedence:mailing-list:list-id:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=2l0dYBzQx5Cyoi0X+sHo8tLWomGSkKHTionRsFq9ZfE=; b=GbMCF5RbiWyAmsgmCpA1uUIgtumROY6vqI7rHu7CZsWuxEPwOWyB9MpdfTzXdwFyiN lixSh+DYZY8xXiS5+nvir+Do2TWWgM7Q5PL7hZFY9ep+BEyPgc6bbwYNzWXocSvJLxDP uX1NYqjtyceXgKzHT20rw6CbcM9tybijjgivN8ZGKA+AI/D+QV6Zt20QUl9bIpg0l0tl JjSM++DsL4vruM79b4L+zsy/EM38Mfrf9v/HQtI87lH2DvP1c/DUQNpqm0faU6GQ0og6 dHgjPUvWEGnsPmPsxgOWZHbKkbKuwtER97rfEx06XExkArcvmxrw4jxNbDOE8+Ght7vf kohg== 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=2l0dYBzQx5Cyoi0X+sHo8tLWomGSkKHTionRsFq9ZfE=; b=TPW5d3MJgAUcy8mueN+I9HrnzHJsp07L0pMU8ZcODzasHF4LwpJE0bjoZMD3CdU9wf 3Ils8rvn+GPdCyKiEDDLagT1lEjyPStsyXqnV3zhs+JFKAWj/bC2iIjw7AUM90S5q69r iWPQCrQLPTq34rZeSyfxhqvA6erevgNcmMm+HeGvT9UBLedJ167DskhBwlyi7W7ti4rZ 3oqM4xm1xuc9SitrTJgJaJvJOs3tlasyiRliRN8bLD/Mo1bGfAzBze4NH3IVrMNvM3Wy OH8vVMPYtG4evhRaizEWafZLW4NOdPANhD6oMlckcMSd8RiHF4iRkaI0pZYIC3JuA45n nYzA== X-Gm-Message-State: ALQs6tCkywPvawv3wjLlIwKt5PN4mh6cMbN3Av5Q9YR0fa7vUDwQEQZq b8O8Dp/d5Jr7a6B/aupbndVMgg== X-Google-Smtp-Source: AIpwx4+Mvf1rbxMZyuK0q6BjaK4BoExUECK1snjAbGAHM20qDuBi578xvlQUn84oUmBa4kmKfxg4JQ== X-Received: by 10.31.68.200 with SMTP id r191mr1405414vka.68.1522375266036; Thu, 29 Mar 2018 19:01:06 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.31.86.129 with SMTP id k123ls4378799vkb.5.gmail; Thu, 29 Mar 2018 19:01:04 -0700 (PDT) X-Received: by 10.31.173.80 with SMTP id w77mr4013413vke.13.1522375264439; Thu, 29 Mar 2018 19:01:04 -0700 (PDT) X-Original-Sender: liweifriends@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:37564 Archived-At: ------=_Part_4691_154450286.1522375263801 Content-Type: multipart/alternative; boundary="----=_Part_4692_651785234.1522375263801" ------=_Part_4692_651785234.1522375263801 Content-Type: text/plain; charset="UTF-8" In C++, We can introduce a scope to control the life-time of a runtime variable. When the scrope is end, the variable inside the scope will be removed to save the memory. For example: { int a = ... shared_ptr b = new int() } When running at the end of the scope, a and b will be removed from the stack and heap. But when considering the compile time calculation, currently C++ doesn't have a similar mechanism to tell the compiler to "free" some useless information. For example: template struct RemoveConstReference { using tmp = typename std::remove_const::type; using type = typename std::remove_reference::type; }; using ResType = typename RemoveConstReference::type; // calling compile time calculation, ResType will be int When calculating ResTypeat compile time, the compiler might generate some Intermediate information (such as RemoveConstReference::tmp). The compiler might assume this information might be used further and therefore allocate a memory to store these kind of information. But in fact, the info such as RemoveConstReference::tmp might never be used anymore. Since it is just a "Intermediate result" of compile time calculation and is useless after we get the type of ResType. 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; 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. -- 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/5e47cc81-4834-4a68-8925-717fb2ec8612%40isocpp.org. ------=_Part_4692_651785234.1522375263801 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
In C++, We can introduce a scope to control the life-time = of a runtime variable. When the scrope is end, the variable inside the scop= e will be removed to save the memory. For example:

{
=C2=A0=C2=A0=C2=A0 int a =3D ...
=C2=A0=C2= =A0=C2=A0 shared_ptr<int> b =3D new int()
}

When run= ning at the end of the scope, a and b will be removed from the stack and he= ap.

But when considering the compile time calculation, currently C+= + doesn't have a similar mechanism to tell the compiler to "free&q= uot; some useless information. For example:

template <typename T>
struct RemoveConstReference=
{
=C2=A0=C2=A0=C2=A0 using tmp =3D typename std::remove_const<T&g= t;::type;
=C2=A0=C2=A0=C2=A0 using type =3D typename std::remove_referen= ce<tmp>::type;
};

using ResType =3D typename RemoveConstRef= erence<const int&>::type;=C2=A0 // calling compile time calculati= on, ResType will be int

When calculating ResTypeat compile ti= me, the compiler might generate some Intermediate information (such as Remo= veConstReference<const int&>::tmp). The compiler might assume thi= s information might be used further and therefore allocate a memory to stor= e these kind of information.

But in fact, the info such as RemoveCon= stReference<const int&>::tmp might never be used anymore. Since i= t is just a "Intermediate result" of compile time calculation and= is useless after we get the type of ResType.

For a program that = heavily depends on compile time calculation, this might be a serious proble= m, since the compiler might store a lot of such "useless" informa= tion during compile, this will increase the memory useage of the compiler a= nd slow down the compile procedure.

To solve this problem, I think w= e should introduce an "metafunction" scope, as follows:

metafunction
{
template <typename T>struct RemoveConstReference
{
=C2=A0=C2=A0=C2=A0 using tmp =3D typen= ame std::remove_const<T>::type;
=C2=A0=C2=A0=C2=A0 using type =3D = typename std::remove_reference<tmp>::type;
};
}

using ResType =3D typename RemoveConstReference<const int&>::type;
=
the RemoveConstReference is includ= ed inside this scope, so after the calculation of ResType, the compiler mig= ht remove all the information generated inside this scope. This will save t= he memory of the compiler and speed up the compile procedure.

--
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/5e47cc81-4834-4a68-8925-717fb2ec8612= %40isocpp.org.
------=_Part_4692_651785234.1522375263801-- ------=_Part_4691_154450286.1522375263801-- .