220 15139 <9bfdbffd-c89b-4ce1-a5e7-d679c81842c8@isocpp.org> article Path: news.gmane.org!not-for-mail From: sasho648 Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Inline variables - superior of templates and constexpr. Date: Tue, 16 Dec 2014 05:40:01 -0800 (PST) Lines: 1135 Approved: news@gmane.org Message-ID: <9bfdbffd-c89b-4ce1-a5e7-d679c81842c8@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_270_847709593.1418737201599" X-Trace: ger.gmane.org 1418877580 14441 80.91.229.3 (18 Dec 2014 04:39:40 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 18 Dec 2014 04:39:40 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDBNZXHN2QPRBBFVZGSAKGQEQJ2ZITY@isocpp.org Thu Dec 18 05:39:35 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ie0-f199.google.com ([209.85.223.199]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Y1SsA-0004Xs-B1 for gclcip-std-proposals@m.gmane.org; Thu, 18 Dec 2014 05:39:34 +0100 Original-Received: by mail-ie0-f199.google.com with SMTP id rp18sf1662544iec.2 for ; Wed, 17 Dec 2014 20:39:33 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:message-id:subject:mime-version :content-type:x-original-sender:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe; bh=74PR63vhXISBjazWobhp163OLPx4rKdKiBMwtr4JfvA=; b=Hj2oH1Eu7UJ/K4NILilW4qIjYxZp/Fz669lNV+hcxGUSQJQ/XhHaIsUjP9DOLJIIKw qc1KLOEqF8mfJHt9kCZFTJOUymjHPqlhTFRDLjmpfhzdmrfCq+/GK95LFpzTP5gPqKWx SO68bVOA2Ai/iKtBMM+CViAohdw3TjoiYDYKhBggZhd88Cb3bLeVzNGau0R3+T5fezzx DsR6AlDWBMKTUXB3NcTAJs34ZiBOE1c2nIzqKyPdTqm08g8M7LTIH1RBXSFqHrCuEtgd kIRv1+cLAsoUjLMuJ9v1TagVLx/ncJ5lwqPjNtVV7l5Y6NBRd2WyCCn7r5oLXrWRxIfD FZLQ== X-Gm-Message-State: ALoCoQkHhGgXD2DLACBN6ASXlmwNOC2OYT+QC7NjGUpACusHfwyeRJqMsTSjXS0ZyEoViDeToRFi X-Received: by 10.50.221.104 with SMTP id qd8mr743402igc.0.1418877573374; Wed, 17 Dec 2014 20:39:33 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.37.85 with SMTP id q79ls4025474qgq.34.gmail; Wed, 17 Dec 2014 20:39:32 -0800 (PST) X-Received: by 10.236.20.116 with SMTP id o80mr100752yho.45.1418877572720; Wed, 17 Dec 2014 20:39:32 -0800 (PST) Original-Received: by 10.224.163.71 with SMTP id z7msqax; Tue, 16 Dec 2014 05:40:02 -0800 (PST) X-Received: by 10.140.37.104 with SMTP id q95mr3245qgq.36.1418737201954; Tue, 16 Dec 2014 05:40:01 -0800 (PST) X-Original-Sender: sasho648@mail.bg Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:15139 Archived-At: ------=_Part_270_847709593.1418737201599 Content-Type: multipart/alternative; boundary="----=_Part_271_1048615353.1418737201599" ------=_Part_271_1048615353.1418737201599 Content-Type: text/plain; charset=UTF-8 'Constexpr' are very bad idea as they introduce a new keyword only to tell us that certain functions MAY be evaluated at compile-time (but also may not). Also 'constexpr' can be only whole functions and not different arguments, or only return-value (which would be twice more-useful). My new construct could deprecated templates too. The idea is simple, variables, references or pointers declared as 'inline' can be constructed only once with other 'inline' variables. As 'inline' variable is a compiler-time known constant (can't be edited). Function with inline return value or arguments will be implicitly inline themselves. Inline classes specify that each of their members are inline (including functions), contain no virtual methods and 'this' is an inline pointer. If a class-constructor modify it's members types or size using inline variables known only at instance of it, then this class creates an incomplete type, which depending on it's construction way will create different classes. If a function return or arguments type depends on other arguments, then the function is of incomplete type, which depends on them and each will form the actual type. Conversion from 'inline' to any other type is possible but not the opposite (you can't cast to 'inline'). The main motivation for creating this new behavior for 'inline' keyword is enabling static checks for function arguments and also creating more optimized code which will calculate inline variables at compile-time and other ones at run-time. Examples of the first: If we have an 'std::array', declared like this: std::array arr And we instance it like that: cout << arr[86] << endl; Life example . It will compile just fine and produce an run-time error! You'll say who will write this stupid code anyway but imagine that '86' is actually a call to 'constexpr' and we have the following code: constexpr int EvaluateSpecialArrayIndex(int a) { return a * sizeof(int); } //cout array like this cout << arr[EvaluateSpecialArrayIndex(4)] << endl; Life example . You'll think now - hey but I could write a static_assert in the above function to check if it's in array bounds but you are deadly wrong, 'int a' is not a 'constexpr' to write a static_assert - you are amazed now - how it is not a 'constexpr' as the function should be evaluated at compile-time but the truth is that this is not a rule, we could instance 'EvaluateSpecialArrayIndex' fully legally with 'lvalue' also, 'constexpr' functions MAY be evaluated at run-time but MAY not (which depends on where are they instanced - if they should store their return-value into constexpr as in the above example, they are evaluated at compile time otherwise at run-time so the function should suppose that the arguments are 'lvalues') : int a; //'lvalue' cout << EvaluateSpecialArrayIndex(a) << endl; Life example . So this is code is wrong: constexpr int EvaluateSpecialArrayIndex(int a) { static_assert( a < 5, "a should be < 5"); return a * sizeof(int); } Life example . If my suggestion is accepted we could overload std::array for inline values as following (supposing templates are still used): template T & std::array::operator[]( inline size_type pos ) { static_assert( pos < sz, "invalid array index"); return this->operator[]((size_type)pos); //cast from 'inline size_type' to 'size_type' in order to instance 'operator[]' for 'lvalues' } And when 'inline' (or compiler known) index is accessed in array - compiler error will arise and so in the previous examples, this: cout << arr[EvaluateSpecialArrayIndex(4)] << endl; will cause an compiler error. As I said it will also allow program explicit optimizations like for example the fibonacci algorithm series: auto fibonacci_general(auto n) -> decltype(n) { if (n == 0) { return 0; } else if (n == 1) { return 1; } return fibonacci(n-1) + fibonacci(n-2); } int fibonacci(int n) { return fibonacci_general(n); } //creates and instance 'fibonacci_general' with lvalues ('int') inline int fibonacci(inline int n) { static_assert( n < 0, "invalid parameter"); return fibonacci_general(n); } //validates param 'n', creates and instance 'fibonacci_general' with inline values ('inline int') Now in the above code, depending on the value type called, the 'fibonacci' function will be either evaluated at compile-time or generated code for run-time execution. Examples: int n; fibonacci(n); //as 'n' is 'lvalue' fibonacci will be called at run-time fibonacci(90); //as 'inline int' is passed 'fibonacci' will be evaluated at run-time Next I'll show why 'inline' variables are the superior of templates. Imagine you have a class and you want one of it's member to be have public read-only access and private read-write one. For now you could achieve this only by using get/setters which are not ideal (you should always write and call them fro every member which is additional hassle). You could write this: class A { int _a; public: const int &a = _a; } ; Unfortunately the above construct will always require additional sizeof(const int &) bytes in order to store the reference, no matter it will always refer the same object. Life example . We can not optimize this by using templates as they don't know anything about the 'A' members. The most equivalent code will look something like this: template class A { int _a; } ; Which of-course is illegal, the same applies for 'constexpr': class A { int _a; public: constexpr int &a = _a; // the same as int & constexpr a = _a; } ; By using my construct this could be re-written like this: class A { int _a; public: int & inline a = _a; // 'a' is now by default an 'inline reference' to '_a' } ; And so now as '_a' is an inline reference all instances of 'a' will be replaced with something similar to '(const int)obj._a' and no run-time memory will be allocated. As 'inline' will fully replace 'template''s we should talk about 'inline' functions and classes specializations. Every function which parameters and return value types depends on other inline arguments can be specialize in another function. Examples: func_add(inline typename T, T a, T b) -> T { } //'func_add' general inline function func_add(inline typename T == int, T a, T b) -> T { }//'func_add' specialization for int's - it doesn't have inline arguments or return-value so it's not implicitly converted into inline Note the syntax - function specialization of argument will be done by using the equal sign '==' And several example instances of 'func_add': func_add(double, 3.14, 2); //will instance inline function func_add(int, 3, 2); //will instance the specialized 'int' function (note that the '==' is different than the '=' and we can not left the first argument position with no value) And the word is given to 'class' specializations. A class will be specialized after it's 'inline' constructor ends execution. Object being constructed using inline constructor, if when executed an specialization of the class is found it's constructor will be instanced too. Specialization of inline class members will be done using the 'equal' sign as the arguments. Example: class A //general class { T(inline typename arg) : T(arg) {} inline typename T; T data; } ; class A //specialized class for int's { T(int arg) : data(arg) { cout << data << endl; } inline typename T == int; T data; } ; And if we instance an object with some int like this for example: A obj(9); This will happen - 'T(inline typename arg)' will be instanced, creating an 'class A' specialization with 'int', compiler will search if there exist and if so it'll start using it's functionality and thus call 'T(int arg)' and 'cout' 9, Now some of you will ask - so every specialization will have the same type. No that's not true. In the above example class 'A' is from type 'decltype(A(int{}))' but also from type 'A', so if there is a function using it, they could either be general for all 'A''s or only for the 'A''s with member 'T' of type 'int' like this: void Func(A obj); //general function for objects of type 'A' thus inline void Func(decltype(A(int{})) obj); //function of objects with specialized 'A' type which left no inline members so function is not inline The same applies for functions. Examples of function 'func_add': void Func(decltype(func_add) &obj); //general function with argument of type 'auto (&)(inline typename T, T a, T b) -> T', as include inline members function implicit inline void Func(decltype(func_add(int, int(), int())) &obj); //function with argument of type 'auto (&)(inline typename T == int, T a, T b) -> T', no inline so function isn't implicit inline I believe this wasn't the clearest wrote of my life but I also believe you got the point and the benefits of including this syntax. -- --- 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_271_1048615353.1418737201599 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
'Constexpr' are very bad idea as they introduce a new= keyword only to tell us that certain functions MAY be evaluated at compile= -time (but also may not). Also 'constexpr' can be only whole functions and = not different arguments, or only return-value (which would be twice more-us= eful). My new construct could deprecated templates too.

