220 15132 <5c8a1dd2-4664-40ac-90fa-65011612d69b@isocpp.org> article Path: news.gmane.org!not-for-mail From: Douglas Boffey Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Inline variables - superior of templates and constexpr. Date: Wed, 17 Dec 2014 06:25:23 -0800 (PST) Lines: 796 Approved: news@gmane.org Message-ID: <5c8a1dd2-4664-40ac-90fa-65011612d69b@isocpp.org> References: <84da1bdc-3356-4c40-a29a-bdd4c0b058b4@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_416_1204189752.1418826323071" X-Trace: ger.gmane.org 1418826331 14519 80.91.229.3 (17 Dec 2014 14:25:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 17 Dec 2014 14:25:31 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDSIZVXVVUFBBU5EY2SAKGQEJVGTNPY@isocpp.org Wed Dec 17 15:25:26 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-oi0-f71.google.com ([209.85.218.71]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Y1FXZ-0004AD-9J for gclcip-std-proposals@m.gmane.org; Wed, 17 Dec 2014 15:25:25 +0100 Original-Received: by mail-oi0-f71.google.com with SMTP id u20sf67059474oif.2 for ; Wed, 17 Dec 2014 06:25:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:message-id:in-reply-to:references: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=De0DZqeKI+Ey3uAKvQu9XRWMq9psrcgKV7NupJwYLiI=; b=KcN5TxK0pafz0d0tA5KNrBXl/DFUwIMfiTPwGzurAwL04w399d+IRSl3+Cc61/nljF zjlXMGmAjo3mp3mZUy1ajcpv95UBl13gPHU891wTdUpj4OzeZyr+4QABeQOCRcdfeqch uBx+uUs1j3UIBvkump9H6RazEtdEpVdo6wLbPnQcMJg0MjKYJ1Yj3y+On8hpS2b2nJi0 6/sp0JoLD3ZfPM0RrVWi8TcQEncYXVxkfIxCclCNdyFN78b79Sa/UkPmyF5KccBcMdkv IEOj87k4TUtrhdvAPJ2hsHFkiWzkgc8xUBJcukC5bbALKm77XApztwk+Znfa78Rf3QgW sqZg== 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:in-reply-to:references :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=De0DZqeKI+Ey3uAKvQu9XRWMq9psrcgKV7NupJwYLiI=; b=R86Oy6ZLvr9zsv/rYsJN4U+AYIEJvGd2w8yeQtpGF3u/st7/8anqyeN0XTz7TUESmK JQF7oZAbXzhlVNLILIzR7nA6kgkulOZhE1ydYo6zLLC6KQZ+lMfp6IzlqLGFV3mTBJQ8 306X2o8RcN/QDvfPJIEJ30bImAECM7a73psCwJR6xcjEw8UNcDVE4UvyWNg77EWV/yaf N836H8IWhD2DOQmVZi28JOxjFzt/AokQTtLiah2l9vZCdDvBwfDQ+aYvvFVNoxbhE/pS 2J/LMr3mg9R2EurUm820rLaG7i0UyeyNZet7zRmy0c+pT2la/GR5GQt0DdGetLWSjD8k MFOQ== X-Gm-Message-State: ALoCoQkazmLGNrcOITdgKputMVglA2BNjKdXnG1E53/HLwVAkKpNRc5GHLbyhx65Ael4KeUZFVal X-Received: by 10.42.22.75 with SMTP id n11mr41007673icb.22.1418826324217; Wed, 17 Dec 2014 06:25:24 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.96.112 with SMTP id j103ls3620447qge.83.gmail; Wed, 17 Dec 2014 06:25:23 -0800 (PST) X-Received: by 10.140.27.197 with SMTP id 63mr391881qgx.6.1418826323424; Wed, 17 Dec 2014 06:25:23 -0800 (PST) In-Reply-To: <84da1bdc-3356-4c40-a29a-bdd4c0b058b4@isocpp.org> X-Original-Sender: Douglas.Boffey@gmail.com 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:15132 Archived-At: ------=_Part_416_1204189752.1418826323071 Content-Type: multipart/alternative; boundary="----=_Part_417_931272536.1418826323071" ------=_Part_417_931272536.1418826323071 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tuesday, 16 December 2014 18:50:46 UTC, sasho648 wrote: > > As the title says - I'm purposing the introduction of a new variables=20 > specifier - 'inline', which will indicate that their value is known at=20 > compile-time. [Literals aren't itself 'inline' variables, so an reference= =20 > to 'inline' variable can't bound to literal.] The motivation of introduci= ng=20 > it is enabling static checks at functions, native 'read-only public' clas= s=20 > member specifiers and creating more optimized code. > > Example of the first one can be given by using 'std::array' if we access= =20 > an object of the type using the 'operator[]' and 'constexpr' with invalid= =20 > index no compiler warning or even an error will be introduced: > > =20 > array arr; > =20 > cout << arr[98] << endl; //compiles just fine > > Life example . > > You'll say - this is too obvious - no one will do such thing but let's=20 > imagine that we are going to access the array element, instead of a=20 > literal, by some constexpr function. > > constexpr int EvaluateSpecialArrayIndex(int a) > { return a * sizeof(int); } > > cout << arr[EvaluateSpecialArrayIndex(4)] << endl; > > Now things get complex, huh? In order to check if the array index is vali= d=20 > we should first multiply by hand 4 * sizeof(int) and compare it with the= =20 > array size. You think now - hey but why don't you add a static_assert in= =20 > the 'EvaluateSpecialArrayIndex' and check 'a' with the array size. But th= e=20 > truth is - that you can't do that as the parameter 'a' isn't required to = be=20 > 'constexpr', neither the return value of the function. Example on valid= =20 > 'constexpr' call with 'lvalue': > > > int a =3D rand() % 4; //lvalue > > cout << arr[EvaluateSpecialArrayIndex(a)] << endl; // also valid > > Life example . > > So this piece of code is invalid: > > constexpr int EvaluateSpecialArrayIndex(int a) > { static_assert( a < 5, "invalid a" ); return a * sizeof(int); } > > > Life example . > > Here is where 'inline' variables came in use. They can be initialized onl= y=20 > once with another 'inline' variable or with literal but aren't 'const' an= d=20 > non-'inline' variables can't be casted to 'inline'. However the opposite = is=20 > possible (casting from 'inline' to any other type). Functions declared wi= th=20 > 'inline' parameters or return-value will be implicit 'inline' themselves.= =20 > Instance to a function with argument literal will first search for one wi= th=20 > parameter of type 'inline '. So now we could overload th= e=20 > 'std::array::operator[]' in order to do static checks on 'inline' variabl= es=20 > like this (supposing that 'templates' are still used): > > template > T & std::array::operator[]( size_type pos ) > > { > static_assert( pos < sz, "invalid array index" ); > > return this->operator[]((int)pos); //instance default 'non-inline'=20 > (run-time) operator[] with 'a' casted (from 'inline int') to 'int' > } > > > By using the above function this invalid code: > > array arr; > =20 > cout << arr[98] << endl; > > Will report compiler error, instead of producing undefined behavior. > > The other usage of the specifier, optimizing code, can be demonstrated by= =20 > creating one general function - for both 'inline' and 'non-inline'=20 > parameters, of certain algorithm and other 2 for 'inline' and 'non-inline= '=20 > which will specialize it, so when you call it with for example literal - = it=20 > will be evaluated at compile-time and when you do with some variable it= =20 > will create code for run-time execution. Example: > > auto SomeAlgo(inline bool bIsInline, typename( bIsInline ? inline int := =20 > int ) n) -> decltype(n) > { > //Do something with 'n' and return 'int' (or 'inline int') > } > =20 > inline int SomeAlgo(inline int a) { static_assert( a < 0, "invalid a" );=20 > return SomeAlgo(true, a); } > > int SomeAlgo(int a) { return SomeAlgo(false, a); } > > *Note that the first function is declared as returning an 'inline int', i= f=20 > it was the function itself to be 'inline', it should be 'int inline=20 > SomeAlgo', which is an inline function returning 'int'.* > > And some example instances of 'SomeAlgo': > > SomeAlgo(rand()); //it will invoke code creation as 'rand()' doesn't=20 > return 'inline' value > > SomeAlgo(9); //Will evaluate at compile-time as literal '9' can be used= =20 > to initialize 'inline' variables > > Another useful feature will be the use of 'inline references' which are= =20 > such that will point at some compiler-known location (nothing special),= =20 > they'll be useful when you want to create a public const reference to som= e=20 > private member in order to allow public read-only access to it. For now w= e=20 > could only write this: > > class A > { > int _a; > > public: > > const int &a =3D _a; > } ; > > Life example . > > But in the case memory for 'a' will be allocated for each 'A' instance,= =20 > which is not a deal. We couldn't write this with 'constexpr' for some=20 > strange reason: > > class A > { > int _a; > > public: > > constexpr int &a =3D _a; // the same as 'const int & constexpr a' -= =20 > still produces error > } ; > > Life example . > > By using our new construct this could write this: > > class A > { > int _a; > > public: > > const int & inline a =3D _a; // inline reference to '_a' > } ; > > Which basically means that each reference to 'a', will be evaluated like = -=20 > '(const int)_a', so no additional memory will be created now. > > Function specialization will be done to functions with 'inline'=20 > parameters, which when receive argument values will search for a function= =20 > which have specialized them. The parameter specialization will be done vi= a=20 > the '=3D=3D' operator (one specialization can be for multiples values). E= xamples > > auto FuncAdd(inline typename T, T a, T b) -> T //general function > { > return a + b; > } > > auto FuncAdd(inline typename T =3D=3D int, T a, T b) -> T //specialized= =20 > function about the 'T' parameter, as no inline params, no implicit 'inlin= e'=20 > conversion > { > cout << "I can deal with int" << endl; > > return a + b; > } > > Am I to understand the =E2=80=9Cinline typename T=E2=80=9D as an alternat= ive method of=20 expressing templates or one function that will work for any type? =20 Firstly, whether or not you want this as a template replacement, I object= =20 to having to specify the type when the compiler can deduce that from the=20 variables. =20 If it is meant as a replacement for a template, having the type as a=20 parameter is confusing=E2=80=A6 I would expect one function, and only one f= unction,=20 to be substantiated when a function is not explicitly templated. =20 If it is not, I am at a loss as to how a compiler is meant to implement it= =20 efficiently (or at all, if it is defined in a separate TU). =20 Regarding the second (overloaded) function, is that supposed to overload on= =20 type int? If so, =E2=80=9Cauto FuncAdd(int, =E2=80=A6=E2=80=9D would be mo= re in line with current=20 practice. This will not create an ambiguity, as the parameter is already= =20 defined as a typename. =20 > And some 'FuncAdd' instances: > > FuncAdd(int, 9, 5); // 'FuncAdd' int specialization called (of type -=20 > 'auto (inline typename T =3D=3D int, T a, T b) -> T') > > FuncAdd(double, 3.14f, 1); // 'FuncAdd' general called (of type - 'auto= =20 > (inline typename T, T a, T b) -> T') > > > Some additional 'inline' specifier rules connected to specialization and= =20 > classes. A class can have special methods for 'inline' instances of it,= =20 > which are defined by specifiying 'inline' after it's declaration (in such= =20 > methods 'this' will be inline pointer and will point to an sequenced=20 > 'inline' array holding it's inline member objects). Inline instances of= =20 > class will instance only it's special 'inline-this' methods and won't=20 > create any memory for it's non-inline members. Classes can't be specializ= ed=20 > but you can create a derived class which specialize their methods. But th= is=20 > could cha > ... --=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_417_931272536.1418826323071 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Tuesday, 16 December 2014 18:50:46 UTC, sasho648 w= rote:
As the title says - I'm = purposing the introduction of a new variables specifier - 'inline', which w= ill indicate that their value is known at compile-time. [Literals aren't it= self 'inline' variables, so an reference to 'inline' variable can't bound t= o literal.] The motivation of introducing it is enabling static checks at f= unctions, native 'read-only public' class member specifiers and creating mo= re optimized code.

