220 39077 article Path: news.gmane.org!.POSTED!not-for-mail From: gmisocpp@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: constexpr! or constexpr(false)? Date: Wed, 11 Jul 2018 03:35:12 -0700 (PDT) Lines: 237 Approved: news@gmane.org Message-ID: References: <303bf6d1-2f5a-4b50-b6c0-6d689300243c@isocpp.org> <20180711072840.5177422.61062.57260@gmail.com> <73b413ed-cfef-4174-ac91-51f1eff0274d@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_126378_1131050350.1531305312864" X-Trace: blaine.gmane.org 1531305189 20978 195.159.176.226 (11 Jul 2018 10:33:09 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 11 Jul 2018 10:33:09 +0000 (UTC) Cc: florian.csdt@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCM3TRNUXUDBBYN2S7NAKGQEXAA3XJI@isocpp.org Wed Jul 11 12:33:05 2018 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 1fdCQh-0005KC-IC for gclcip-std-proposals@m.gmane.org; Wed, 11 Jul 2018 12:33:03 +0200 Original-Received: by mail-yw0-f199.google.com with SMTP id q141-v6sf11578849ywg.5 for ; Wed, 11 Jul 2018 03:35:15 -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:list-post:list-help:list-archive:list-subscribe :list-unsubscribe; bh=vvjBuMOZetlvWmK2+eWnGjieRvDE4s41fyPXTip2QTc=; b=Z/TSeblnw8iO8Sa/nUJMvWnDM1AL/zsJe5xp0kstdeyD1KV6v2MG0PiMoyUF9QgwWZ DPscaIRwPO88Kr9awVmEp2ZTkCByVEMJojm2O6Th+fB4eDXHp603JFkbSdISInfG+b9p JkUv2FoR07+oJr9wFfj+hz9gjxMkqD5E6vzdt7f4H3/O1c3/MP2Y0WFr5+KiN/LnlTBe mwx4HKX5bmIKDDdlmBEFbp88jyTKpeKcjcessc2m7jy+Q6Rl3CIaoipCfNmkKe9ajUbp aWgI4d+wBEPnhWlegOccv9QLfULXUxTqIJc0E3b9jvfKYK1wkbl8yPWNrXkipy+FP/Ue t3CQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc: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=vvjBuMOZetlvWmK2+eWnGjieRvDE4s41fyPXTip2QTc=; b=UxL2XUNNlk/UMQitYMhtZUow3WXN99ENRN7jiMfZnneyczZMWfmm/Sg2f+zHMxx699 hQbdplWHdrv+HdF5knu/3tfzttNe93FFT2mZYaoGiVCOd0nmwPFPMV5PTWO5aq9ynC1S 9BOxX6aohVMO3JmLFws/QFZ2RMLt3xwkQZarUAVgUERPlc2jBKRhIDleTGX3/Ue7p1fb lcNIjVVOBIxiDfta/jG3msUVUo+fB61TH9unNMVs2voU6Pw+BE/b2Wd2EnjP3BS60owX /Y9Ojqyh2Z6gQijoGTAgc3/rWZsIo3CTtx3+q5g1KZnOurkHH41zeSZLhuE+G+YQy1N6 x+fw== 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=vvjBuMOZetlvWmK2+eWnGjieRvDE4s41fyPXTip2QTc=; b=lC/6P/MWdC3kuUmfzuM4J0siJ2kswrcGO1JHPvEPEa8obublf9gbYqbkZn8BdTrmXU ZeEDzpgShku3iQZ5d35xACpddPpwzvZ3Sr4qSP12S/jvW9EO3NcnVDaVCurz4Hqn7bF8 RSIgn0RlZQqe6EwsvqqKjlDEa1bfj/HM4fvzPkRr9fOUhZS1GHNbeV3lrq9b7VHPxYJP UGGmHBfWRtM6biv6Qxg6TCTdXEH3nD82EfszohrIFeX2dTmK9EHefuUfqz0PJ5yqa+3V yZ689fO/ZDpLcyaaJP5MU7UMS6ZwNpPKQ8dEHZWyz+kFkbNr8jl61fpkMtApnkB2Tsit 6rzA== X-Gm-Message-State: APt69E1R9M5vi674xoYrQFo2hASHt/SJa9MnYiF5mFgYSiUImvfPYUIV SDtxM87CmUVH7vO8GhPyutddNQ== X-Google-Smtp-Source: AAOMgpfrryxEwZQQonAr1NosOUx7S9RVkw+CyRGzprYPLFhwXkaauqJKqI4O5418AQAJeH63QOv6tg== X-Received: by 2002:a25:62cc:: with SMTP id w195-v6mr8927668ybb.46.1531305314570; Wed, 11 Jul 2018 03:35:14 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 2002:a25:2fd2:: with SMTP id v201-v6ls5246811ybv.10.gmail; Wed, 11 Jul 2018 03:35:13 -0700 (PDT) X-Received: by 2002:a5b:60f:: with SMTP id d15-v6mr3887199ybq.6.1531305313281; Wed, 11 Jul 2018 03:35:13 -0700 (PDT) In-Reply-To: X-Original-Sender: gmisocpp@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:39077 Archived-At: ------=_Part_126378_1131050350.1531305312864 Content-Type: multipart/alternative; boundary="----=_Part_126379_310321190.1531305312865" ------=_Part_126379_310321190.1531305312865 Content-Type: text/plain; charset="UTF-8" On Wednesday, July 11, 2018 at 8:23:51 PM UTC+12, floria...@gmail.com wrote: > > > I would like to highlight some facts: the inline keyword is not about > inlining. As already said by others, the abstract machine has no notion of > what is inlining. > The reason is simple: inlining doesn't change the behavior of a program, > only its speed (and stack usage in some cases). > The abstract machine doesn't care about speed, only the bahavior. > I'm not sure keep thinking about inline on it's own is helpful to my case, though perhaps it might be for your case. But see my comment later. > > Currently, what inline is about is multiple definition of a single > function/object across translation units. > If you want extra information, have a look at > https://en.cppreference.com/w/cpp/language/inline > > > That being said, it would still be interested to have a force inline. > The best example I can think of is calling alloca within a function, and > returning the pointer. On every compilers I tested, the allocated stack > memory is kept after this call iif the call is actually inlined. > One use case would be runtime size class: > template class T> > class stack_array { > private: > T* p; > public: > inline! stack_array(int n) : p(alloca(n * sizeof(T))) {} > stack_array() = delete; > stack_array(const stack_array&) = delete; > stack_array& operator=(const stack_array&) = delete; > ~stack_array() = default; > > /* ... */ > }; > > Now, to standardize that kind of stuff, I think we should speak in terms > of scopes: > the internal scope of an inline! function is the same as the scope where > the call is performed. > As the alloca memory is "deallocated" at the end of the scope, we have the > expected behavior. > > For this to work, the definition of the inline! function must be visible > at the call site, and the simplest way to implement it in the compiler is > to actually perform inlining. > With such a definition, inline! cannot be implemented with an attribute as > it changes the semantic of the program, and cannot be ignored. > People compile their code and when they don't get the result they want, they use __forceinline or always_inline or resort to that immediately. At that point they now have compiler specific code and macros. If they had inline! in terms in the mentioned they would have less of that type of code. My description of inline! if defined in terms of __forceinline and always_inline. What you are after sounds like something more complicated and therefore a different feature than what my suggestion is aiming for. I've little doubt that what you want is of value but you are opening more cans of worms to get it. A question to ask also is does your feature likely promise to do the thing that makes people reach for __forceinline and always_inline. I don't really have much of a problem with anything you've said other than I think if everyone heads off to define that what you are talking about I suspect it'll be something else to what I'm proposing. If it makes C++ better, ok. It seems there are a few features in this space that people need. -- 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/d7201ef1-1e7b-4735-bd84-8e81b3983d10%40isocpp.org. ------=_Part_126379_310321190.1531305312865 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wednesday, July 11, 2018 at 8:23:51 PM UTC+12, = floria...@gmail.com wrote:

I would like to highlight some facts: the inline keyword is not about inli= ning. As already said by others, the abstract machine has no notion of what= is inlining.
The reason is simple: inlining doesn't change t= he behavior of a program, only its speed (and stack usage in some cases).
The abstract machine doesn't care about speed, only the bahavi= or.

I'm not sure keep think= ing about inline on it's own is helpful to my case,=C2=A0though perhaps= it might be for your case.
But see my comment later.
<= br>
=C2=A0

Currently, what inline is about is multiple definition of a single functio= n/object across translation units.
If you want extra informat= ion, have a look at https://en.cppre= ference.com/w/cpp/language/inline

That be= ing said, it would still be interested to have a force inline.
Th= e best example I can think of is calling alloca within a function, and retu= rning the pointer. On every compilers I tested, the allocated stack memory = is kept after this call iif the call is actually inlined.
One use= case would be runtime size class:
template class T>
class stack_array {
=C2=A0 private:
=C2=A0= =C2=A0 T* p
=C2=A0 public:
=C2=A0 =C2=A0 inline! stack_ar= ray(int n) : p(alloca(n * sizeo= f(T))) {}
=C2=A0 =C2= =A0 stack_array() =3D delete;
=C2=A0 =C2=A0 stack= _array(const&)= =3D delete;
=C2=A0 =C2=A0 sta= ck_array& =3D(const stack_array&) =3D delete;
=C2=A0 =C2= =A0 ~stack_array() =3D <= /span>default;
<= br>=C2=A0 =C2=A0 /* ... */
};
=

Now, to standardize that kind of stuff, I think we s= hould speak in terms of scopes:
the internal scope of an inline! = function is the same as the scope where the call is performed.
As= the alloca memory is "deallocated" at the end of the scope, we h= ave the expected behavior.

For this to work, the d= efinition of the inline! function must be visible at the call site, and the= simplest way to implement it in the compiler is to actually perform inlini= ng.
With such a definition, inline! cannot be implemented with an= attribute as it changes the semantic of the program, and cannot be ignored= ..

People compile their code= and when they don't get the result they want, they use __forceinline o= r=C2=A0always_inline or resort to that immediately.
At that point= they now have compiler specific code and macros. If they had inline! in te= rms=C2=A0in the mentioned they would have less of that type of code.
<= div>My description of inline! if defined in terms of __forceinline and alwa= ys_inline.

What you are after sounds like somethin= g more complicated and therefore a=C2=A0different feature than what my sugg= estion is aiming for.
I've little doubt that what you want is= of value but you are opening more cans of worms to get it.
A que= stion to ask also is does your feature likely promise to do the thing that= =C2=A0makes people reach for=C2=A0__forceinline and always_inline.

I don't really have much of a problem with anything yo= u've said other than I think if everyone heads off to define that what = you are talking about I suspect it'll be something else to what I'm= proposing.=C2=A0If it makes C++ better, ok. It seems there are a few featu= res in this space that people need.

--
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/d7201ef1-1e7b-4735-bd84-8e81b3983d10= %40isocpp.org.
------=_Part_126379_310321190.1531305312865-- ------=_Part_126378_1131050350.1531305312864-- .