The idea is simple, variables, references or pointers declared as 'in= line' can be constructed only once with other 'inline' variables. As 'inlin= e' variable is a compiler-time known constant (can't be edited). Function w= ith inline return value or arguments will be implicitly inline themselves. = Inline classes specify that each of their members are inline (including fun= ctions), contain no virtual methods and 'this' is an inline pointer. If a c= lass-constructor modify it's members types or size using inline variables k= nown only at instance of it, then this class creates an incomplete type, wh= ich depending on it's construction way will create different classes. If a = function return or arguments type depends on other arguments, then the func= tion is of incomplete type, which depends on them and each will form the ac= tual type. Conversion from 'inline' to any other type is possible but not t= he opposite (you can't cast to 'inline').

The main motivation for cr= eating this new behavior for 'inline' keyword is enabling static checks for= function arguments and also creating more optimized code which will calcul= ate inline variables at compile-time and other ones at run-time. Examples o= f the first:

If we have an 'std::array', declared like this:

=
std::array<int, 5> arr

And w= e instance it like that:

cout <= span style=3D"color: #660;" class=3D"styled-by-prettify"><< arr[86] << endl;

<= /div>Life e= xample.

It will compile just fine and produce an run-time= error! You'll say who will write this stupid code anyway but imagine that = '86' is actually a call to 'constexpr' and we have the following code:
<= br>
constexpr int EvaluateSpecialArrayIndex(int a)
{ return a * sizeof(int); }