Example of the first one can be given by using 's= td::array' if we access an object of the type using the 'operator[]' and 'c= onstexpr' with invalid index no compiler warning or even an error will be i= ntroduced:

    
array<int, 5> arr;
   
c= out << arr[98]= << endl; //compiles just fine
Life example.

<= /div>
You'll say - this is too obvious - no one will do such thing but = let's imagine that we are going to access the array element, instead of a l= iteral, by some constexpr function.

c= onstexpr int EvaluateSpecialArrayIndex(int a)
{ return a * sizeof(int); }<= span style=3D"color: rgb(0, 0, 0);">

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

Now things ge= t complex, huh? In order to check if the array index is valid we should fir= st multiply by hand 4 * sizeof(int) and compare it with the array size. You= think now - hey but why don't you add a static_assert in the 'EvaluateSpec= ialArrayIndex' and check 'a' with the array size. But the truth is - that y= ou can't do that as the parameter 'a' isn't required to be 'constexpr', nei= ther the return value of the function. Example on valid 'constexpr' call wi= th 'lvalue':


int<= /span> a =3D rand() % 4; /= /lvalue

cout << arr[<= span style=3D"color: rgb(102, 0, 102);">EvaluateSpecialArrayIndex(a)] << endl; // also valid<= /div>

Life example.

