Topic: Meta-programming suggestions.
Author: Alexander Nikolov <sasho648@mail.bg>
Date: Thu, 5 Mar 2015 09:30:06 -0800 (PST)
Raw View
------=_Part_7875_1270125837.1425576606360
Content-Type: multipart/alternative;
boundary="----=_Part_7876_1017491279.1425576606360"
------=_Part_7876_1017491279.1425576606360
Content-Type: text/plain; charset=UTF-8
I thought I should pop up the matter of meta-programming again - especially
the non-template one, mainly because of the new ideas and experience I've
got.
First let's think about what's so different about 'constexpr' functions:
- They can be called in places where constant value is required - in which
case they are evaluated at compile-time.
- Otherwise they behave the exact same way as other functions.
What should the parser need to know in order to execute a function at
compile-time - it's body and that's what the inline function specifier
guarantees. So why then we need this new keyword 'constexpr'? Because
'inline' is already reserved in variables declaration?? (this is not true)
This implies my first suggestion which is removing 'constexpr' as a keyword
and instead replacing/merging it with the already existing 'inline' one.
Another thing I noticed is the requirement that before using the 'typeid',
<typeinfo> <http://en.cppreference.com/w/cpp/header/typeinfo> should be
included and otherwise the program is ill-formed which is an absurd for me
at least. After-all it is a keyword and in my opinion no keyword should
depend on such high-level details (is one header included or not). I
suggest re-implementing this keyword as a function defined in this header.
But for implementing it we should either use templates or what I introduce
- pure constant-expression functions with the possibility for
constant-expression variables and function parameters to map types by
declaring them with 'class'.
This is a function which should be executed at compile-time (rather than
'can be') and which is allowed to access only it's locals and globally
(statically) defined constant-expression variables (talking about the pure
constant-expression function). Such function are only allowed to instance
other constant-expression functions (or classes). Variables declared in it
will be implicitly constant-expression excluding those with static linkage
and as well as its parameters and return-value.
Now we can declare 'typeid' by using my structures like this:
true inline /* if inline function is declared 'true' then it's a pure
constant-expression function */
const std::type_info <http://en.cppreference.com/w/cpp/types/type_info>
typeid(inline class T /* constant-expression variable which can be assigned
a type */ );
It would be also nice if standard library includes an 'true inline' variant
of it's functions (and classes) - at a different namespace maybe.
Also for the following code we would need an function return-type deduced
dynamically at the time return statement is executed for pure constant
expression functions. It would be nice if partial type specialization for
such deductions is allowed too (for example an array type with
automatically deduced number of elements).
This will allow us for example reading a file at compile-time like this:
true inline auto aReadFileAsCharArray(const char *pFileName /* implicitly
'inline' */)
{
using namespace std::_inline; //supposing that 'std::_inline' defines
all classes and functions from 'std' as constant-expression
//note:
//All below variables are implicitly constant-expression (as if they
//were declared 'inline')
ifstream iFile(pFileName, ios::ate); //try opening the file
if(!iFile.is_open()) //in case the file wasn't opened return null
pointer
return nullptr; //here return-type is 'std::nullptr_t'
auto szFile = iFile.size(); //get file size
array<int, szFile> chFile; //create a variable of type 'array<int,
szFile>'
//in order to store the file content
//*note: 'array<int, szFile>' is a complete
type because 'szFile' is
//a constant-expression
//read the file into the array and return it
iFile.seekg(0);
iFile.read(chFile.data(), szFile);
return chFile; //here return type is 'Ttmp' or 'array<int, szFile>'
//where 'szFile' is the size of the opened file
}
In the above example I'm using 'std::array' because unfortunately normal
ones can't be returned.
Below is an example instance of the function:
auto aFileContent = aReadFileAsCharArray("shader.vert");
Here 'aFileContent' will be of type 'std::_inline::array<char, fileSz>' as '
fileSz' will be the size of 'shader.vert'.
Of-course you could think of thousands other thing that such tools can
allow you to do as supposedly all the C++ library will be available to you
at run-time.
What do you think?
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_7876_1017491279.1425576606360
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I thought I should pop up the matter of meta-programming a=
gain - especially the non-template one, mainly because of the new ideas and=
experience I've got.<div><br></div><div>First let's think about what's so =
different about 'constexpr' functions:</div><div><br></div><div>- They can =
be called in places where constant value is required - in which case they a=
re evaluated at compile-time.</div><div><br></div><div>- Otherwise they beh=
ave the exact same way as other functions.</div><div><br></div><div>What sh=
ould the parser need to know in order to execute a function at compile-time=
- it's body and that's what the inline function specifier guarantees. So w=
hy then we need this new keyword 'constexpr'? Because 'inline' is already r=
eserved in variables declaration?? (this is not true)</div><div><br></div><=
div>This implies my first suggestion which is removing 'constexpr' as a key=
word and instead replacing/merging it with the already existing 'inline' on=
e.</div><div><br></div><div>Another thing I noticed is the requirement that=
before using the 'typeid', <a href=3D"http://en.cppreference.com/w/cp=
p/header/typeinfo" title=3D"cpp/header/typeinfo" style=3D"color: rgb(11, 0,=
128); font-family: DejaVuSans, 'DejaVu Sans', arial, sans-serif; font-size=
: 12.8000001907349px; line-height: 15.3600006103516px; background-image: no=
ne; background-attachment: initial; background-size: initial; background-or=
igin: initial; background-clip: initial; background-position: initial; back=
ground-repeat: initial;"><typeinfo></a> should be included and o=
therwise the program is ill-formed which is an absurd for me at least. Afte=
r-all it is a keyword and in my opinion no keyword should depend on such hi=
gh-level details (is one header included or not). I suggest re-implementing=
this keyword as a function defined in this header.</div><div><br></div><di=
v>But for implementing it we should either use templates or what I introduc=
e - pure constant-expression functions with the possibility for constant-ex=
pression variables and function parameters to map types by declaring them w=
ith 'class'.</div><div><br></div><div>This is a function which should be ex=
ecuted at compile-time (rather than 'can be') and which is allowed to acces=
s only it's locals and globally (statically) defined constant-expression va=
riables (talking about the pure constant-expression function). Such functio=
n are only allowed to instance other constant-expression functions (or clas=
ses). Variables declared in it will be implicitly constant-expression exclu=
ding those with static linkage and as well as its parameters and return-val=
ue.</div><div><br></div><div>Now we can declare 'typeid' by using my struct=
ures like this:<br><br></div><div class=3D"prettyprint" style=3D"border: 1p=
x solid rgb(187, 187, 187); word-wrap: break-word; background-color: rgb(25=
0, 250, 250);"><code class=3D"prettyprint"><div class=3D"subprettyprint"><s=
pan style=3D"color: #008;" class=3D"styled-by-prettify">true</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">inline</span><span style=3D"color:=
#000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #800;" c=
lass=3D"styled-by-prettify">/* if inline function is declared 'true' then i=
t's a pure constant-expression function */</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"><br><br></span><span style=3D"color: #008;"=
class=3D"styled-by-prettify">const</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> </span><a href=3D"http://en.cppreference.com/w/cp=
p/types/type_info"><span style=3D"color: #000;" class=3D"styled-by-prettify=
">std</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify">type_info</sp=
an></a><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><s=
pan style=3D"color: #008;" class=3D"styled-by-prettify">typeid</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"=
color: #008;" class=3D"styled-by-prettify">inline</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;"=
class=3D"styled-by-prettify">class</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> T </span><span style=3D"color: #800;" class=3D"st=
yled-by-prettify">/* constant-expression variable which can be assigned a t=
ype */</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">);</span></di=
v></code></div><div><br></div><div><br></div><div>It would be also nice if =
standard library includes an 'true inline' variant of it's functions (and c=
lasses) - at a different namespace maybe.</div><div><br></div><div>Also for=
the following code we would need an function return-type deduced dynamical=
ly at the time return statement is executed for pure constant expression fu=
nctions. It would be nice if partial type specialization for such deduction=
s is allowed too (for example an array type with automatically deduced numb=
er of elements).</div><div><br></div><div>This will allow us for example re=
ading a file at compile-time like this:</div><div><br></div><div class=3D"p=
rettyprint" style=3D"border: 1px solid rgb(187, 187, 187); word-wrap: break=
-word; background-color: rgb(250, 250, 250);"><code class=3D"prettyprint"><=
div class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-b=
y-prettify">true</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">inl=
ine</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span style=3D"color: #008;" class=3D"styled-by-prettify">auto</span><span=
style=3D"color: #000;" class=3D"styled-by-prettify"> aReadFileAsCharArray<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><sp=
an style=3D"color: #008;" class=3D"styled-by-prettify">const</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">char</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">*</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify">pFileName </span><span style=3D"color: #800;" class=3D"sty=
led-by-prettify">/* implicitly 'inline' */</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br> </span><span style=3D"color: #008;" class=3D"sty=
led-by-prettify">using</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettif=
y">namespace</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> std</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify">_inline</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"c=
olor: #800;" class=3D"styled-by-prettify">//supposing that 'std::_inline' d=
efines all classes and functions from 'std' as constant-expression</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"><br><br><br> =
</span><span style=3D"color: #800;" class=3D"styled-by-prettify">//n=
ote:</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&n=
bsp; </span><span style=3D"color: #800;" class=3D"styled-by-prettify=
">//All below variables are implicitly constant-expression (as if they</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"><br> &nbs=
p; </span><span style=3D"color: #800;" class=3D"styled-by-prettify">//were =
declared 'inline')</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"><br> <br> ifstream iFile</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify">pFileName</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> ios</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify">ate</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">);</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> </span><span style=3D"color: #800;" class=3D"styled-by-prettify">//try op=
ening the file</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"><br> <br> </span><span style=3D"color: #008;"=
class=3D"styled-by-prettify">if</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">(!</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify">iFile</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">.</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
">is_open</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(=
))</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span>=
<span style=3D"color: #800;" class=3D"styled-by-prettify">//in case the fil=
e wasn't opened return null pointer</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"><br> </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">return</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #0=
08;" class=3D"styled-by-prettify">nullptr</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #800;" class=3D"style=
d-by-prettify">//here return-type is 'std::nullptr_t'</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"><br> <br> &nb=
sp; </span><span style=3D"color: #008;" class=3D"styled-by-prettify">auto</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> szFile </sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> iFile</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">.</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify">size</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">();</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> </span><span style=3D"color: #800;" class=3D"s=
tyled-by-prettify">//get file size</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br> <br> array</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify"><</span><span sty=
le=3D"color: #008;" class=3D"styled-by-prettify">int</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> szFile</span><span style=3D"color: #660;"=
class=3D"styled-by-prettify">></span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> chFile</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> </span><span style=3D"color: #800;" class=3D"styled-by-prettif=
y">//create a variable of type 'array<int, szFile>'</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br> &nb=
sp; &=
nbsp; </span><span style=3D"color: #800;" class=3D"styled-by-prettif=
y">//in order to store the file content</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"><br> =
</spa=
n><span style=3D"color: #800;" class=3D"styled-by-prettify">//*note: 'array=
<int, szFile>' is a complete type because 'szFile' is</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"><br> &=
nbsp; =
</span><span style=3D"color: #800;" class=3D"styled-by-prett=
ify">//a constant-expression</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"><br> <br> </span><span style=3D=
"color: #800;" class=3D"styled-by-prettify">//read the file into the array =
and return it</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"><br> <br> iFile</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">.</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify">seekg</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">(</span><span style=3D"color: #066;" class=3D"styled-by=
-prettify">0</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">);</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&n=
bsp; <br> iFile</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">.</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify">read</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
>chFile</span><span style=3D"color: #660;" class=3D"styled-by-prettify">.</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify">data</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">(),</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> szFile</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">);</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br> <br> =
</span><span style=3D"color: #008;" class=3D"styled-by-prettify">return</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> chFile</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"col=
or: #800;" class=3D"styled-by-prettify">//here return type is 'Ttmp' or 'ar=
ray<int, szFile>'</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"><br> &n=
bsp; </span><span style=3D"color: #800;" class=3D"styled-by-prettify"=
>//where 'szFile' is the size of the opened file</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">}</span></div></code></div><br><div><br>In =
the above example I'm using 'std::array' because unfortunately normal ones =
can't be returned.</div><div><br></div><div>Below is an example instance of=
the function:<br><br><div class=3D"prettyprint" style=3D"border: 1px solid=
rgb(187, 187, 187); word-wrap: break-word; background-color: rgb(250, 250,=
250);"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span sty=
le=3D"color: #008;" class=3D"styled-by-prettify">auto</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> aFileContent </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> aReadFileAsCharArray</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"c=
olor: #080;" class=3D"styled-by-prettify">"shader.vert"</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">);</span></div></code></div>=
<span style=3D"color: rgb(0, 0, 0); font-family: monospace; background-colo=
r: rgb(250, 250, 250);"><br></span></div><div><span style=3D"color: rgb(0, =
0, 0); font-family: monospace; background-color: rgb(250, 250, 250);">Here =
'</span><span style=3D"color: rgb(0, 0, 0); font-family: monospace; backgro=
und-color: rgb(250, 250, 250);">aFileContent</span><span style=3D"color: rg=
b(0, 0, 0); font-family: monospace; background-color: rgb(250, 250, 250);">=
' will be of type 'std::</span><span class=3D"styled-by-prettify" style=3D"=
font-family: monospace; color: rgb(0, 0, 0); background-color: rgb(250, 250=
, 250);">_</span><span class=3D"styled-by-prettify" style=3D"font-family: m=
onospace; color: rgb(0, 0, 0); background-color: rgb(250, 250, 250);">inlin=
e</span><span style=3D"color: rgb(0, 0, 0); font-family: monospace; backgro=
und-color: rgb(250, 250, 250);">::array<char, fileSz>' as '</span><sp=
an style=3D"color: rgb(0, 0, 0); font-family: monospace; background-color: =
rgb(250, 250, 250);">fileSz</span><span style=3D"color: rgb(0, 0, 0); font-=
family: monospace; background-color: rgb(250, 250, 250);">' will be the siz=
e of 'shader.vert'.</span></div><div><span style=3D"color: rgb(0, 0, 0); fo=
nt-family: monospace; background-color: rgb(250, 250, 250);"><br></span></d=
iv><div>Of-course you could think of thousands other thing that such tools =
can allow you to do as supposedly all the C++ library will be available to =
you at run-time.</div><div><br></div><div>What do you think?</div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_7876_1017491279.1425576606360--
------=_Part_7875_1270125837.1425576606360--
.
Author: Matthew Woehlke <mw_triad@users.sourceforge.net>
Date: Thu, 05 Mar 2015 16:42:10 -0500
Raw View
On 2015-03-05 12:30, Alexander Nikolov wrote:
> What should the parser need to know in order to execute a function at
> compile-time - it's body and that's what the inline function specifier
> guarantees. So why then we need this new keyword 'constexpr'? Because
> 'inline' is already reserved in variables declaration?? (this is not true)
>
> This implies my first suggestion which is removing 'constexpr' as a keyword
> and instead replacing/merging it with the already existing 'inline' one.
....except that "inline" and "constexpr" really don't mean the same thing.
- 'constexpr' -> (may) evaluate at compile time
- 'inline' -> hoist definition to point(s) of use
An inline function is closer to a preprocessor macro. The concepts are
orthogonal.
> It would be also nice if standard library includes an 'true inline' variant
> of it's functions (and classes) - at a different namespace maybe.
>
> This will allow us for example reading a file at compile-time like this:
Somehow I *really* don't see (non-PP-esque) file I/O as something I want
in constexpr flavors. (That said... have you read the recent thread
"include external file as char[]"?)
Just thinking about the perversion potential of allowing a program to do
arbitrary things to the file system *at compile time* makes me shudder...
--
Matthew
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Matthew Woehlke <mw_triad@users.sourceforge.net>
Date: Thu, 05 Mar 2015 16:46:12 -0500
Raw View
On 2015-03-05 16:42, Matthew Woehlke wrote:
> On 2015-03-05 12:30, Alexander Nikolov wrote:
>> What should the parser need to know in order to execute a function at
>> compile-time - it's body and that's what the inline function specifier
>> guarantees. So why then we need this new keyword 'constexpr'? Because
>> 'inline' is already reserved in variables declaration?? (this is not true)
>>
>> This implies my first suggestion which is removing 'constexpr' as a keyword
>> and instead replacing/merging it with the already existing 'inline' one.
>
> ...except that "inline" and "constexpr" really don't mean the same thing.
>
> - 'constexpr' -> (may) evaluate at compile time
> - 'inline' -> hoist definition to point(s) of use
>
> An inline function is closer to a preprocessor macro. The concepts are
> orthogonal.
Also, in a modern optimizing compiler, the main thing that 'inline'
means is "don't export this as a public symbol" (i.e. to avoid duplicate
symbols when a definition appears in a header that is then included in
multiple TU's), since the compiler's decision to inline or not may have
little to nothing to do with whether or not a function is marked 'inline'.
--
Matthew
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Thu, 5 Mar 2015 23:54:57 +0200
Raw View
On 5 March 2015 at 19:30, Alexander Nikolov <sasho648@mail.bg> wrote:
> What should the parser need to know in order to execute a function at
> compile-time - it's body and that's what the inline function specifier
> guarantees. So why then we need this new keyword 'constexpr'? Because
Inline doesn't guarantee that.
> This implies my first suggestion which is removing 'constexpr' as a keyword
> and instead replacing/merging it with the already existing 'inline' one.
It's far too late for such changes.
> Another thing I noticed is the requirement that before using the 'typeid',
> <typeinfo> should be included and otherwise the program is ill-formed which
> is an absurd for me at least. After-all it is a keyword and in my opinion no
> keyword should depend on such high-level details (is one header included or
> not). I suggest re-implementing this keyword as a function defined in this
> header.
It's far too late for that sort of a change as well.
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Alexander Nikolov <sasho648@mail.bg>
Date: Thu, 5 Mar 2015 14:54:13 -0800 (PST)
Raw View
------=_Part_11_86279623.1425596053664
Content-Type: multipart/alternative;
boundary="----=_Part_12_550162036.1425596053664"
------=_Part_12_550162036.1425596053664
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
=D1=87=D0=B5=D1=82=D0=B2=D1=8A=D1=80=D1=82=D1=8A=D0=BA, 5 =D0=BC=D0=B0=D1=
=80=D1=82 2015 =D0=B3., 23:42:36 UTC+2, Matthew Woehlke =D0=BD=D0=B0=D0=BF=
=D0=B8=D1=81=D0=B0:
>
> On 2015-03-05 12:30, Alexander Nikolov wrote:=20
> > What should the parser need to know in order to execute a function at=
=20
> > compile-time - it's body and that's what the inline function specifier=
=20
> > guarantees. So why then we need this new keyword 'constexpr'? Because=
=20
> > 'inline' is already reserved in variables declaration?? (this is not=20
> true)=20
> >=20
> > This implies my first suggestion which is removing 'constexpr' as a=20
> keyword=20
> > and instead replacing/merging it with the already existing 'inline' one=
..=20
>
> ...except that "inline" and "constexpr" really don't mean the same thing.=
=20
>
> - 'constexpr' -> (may) evaluate at compile time=20
> - 'inline' -> hoist definition to point(s) of use=20
>
> An inline function is closer to a preprocessor macro. The concepts are=20
> orthogonal.=20
>
>
Actually 'constexpr' functions are implicitly 'inline'. Also the things=20
that this keyword adds can be automatically applied for normal inline=20
functions without compatibility lose (if the function content restrictions=
=20
are lifted - which I think is a good idea because they look rather useless=
=20
for me). This could also extend usability of old functions written as=20
'inline' because they could be now used in constant-expressions.
=20
> > It would be also nice if standard library includes an 'true inline'=20
> variant=20
> > of it's functions (and classes) - at a different namespace maybe.=20
> >=20
> > This will allow us for example reading a file at compile-time like this=
:=20
>
> Somehow I *really* don't see (non-PP-esque) file I/O as something I want=
=20
> in constexpr flavors. (That said... have you read the recent thread=20
> "include external file as char[]"?)=20
>
> Just thinking about the perversion potential of allowing a program to do=
=20
> arbitrary things to the file system *at compile time* makes me shudder...=
=20
>
> --=20
> Matthew=20
>
>
You're right but this could be easily fixed by limiting the input/output=20
access of those functions. This can be done by modifying some of the=20
definitions in the possible namespace defined for them ('std::_inline') if=
=20
that was what you meant. Otherwise I think it's a good idea to make=20
meta-programming easier. It would allow many, many things to be done.
--=20
---=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_12_550162036.1425596053664
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>=D1=87=D0=B5=D1=82=D0=B2=D1=8A=D1=80=D1=82=D1=8A=
=D0=BA, 5 =D0=BC=D0=B0=D1=80=D1=82 2015 =D0=B3., 23:42:36 UTC+2, Matthew Wo=
ehlke =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0:<blockquote class=3D"gmail_quote=
" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding=
-left: 1ex;">On 2015-03-05 12:30, Alexander Nikolov wrote:
<br>> What should the parser need to know in order to execute a function=
at=20
<br>> compile-time - it's body and that's what the inline function speci=
fier=20
<br>> guarantees. So why then we need this new keyword 'constexpr'? Beca=
use=20
<br>> 'inline' is already reserved in variables declaration?? (this is n=
ot true)
<br>>=20
<br>> This implies my first suggestion which is removing 'constexpr' as =
a keyword=20
<br>> and instead replacing/merging it with the already existing 'inline=
' one.
<br>
<br>...except that "inline" and "constexpr" really don't mean the same thin=
g.
<br>
<br>- 'constexpr' -> (may) evaluate at compile time
<br>- 'inline' -> hoist definition to point(s) of use
<br>
<br>An inline function is closer to a preprocessor macro. The concepts are
<br>orthogonal.
<br>
<br></blockquote><div><br></div><div>Actually 'constexpr' functions are imp=
licitly 'inline'. Also the things that this keyword adds can be automatical=
ly applied for normal inline functions without compatibility lose (if the f=
unction content restrictions are lifted - which I think is a good idea beca=
use they look rather useless for me). This could also extend usability of o=
ld functions written as 'inline' because they could be now used in constant=
-expressions.</div><div> </div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;">> It would be also nice if standard library includes an 'true inli=
ne' variant=20
<br>> of it's functions (and classes) - at a different namespace maybe.
<br>>=20
<br>> This will allow us for example reading a file at compile-time like=
this:
<br>
<br>Somehow I *really* don't see (non-PP-esque) file I/O as something I wan=
t
<br>in constexpr flavors. (That said... have you read the recent thread
<br>"include external file as char[]"?)
<br>
<br>Just thinking about the perversion potential of allowing a program to d=
o
<br>arbitrary things to the file system *at compile time* makes me shudder.=
...
<br>
<br>--=20
<br>Matthew
<br>
<br></blockquote><div><br></div><div>You're right but this could be easily =
fixed by limiting the input/output access of those functions. This can be d=
one by modifying some of the definitions in the possible namespace defined =
for them ('std::_inline') if that was what you meant. Otherwise I think it'=
s a good idea to make meta-programming easier. It would allow many, many th=
ings to be done.</div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_12_550162036.1425596053664--
------=_Part_11_86279623.1425596053664--
.
Author: Matthew Woehlke <mw_triad@users.sourceforge.net>
Date: Thu, 05 Mar 2015 18:07:03 -0500
Raw View
On 2015-03-05 17:54, Alexander Nikolov wrote:
> Also the things that [the 'constexpr'] keyword adds can be
> automatically applied for normal inline functions without
> compatibility loss
Why limit that to only functions explicitly marked 'inline'? Why not any
function in the same TU that meets the requirements for 'constexpr'?
(Similar to how the compiler may inline even if not asked...)
>>> This will allow us for example reading a file at compile-time like this:
>>
>> Somehow I *really* don't see (non-PP-esque) file I/O as something I want
>> in constexpr flavors. (That said... have you read the recent thread
>> "include external file as char[]"?)
>>
>> Just thinking about the perversion potential of allowing a program to do
>> arbitrary things to the file system *at compile time* makes me shudder...
>
> You're right but this could be easily fixed by limiting the input/output
> access of those functions. This can be done by modifying some of the
> definitions in the possible namespace defined for them ('std::_inline') if
> that was what you meant. Otherwise I think it's a good idea to make
> meta-programming easier. It would allow many, many things to be done.
Why do you need output? (Would you need this *at all* if the "include
external file as char[]" feature were accepted? If so, why? Note, I'm
talking about *file* I/O, not e.g. std::stringstream, which has more
obvious potential usefulness. Not that I'm exactly in love with the
notion of implementing parsers in metaprogramming...)
--
Matthew
--
---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: Alexander Nikolov <sasho648@mail.bg>
Date: Fri, 6 Mar 2015 01:47:21 -0800 (PST)
Raw View
------=_Part_467_1371783716.1425635241760
Content-Type: multipart/alternative;
boundary="----=_Part_468_184480620.1425635241761"
------=_Part_468_184480620.1425635241761
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
=D0=BF=D0=B5=D1=82=D1=8A=D0=BA, 6 =D0=BC=D0=B0=D1=80=D1=82 2015 =D0=B3., 1:=
07:24 UTC+2, Matthew Woehlke =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0:
>
> On 2015-03-05 17:54, Alexander Nikolov wrote:=20
> > Also the things that [the 'constexpr'] keyword adds can be=20
> > automatically applied for normal inline functions without=20
> > compatibility loss=20
>
> Why limit that to only functions explicitly marked 'inline'? Why not any=
=20
> function in the same TU that meets the requirements for 'constexpr'?=20
> (Similar to how the compiler may inline even if not asked...)=20
>
>
I can't tell you that. Why the keyword 'inline' was included?
Maybe some expert could give an opinion on this? But in every case this=20
isn't so important as the ability to write 100% compile-time execution=20
guaranteed code.
=20
> >>> This will allow us for example reading a file at compile-time like=20
> this:=20
> >>=20
> >> Somehow I *really* don't see (non-PP-esque) file I/O as something I=20
> want=20
> >> in constexpr flavors. (That said... have you read the recent thread=20
> >> "include external file as char[]"?)=20
> >>=20
> >> Just thinking about the perversion potential of allowing a program to=
=20
> do=20
> >> arbitrary things to the file system *at compile time* makes me=20
> shudder...=20
> >=20
> > You're right but this could be easily fixed by limiting the input/outpu=
t=20
> > access of those functions. This can be done by modifying some of the=20
> > definitions in the possible namespace defined for them ('std::_inline')=
=20
> if=20
> > that was what you meant. Otherwise I think it's a good idea to make=20
> > meta-programming easier. It would allow many, many things to be done.=
=20
>
> Why do you need output? (Would you need this *at all* if the "include=20
> external file as char[]" feature were accepted? If so, why? Note, I'm=20
> talking about *file* I/O, not e.g. std::stringstream, which has more=20
> obvious potential usefulness. Not that I'm exactly in love with the=20
> notion of implementing parsers in metaprogramming...)=20
>
>
The idea suggested in this thread is using preprocessor which is something=
=20
that ISO C++ committee is trying to get rid off and so am I - because it=20
have no connection with the main language and it's hard to maintain (no=20
type information applied - only text replacing). But this is also something=
=20
that I suppose wouldn't be a problem. Even if we can't open files at=20
compile-time maybe we would be able to manipulate strings and other type of=
=20
objects which will be something too.
=20
--=20
---=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_468_184480620.1425635241761
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>=D0=BF=D0=B5=D1=82=D1=8A=D0=BA, 6 =D0=BC=D0=B0=D1=
=80=D1=82 2015 =D0=B3., 1:07:24 UTC+2, Matthew Woehlke =D0=BD=D0=B0=D0=BF=
=D0=B8=D1=81=D0=B0:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2015-03-=
05 17:54, Alexander Nikolov wrote:
<br>> Also the things that [the 'constexpr'] keyword adds can be
<br>> automatically applied for normal inline functions without
<br>> compatibility loss
<br>
<br>Why limit that to only functions explicitly marked 'inline'? Why not an=
y
<br>function in the same TU that meets the requirements for 'constexpr'?
<br>(Similar to how the compiler may inline even if not asked...)
<br>
<br></blockquote><div><br></div><div>I can't tell you that. Why the keyword=
'inline' was included?</div><div><br></div><div>Maybe some expert could gi=
ve an opinion on this? But in every case this isn't so important as the abi=
lity to write 100% compile-time execution guaranteed code.</div><div> =
</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;">>>> This will a=
llow us for example reading a file at compile-time like this:=20
<br>>>
<br>>> Somehow I *really* don't see (non-PP-esque) file I/O as someth=
ing I want=20
<br>>> in constexpr flavors. (That said... have you read the recent t=
hread=20
<br>>> "include external file as char[]"?)=20
<br>>>
<br>>> Just thinking about the perversion potential of allowing a pro=
gram to do=20
<br>>> arbitrary things to the file system *at compile time* makes me=
shudder...=20
<br>>
<br>> You're right but this could be easily fixed by limiting the input/=
output=20
<br>> access of those functions. This can be done by modifying some of t=
he=20
<br>> definitions in the possible namespace defined for them ('std::_inl=
ine') if=20
<br>> that was what you meant. Otherwise I think it's a good idea to mak=
e=20
<br>> meta-programming easier. It would allow many, many things to be do=
ne.
<br>
<br>Why do you need output? (Would you need this *at all* if the "include
<br>external file as char[]" feature were accepted? If so, why? Note, I'm
<br>talking about *file* I/O, not e.g. std::stringstream, which has more
<br>obvious potential usefulness. Not that I'm exactly in love with the
<br>notion of implementing parsers in metaprogramming...)
<br>
<br></blockquote><div><br></div><div>The idea suggested in this thread is u=
sing preprocessor which is something that ISO C++ committee is trying to ge=
t rid off and so am I - because it have no connection with the main languag=
e and it's hard to maintain (no type information applied - only text replac=
ing). But this is also something that I suppose wouldn't be a problem. Even=
if we can't open files at compile-time maybe we would be able to manipulat=
e strings and other type of objects which will be something too.</div><div>=
</div><div><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_468_184480620.1425635241761--
------=_Part_467_1371783716.1425635241760--
.
Author: Scott Prager <splinterofchaos@gmail.com>
Date: Sat, 7 Mar 2015 13:24:10 -0800 (PST)
Raw View
------=_Part_394_1455012455.1425763450518
Content-Type: multipart/alternative;
boundary="----=_Part_395_998042796.1425763450519"
------=_Part_395_998042796.1425763450519
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Thursday, March 5, 2015 at 5:54:13 PM UTC-5, Alexander Nikolov wrote:
>
>
>
> =D1=87=D0=B5=D1=82=D0=B2=D1=8A=D1=80=D1=82=D1=8A=D0=BA, 5 =D0=BC=D0=B0=D1=
=80=D1=82 2015 =D0=B3., 23:42:36 UTC+2, Matthew Woehlke =D0=BD=D0=B0=D0=BF=
=D0=B8=D1=81=D0=B0:
>>
>>
>> =20
>
>> - 'constexpr' -> (may) evaluate at compile time=20
>> - 'inline' -> hoist definition to point(s) of use=20
>>
>> An inline function is closer to a preprocessor macro. The concepts are=
=20
>> orthogonal.=20
>>
>>
> Actually 'constexpr' functions are implicitly 'inline'.
>
>>
Counter-example:
extern constexpr int f(int);
int main() { }
If evaluated at compile-time, I suppose you could argue that it was inlined=
,
but that's rather philosophical. Does it say anywhere in the standard that
a *constexpr *function is implicitly *inline* as well?
--=20
---=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_395_998042796.1425763450519
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Thursday, March 5, 2015 at 5:54:13 PM UTC-5, Al=
exander Nikolov wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><br><br>=D1=87=D0=B5=D1=82=D0=B2=D1=8A=D1=80=D1=82=D1=8A=D0=BA, 5 =
=D0=BC=D0=B0=D1=80=D1=82 2015 =D0=B3., 23:42:36 UTC+2, Matthew Woehlke =D0=
=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0:<blockquote class=3D"gmail_quote" style=
=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"=
><br></blockquote></div></blockquote><div> </div><blockquote class=3D"=
gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc so=
lid;padding-left: 1ex;"><div dir=3D"ltr"><blockquote class=3D"gmail_quote" =
style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left=
:1ex">
<br>- 'constexpr' -> (may) evaluate at compile time
<br>- 'inline' -> hoist definition to point(s) of use
<br>
<br>An inline function is closer to a preprocessor macro. The concepts are
<br>orthogonal.
<br>
<br></blockquote><div><br></div><div>Actually 'constexpr' functions are imp=
licitly 'inline'.</div><blockquote class=3D"gmail_quote" style=3D"margin:0;=
margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"></blockquote=
></div></blockquote><div><br></div><div>Counter-example:</div><div><div><di=
v class=3D"prettyprint" style=3D"border: 1px solid rgb(187, 187, 187); word=
-wrap: break-word; background-color: rgb(250, 250, 250);"><code class=3D"pr=
ettyprint"><div class=3D"subprettyprint"><span style=3D"color: #008;" class=
=3D"styled-by-prettify">extern</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by=
-prettify">constexpr</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify"=
>int</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> f</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span =
style=3D"color: #008;" class=3D"styled-by-prettify">int</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">);</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">int</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> main</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">()</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span></div>=
</code></div><br></div></div><div>If evaluated at compile-time, I suppose y=
ou could argue that it was inlined,</div><div>but that's rather philosophic=
al. Does it say anywhere in the standard that</div><div>a <i>constexpr </i>=
function is implicitly <i>inline</i> as well?</div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_395_998042796.1425763450519--
------=_Part_394_1455012455.1425763450518--
.
Author: Alexander Nikolov <sasho648@mail.bg>
Date: Sat, 7 Mar 2015 13:42:58 -0800 (PST)
Raw View
------=_Part_551_191347541.1425764578425
Content-Type: multipart/alternative;
boundary="----=_Part_552_1195102028.1425764578425"
------=_Part_552_1195102028.1425764578425
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
=D1=81=D1=8A=D0=B1=D0=BE=D1=82=D0=B0, 7 =D0=BC=D0=B0=D1=80=D1=82 2015 =D0=
=B3., 23:24:10 UTC+2, Scott Prager =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0:
>
>
>
> On Thursday, March 5, 2015 at 5:54:13 PM UTC-5, Alexander Nikolov wrote:
>>
>>
>>
>> =D1=87=D0=B5=D1=82=D0=B2=D1=8A=D1=80=D1=82=D1=8A=D0=BA, 5 =D0=BC=D0=B0=
=D1=80=D1=82 2015 =D0=B3., 23:42:36 UTC+2, Matthew Woehlke =D0=BD=D0=B0=D0=
=BF=D0=B8=D1=81=D0=B0:
>>>
>>>
>>> =20
>
>>
>>> - 'constexpr' -> (may) evaluate at compile time=20
>>> - 'inline' -> hoist definition to point(s) of use=20
>>>
>>> An inline function is closer to a preprocessor macro. The concepts are=
=20
>>> orthogonal.=20
>>>
>>>
>> Actually 'constexpr' functions are implicitly 'inline'.
>>
>>>
> Counter-example:
> extern constexpr int f(int);
> int main() { }
>
> If evaluated at compile-time, I suppose you could argue that it was=20
> inlined,
> but that's rather philosophical. Does it say anywhere in the standard tha=
t
> a *constexpr *function is implicitly *inline* as well?
>
Yes it does actually. Quoting latest ISO C++ draft (n4296) at 7.1.5.2:
A constexpr specifier used in the declaration of a function that is not a=
=20
> constructor declares that function
> to be a constexpr function. Similarly, a constexpr specifier used in a=20
> constructor declaration declares that
> constructor to be a constexpr constructor.=20
> *constexpr functions and constexpr constructors are implicitlyinline*
So your example is equivalent to:=20
extern inline constexpr int f(int);
int main() { }
I believe declaring the constant-expression function 'f' with external=20
linkage was an example intended to show that such functions aren't=20
guaranteed to be defined in the same translation unit and thereof they=20
aren't inline. The above citation clearly showed that this is not true but=
=20
I can also add that 'inline' functions (and thus 'constexpr') can be=20
declared 'extern' and this is well defined in 7.1.2.4:
An inline function shall be defined in every translation unit in which it=
=20
> is odr-used and shall have exactly
> the same definition in every case (3.2). [ Note: A call to the inline=20
> function may be encountered before its
> definition appears in the translation unit. =E2=80=94end note ] If the de=
finition=20
> of a function appears in a translation
> unit before its first declaration as inline, the program is ill-formed. I=
f=20
> a function with external linkage is
> declared inline in one translation unit, it shall be declared inline in=
=20
> all translation units in which it appears;
> no diagnostic is required.=20
> *An inline function with external linkage shall have the same address in=
=20
> all*
> *translation units. A static local variable in an extern inline function=
=20
> always refers to the same object.**A type defined within the body of an=
=20
> extern inline function is the same type in every translation unit.*
--=20
---=20
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 e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
------=_Part_552_1195102028.1425764578425
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>=D1=81=D1=8A=D0=B1=D0=BE=D1=82=D0=B0, 7 =D0=BC=D0=
=B0=D1=80=D1=82 2015 =D0=B3., 23:24:10 UTC+2, Scott Prager =D0=BD=D0=B0=D0=
=BF=D0=B8=D1=81=D0=B0:<blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><br><br>On Thursday, March 5, 2015 at 5:54:13 PM UTC-5, Alexander =
Nikolov wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-le=
ft:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><br>=
<br>=D1=87=D0=B5=D1=82=D0=B2=D1=8A=D1=80=D1=82=D1=8A=D0=BA, 5 =D0=BC=D0=B0=
=D1=80=D1=82 2015 =D0=B3., 23:42:36 UTC+2, Matthew Woehlke =D0=BD=D0=B0=D0=
=BF=D0=B8=D1=81=D0=B0:<blockquote class=3D"gmail_quote" style=3D"margin:0;m=
argin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><br></blockqu=
ote></div></blockquote><div> </div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:=
1ex"><div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin:0;m=
argin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>- 'constexpr' -> (may) evaluate at compile time
<br>- 'inline' -> hoist definition to point(s) of use
<br>
<br>An inline function is closer to a preprocessor macro. The concepts are
<br>orthogonal.
<br>
<br></blockquote><div><br></div><div>Actually 'constexpr' functions are imp=
licitly 'inline'.</div><blockquote class=3D"gmail_quote" style=3D"margin:0;=
margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"></blockquote=
></div></blockquote><div><br></div><div>Counter-example:</div><div><div><di=
v style=3D"border:1px solid rgb(187,187,187);word-wrap:break-word;backgroun=
d-color:rgb(250,250,250)"><code><div><span style=3D"color:#008">extern</spa=
n><span style=3D"color:#000"> </span><span style=3D"color:#008">constexpr</=
span><span style=3D"color:#000"> </span><span style=3D"color:#008">int</spa=
n><span style=3D"color:#000"> f</span><span style=3D"color:#660">(</span><s=
pan style=3D"color:#008">int</span><span style=3D"color:#660">);</span><spa=
n style=3D"color:#000"><br></span><span style=3D"color:#008">int</span><spa=
n style=3D"color:#000"> main</span><span style=3D"color:#660">()</span><spa=
n style=3D"color:#000"> </span><span style=3D"color:#660">{</span><span sty=
le=3D"color:#000"> </span><span style=3D"color:#660">}</span></div></code><=
/div><br></div></div><div>If evaluated at compile-time, I suppose you could=
argue that it was inlined,</div><div>but that's rather philosophical. Does=
it say anywhere in the standard that</div><div>a <i>constexpr </i>function=
is implicitly <i>inline</i> as well?</div></div></blockquote><div><br=
></div><div>Yes it does actually. Quoting latest ISO C++ draft (n4296) at&n=
bsp;7.1.5.2:<br><br><blockquote class=3D"gmail_quote" style=3D"margin: 0px =
0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204=
); border-left-style: solid; padding-left: 1ex;">A constexpr specifier used=
in the declaration of a function that is not a constructor declares that f=
unction<br>to be a constexpr function. Similarly, a constexpr specifier use=
d in a constructor declaration declares that<br>constructor to be a constex=
pr constructor. <b>constexpr functions and constexpr constructors are impli=
citly<br>inline</b></blockquote><div><br></div><div>So your example is equi=
valent to: </div><div><br></div><div><div class=3D"prettyprint" style=
=3D"border: 1px solid rgb(187, 187, 187); word-wrap: break-word; background=
-color: rgb(250, 250, 250);"><code class=3D"prettyprint"><div class=3D"subp=
rettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettify">exter=
n</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><=
span style=3D"color: #008;" class=3D"styled-by-prettify">inline</span><span=
style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D=
"color: #008;" class=3D"styled-by-prettify">constexpr</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #0=
08;" class=3D"styled-by-prettify">int</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> f</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">(</span><span style=3D"color: #008;" class=3D"styled-by-=
prettify">int</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">);</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><=
/span><span style=3D"color: #008;" class=3D"styled-by-prettify">int</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> main</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">()</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">}</span></div></code></div></div><div><br></div><div>I bel=
ieve declaring the constant-expression function 'f' with external linkage w=
as an example intended to show that such functions aren't guaranteed to be =
defined in the same translation unit and thereof they aren't inline. The ab=
ove citation clearly showed that this is not true but I can also add that '=
inline' functions (and thus 'constexpr') can be declared 'extern' and this =
is well defined in 7.1.2.4:</div><div><br><blockquote class=3D"gmail_q=
uote" style=3D"margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-le=
ft-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;"=
>An inline function shall be defined in every translation unit in which it =
is odr-used and shall have exactly<br>the same definition in every case (3.=
2). [ Note: A call to the inline function may be encountered before its<br>=
definition appears in the translation unit. =E2=80=94end note ] If the defi=
nition of a function appears in a translation<br>unit before its first decl=
aration as inline, the program is ill-formed. If a function with external l=
inkage is<br>declared inline in one translation unit, it shall be declared =
inline in all translation units in which it appears;<br>no diagnostic is re=
quired. <b>An inline function with external linkage shall have the same add=
ress in all<br></b><b>translation units. A static local variable in an exte=
rn inline function always refers to the same object.<br></b><b>A type defin=
ed within the body of an extern inline function is the same type in every t=
ranslation unit.</b></blockquote><div><br><br></div></div></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
------=_Part_552_1195102028.1425764578425--
------=_Part_551_191347541.1425764578425--
.