//cout array like this

cout <= span style=3D"color: #660;" class=3D"styled-by-prettify"><< arr[EvaluateSpecialArrayIndex(4)] << endl;

Life = example.

You'll think now - hey but I could wr= ite a static_assert in the above function to check if it's in array bounds = but you are deadly wrong, 'int a' is not a 'constexpr' to write a static_as= sert - you are amazed now - how it is not a 'constexpr' as the function sho= uld be evaluated at compile-time but the truth is that this is not a rule, = we could instance 'EvaluateSpecialArrayIndex' fully legally with 'lvalue' a= lso, 'constexpr' functions MAY be evaluated at run-time but MAY not (which = depends on where are they instanced - if they should store their return-val= ue into constexpr as in the above example, they are evaluated at compile ti= me otherwise at run-time so the function should suppose that the arguments = are 'lvalues') :

int a; //'lvalue'

cout << EvaluateSpecialArrayIndex(a) << endl;


Life example.

So this is code is wrong:

constexp= r <= span style=3D"color: #008;" class=3D"styled-by-prettify">int EvaluateSpecialArrayIndex(int a)
{ = static_assert( a < 5, "a should be < 5"); return a * sizeof<= span style=3D"color: #660;" class=3D"styled-by-prettify">(int); }

Life example.

If my suggestion is accepted we could overload std::array for = inline values as following (supposing templates are still used):