So this piece of code is in= valid:

constexpr in= t EvaluateSpecialArrayIndex(int<= span style=3D"color: rgb(0, 0, 0);"> a)
{ static_assert( a < 5, "inva= lid a" ); return a * sizeof(int); }

<= br>Life example.

Here is where 'inline' variables came in use. They can be initialized only= once with another 'inline' variable or with literal but aren't 'const' and= non-'inline' variables can't be casted to 'inline'. However the opposite i= s possible (casting from 'inline' to any other type). Functions declared wi= th 'inline' parameters or return-value will be implicit 'inline' themselves= .. Instance to a function with argument literal will first search for one wi= th parameter of type 'inline <type-of-literal>'. So now we could over= load the 'std::array::operator[]' in order to do static checks on 'inline' = variables like this (supposing that 'templates' are still used):

template&l= t;typename T, size_t sz>
T & std::array::operator[]( size_type pos )

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

&= nbsp;   return this->operator[]((int= )pos); //instance default 'non-inline' (run-time) operator[] with 'a' casted = (from 'inline int') to 'int'}

<int, 5&= gt; arr;
&n= bsp;  
cout <&l= t; arr[98<= /span>] <<<= /span> endl;

Will report compiler error, instead of producing undefined beha= vior.

The other usage of the specifier, optimizing= code, can be demonstrated by creating one general function - for both 'inl= ine' and 'non-inline' parameters, of certain algorithm and other 2 for 'inl= ine' and 'non-inline' which will specialize it, so when you call it with fo= r example literal - it will be evaluated at compile-time and when you do wi= th some variable it will create code for run-time execution. Example:
=