template<typename T, size_t sz>
T &am= p; std::array::operator[]( inline size_type pos )

{
    static_assert( pos < sz<= /span>, "invalid array index"= );

    return= this->operator[]((size_type)pos); //ca= st from 'inline size_type' to 'size_type' in order to instance 'operator[]'= for 'lvalues'
}<= /span>

And when 'inline' (or compiler kn= own) index is accessed in array - compiler error will arise and so in the p= revious examples, this:

= cout << arr[EvaluateSpecialArrayIndex(4)] << endl;

will cause an compiler error.

=
As I said it will also allow program explicit optimizations like= for example the fibonacci algorithm series:

auto fibonacci_general(auto n) -> decltype(n) {
 if<= /span> (n =3D=3D 0)
 {<= br> r= eturn 0;
 }
 else if (n =3D=3D<= span style=3D"color: #000;" class=3D"styled-by-prettify"> 1)
 {
 return 1;=
 = }
 
 = ;return fibonacci(n-1) + = fibonacci(= n-2);
}

int fibonacci(int= n<= span style=3D"color: #660;" class=3D"styled-by-prettify">) { return fibonacci_general(n); = } //creates and instance 'fibo= nacci_general' with lvalues ('int')

inline int fibonacci(inlin= e <= span style=3D"color: #008;" class=3D"styled-by-prettify">int n) { static_assert(= n < 0, "invalid parameter"); return fibonacci_general(n); <= /span>} //validates param 'n', creat= es and instance 'fibonacci_general' with inline values ('inline int')

Now in the above= code, depending on the value type called, the 'fibonacci' function will be either evaluated at compile= -time or generated code for run-time execution. Examples:


int n;

fibonacci(n)= ; <= span style=3D"color: #800;" class=3D"styled-by-prettify">//as 'n' is 'lvalu= e' fibonacci will be called at run-time

fibonacci(90); //as 'inline int' is passed 'fibonacci' will be evaluated at run-time

Ne= xt I'll show why 'inline' variables are the superior of templates. Imagine = you have a class and you want one of it's member to be have public read-onl= y access and private read-write one. For now you could achieve this only by= using get/setters which are not ideal (you should always write and call th= em fro every member which is additional hassle). You could write this:
<= br>
class A
{
int _a;<= /span>

public= :

const int &a =3D _a= ;
} ;