autoSomeAlgo(inline bool bIsInline, typename( bIsInline ? inline int : int ) n) = -> decltypen)
{
   
}
 
inline int SomeAlgo(inline<= span style=3D"color: rgb(0, 0, 0);"> int a)= { static_as= sert( a &l= t; 0, "invalid a" <= span style=3D"color: rgb(102, 102, 0);">); return SomeAlgo(true, a); }

int SomeAlgo(int a) { return SomeAlgo(false, a); }

Note that the first function is declared as = returning an 'inline int', if it was the function itself to be 'inline', it= should be 'int inline SomeAlgo', which is an inline function returning 'in= t'.

And some example instances of 'SomeAlgo':

SomeAlg= o(rand());= //it will invoke code creation as 'rand()' doesn't return '= inline' value

SomeAlgo(9); //Will evaluate= at compile-time as literal '9' can be used to initialize 'inline' variable= s

Another useful feature will be the use of 'i= nline references' which are such that will point at some compiler-known loc= ation (nothing special), they'll be useful when you want to create a public= const reference to some private member in order to allow public read-only = access to it. For now we could only write this:

class<= /span> A
{
&nbs= p;   int _a;

public:

    <= /span>const int &a =3D _a;
} ;

Life example.

But in the case memory for 'a' will be allocated for each 'A' instance, wh= ich is not a deal. We couldn't write this with 'constexpr' for some strange= reason:

class A
{
    int _a<= span style=3D"color: rgb(102, 102, 0);">;

public:

    constexpr int &a =3D _a; // the same as 'const int & co= nstexpr a' - still produces error} = ;

Life example.

By using our new construct th= is could write this:

class A
{
    int _a;

public:

    const int & inline a =3D _a; //= inline reference to '_a'
} ;

Which basically mea= ns that each reference to 'a', will be evaluated like - '(const int)_a', so= no additional memory will be created now.

Functio= n specialization will be done to functions with 'inline' parameters, which = when receive argument values will search for a function which have speciali= zed them. The parameter specialization will be done via the '=3D=3D' operat= or (one specialization can be for multiples values). Examples

=
auto FuncAdd(inline typename T, T a, T b) -> = T //general function
{
    = return a + b;
}

auto<= span style=3D"color: rgb(0, 0, 0);"> FuncAdd(inline typename<= span style=3D"color: rgb(0, 0, 0);"> T =3D=3D int, T a,) = -> T //specialized function about the 'T' parameter, as n= o inline params, no implicit 'inline' conversion
{
    cout << "I can deal with= int" <<= endl;

    return a + b;
}

Am I to understand the =E2=80=9Cinline typename T=E2=80=9D as an= alternative method of expressing templates or one function that will = work for any type?
 
Firstly, whether or not you w= ant this as a template replacement, I object to having to specify the type = when the compiler can deduce that from the variables.
 
If it is meant as a replacement for a template, having the type as a = parameter is confusing=E2=80=A6 I would expect one function, and only one f= unction, to be substantiated when a function is not explicitly templated.
 
If it is not, I am at a loss as to how a compiler= is meant to implement it efficiently (or at all, if it is defined in a sep= arate TU).
 
Regarding the second (overloaded) fun= ction, is that supposed to overload on type int?  If so, =E2=80=9Cauto= FuncAdd(int, =E2=80=A6=E2=80=9D would be more in line with current practic= e.  This will not create an ambiguity, as the parameter is already def= ined as a typename.
 
And some 'FuncAdd' instances:

FuncAdd(int, 9, 5); // 'FuncAdd' int specialization called (of type - 'au= to (inline typename T =3D=3D int, T a, T b) -> T')

FuncAdd(double, 3.14f, 1); // 'FuncAdd' general called (of type - 'auto (inline typ= ename T, T a, T b) -> T')

<= br>
Some additional 'inline' specifier rules connected to special= ization and classes. A class can have special methods for 'inline' instance= s of it, which are defined by specifiying 'inline' after it's declaration (= in such methods 'this' will be inline pointer and will point to an sequence= d 'inline'  array holding it's inline member objects). Inline instance= s of class will instance only it's special 'inline-this' methods and won't = create any memory for it's non-inline members. Classes can't be specialized= but you can create a derived class which specialize their methods. But thi= s could cha
...

--

---
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_417_931272536.1418826323071-- ------=_Part_416_1204189752.1418826323071-- .