<= div>Unfortunately the above construct will always require additional sizeof= (const int &) bytes in order to store the reference, no matter it will = always refer the same object.

Life example. 

We can not optimize this by using templates as they don't= know anything about the 'A' members. The most equivalent code will look so= mething like this:

template<public: const int &= a <= span style=3D"color: #660;" class=3D"styled-by-prettify">=3D _a>
class A
{
int _a;
} ;

Which of-course i= s illegal, the same applies for 'constexpr':

class A
{
    int _a= ;

<= /span>public:

    constexpr int &a =3D _a; // the = same as int & constexpr a =3D _a;=
} ;

By using my construct this coul= d be re-written like this:

class A
{
    int _a;

public:

    int & inl= ine a =3D _a; // 'a' is now by default an 'inline reference'= to '_a'}= ;

An= d so now as '_a' is an inline reference all instances of 'a' will be replac= ed with something similar to '(const int)obj._a' and no run-time memory will be allocated.

= As 'inline' will fully replace 'template''s we should talk about 'inline' f= unctions and classes specializations. Every function which parameters and r= eturn value types depends on other inline arguments can be specialize in another fun= ction. Examples:

func_add= (inline typename T, T a, T b) -> T
{
} //'func_add' general inline function

func_add(inline typename T =3D=3D int,= T a, T b) -> T
{

}//'= func_add' specialization for int's - it doesn't have inline arguments or re= turn-value so it's not implicitly converted into inline
=

<= /div>

Note the syntax - function specialization of&nbs= p;argument will be done by using the equal sign '=3D=3D'

And several= example instances of 'func_add':

func_add= (double, 3.14, 2);<= /span> //will instance inli= ne function

func_add(in= t,<= span style=3D"color: #000;" class=3D"styled-by-prettify"> 3, 2); //wil= l instance the specialized 'int' function (note that the '=3D=3D' is differ= ent than the '=3D' and we can not left the first argument position with no = value)


And the word is given to 'class' specializations. A class will = be specialized after it's 'inline' constructor ends execution. Object being= constructed using inline constructor, if when executed an specializat= ion of the class is found it's constructor will be instanced too. Spec= ialization of inline class members will be done using the 'equal' sign as t= he arguments. Example:

cl= ass A //general clas= s
{
    T(inline typename arg) : T(arg) {}

    inline typename T;

    T data;
} ;


class= A //specialized class for = int's
<= /span>{
    T<= /span>(int arg) : data(arg) { cout << data << endl; }
    inline typ= ename T =3D=3D int;

    T data;
} ;


=

And if we instance an object with some int like this for examp= le:


A obj(9);

This will happen - 'T(inline typename arg)'= will be instanced, creating an 'class A' specialization with 'int', compil= er will search if there exist and if so it'll start using it's functio= nality and thus call 'T(int arg)'  and 'cout' = 9,

Now some of you will ask = - so every specialization will have the same type. No that's not true. In t= he above example class 'A' is from type 'decltype(A(int{}))' but als= o from type 'A', so if there is a function using it, they could either be g= eneral for all 'A''s or only for the 'A''s with member 'T' of type 'int' li= ke this:

void Func(A obj); //gener= al function for objects of type 'A' thus inline
void Func(decltype(A(int{})) obj); //function of objects with specialized 'A' type wh= ich left no inline members so function is not inline

The same applies for functions. Examples of function 'func_add':
void<= /span> Func(decltype(func_add) &obj);<= /span> //general function w= ith argument of type 'auto (&)(inline typename T, T a, T b) -> T', a= s include inline members function implicit inline



void Func(decltype(func_add(int, int(), int())) &a= mp;obj); //function with argument of typ= e  'auto (&)(inline typename T =3D=3D int, T a, T b) -> T', no = inline so function isn't implicit inline
I believe th= is wasn't the clearest wrote of my life but I also believe you got the poin= t and the benefits of including this syntax.
=

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/<= /a>.
------=_Part_271_1048615353.1418737201599-- ------=_Part_270_847709593.1418737201599-- .