220 13001 article Path: news.gmane.org!not-for-mail From: TONGARI J Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Compile-time static `std::integral_counter` Date: Fri, 19 Sep 2014 22:07:16 +0800 Lines: 450 Approved: news@gmane.org Message-ID: References: <9a0bde7b-2f0a-4a5b-92a4-88d5e8df7ea9@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=20cf30223fc75cb59f05036b9e02 X-Trace: ger.gmane.org 1411135653 6939 80.91.229.3 (19 Sep 2014 14:07:33 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 19 Sep 2014 14:07:33 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCC3NA775MLBBHHR6CQAKGQENGDM3SA@isocpp.org Fri Sep 19 16:07:26 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ig0-f200.google.com ([209.85.213.200]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XUyqL-0004d6-Jn for gclcip-std-proposals@m.gmane.org; Fri, 19 Sep 2014 16:07:26 +0200 Original-Received: by mail-ig0-f200.google.com with SMTP id hn15sf14250109igb.7 for ; Fri, 19 Sep 2014 07:07:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe:content-type; bh=q7QzHCyH06L9+LznRBCjvYkwnXA6yARc4Ujpmtwg9Ok=; b=D5J28eT3UB5JXN72haUIqcv+siKlTxSMezPMMdCjlDl5kBTShWLBdGuc2ojXSBeFoD N3TmDR6GhPBVSMCcfv13UfywBm7JqfysCAGDxvpgnxlpaeMrlaKn81+qi6Ip2ouKyuy+ hIvAgfXLy6NUlO+TmG11PTiFHnM7di9SpMqoddTE5Pu6dmeTBRnWSWGqsJM5ADVNvoE6 lxJHpcY7W/Wb6jTVBzhHgrEXZPm9ivYp3upELEtBTBzS11wMrrxATd0WqzbdJobc28rd YvUkWL1Xx6t8NWwkI/tLrBo+Zqz0w0BAPWbupxhBjuNbz2UTeuW3/sscHszAs+33dP2V 5ZfQ== X-Gm-Message-State: ALoCoQkCMhFhxG2K0eBvIRQ79Dgc/RfL2r7nUNmB05/MuEvnwxJx08RTp0RSgz/KrY4ypz9Wr6r1 X-Received: by 10.50.47.10 with SMTP id z10mr2790133igm.0.1411135644760; Fri, 19 Sep 2014 07:07:24 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.43.135 with SMTP id w7ls479951igl.28.gmail; Fri, 19 Sep 2014 07:07:23 -0700 (PDT) X-Received: by 10.42.207.68 with SMTP id fx4mr1260336icb.67.1411135642842; Fri, 19 Sep 2014 07:07:22 -0700 (PDT) Original-Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [2607:f8b0:4001:c03::235]) by mx.google.com with ESMTPS id qo6si1752026igb.23.2014.09.19.07.07.22 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 19 Sep 2014 07:07:22 -0700 (PDT) Received-SPF: pass (google.com: domain of tongari95@gmail.com designates 2607:f8b0:4001:c03::235 as permitted sender) client-ip=2607:f8b0:4001:c03::235; Original-Received: by mail-ie0-f181.google.com with SMTP id tr6so3491513ieb.12 for ; Fri, 19 Sep 2014 07:07:22 -0700 (PDT) X-Received: by 10.42.86.145 with SMTP id u17mr1472837icl.20.1411135636807; Fri, 19 Sep 2014 07:07:16 -0700 (PDT) Original-Received: by 10.42.99.84 with HTTP; Fri, 19 Sep 2014 07:07:16 -0700 (PDT) In-Reply-To: <9a0bde7b-2f0a-4a5b-92a4-88d5e8df7ea9@isocpp.org> X-Original-Sender: tongari95@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of tongari95@gmail.com designates 2607:f8b0:4001:c03::235 as permitted sender) smtp.mail=tongari95@gmail.com; dkim=pass header.i=@gmail.com; dmarc=pass (p=NONE dis=NONE) header.from=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:13001 Archived-At: --20cf30223fc75cb59f05036b9e02 Content-Type: text/plain; charset=UTF-8 2014-09-19 21:42 GMT+08:00 Vittorio Romeo : > *Introduction* > There have been many occasions in my games/libraries where I need to > assign a *`0..n` *compile-time integer to a series of types. Here are two > examples: > > - In one of my component-based entity management systems, I assign an > *`std::bitset`* to every entity, where every bit corresponds to a > specific component type. > - One of my polymorphic memory management/recycling classes stores > several "chunks" of allocated memory for specific types that are part of > the same hierarchy. > To quickly retrieve the chunks, they're stored in a contiguous array. > Every index of the array corresponds to a chunk of a specific type. > > The problem here is assigning an unique integer, starting from zero, to a > specific type, and maintaining it throughout the whole program. This > requires keeping track of the last used integer. > > > > *Current solution/workaround* > Sacrificing performance, it is currently possible to achieve what I > described above. Not at compile-time, but at run-time instead. > > // Statically store the last used global unique id. > inline int getLastId() noexcept > { > static int lastId{0}; > return lastId++; > } > > // Statically store an unique id for a specific type `T`. > template int getIdForType() noexcept > { > static int id{getLastId()}; > return id; > } > > struct TypeA { }; > struct TypeB { }; > struct TypeC { }; > > int main() > { > // Whenever `getIdForType()` gets instantiated, > // an unique id is "bound" to `T` for the rest of the program. > > std::cout << getIdForType() << std::endl; // Prints '0' > std::cout << getIdForType() << std::endl; // Prints '1' > std::cout << getIdForType() << std::endl; // Prints '2' > > return 0; > } > > The workaround allows me to implement the aforementioned examples. > However, it requires *`static`* storage for something that could be > determined at compile-time. > It also requires overhead to access this storage every time we need to get > a type's unique id. > > > > *Possible proposal* > Implement a stateful compile-time *`std::integral_counter` *class that > somehow *(compiler magic?) *remembers its value. > > // We need to "store" a counter during compile-time. > // A new keyword/contextual keyword combination is probably required for > this. > > // We basically "allocate" memory for this counter during compilation and > // use the counter during compilation. The counter should not exist anymore > // at run-time (or be accessible at run-time). > > static template std::integral_counter lastIdCounter; > // ____________ _____________________ ___ _ _____________ > // | | | | L name > // L contextual keyword combination | | > // | | L counter starting value > // L type L counter value type > > // Everything is done at compile-time. Constexpr should work, but also > using > // `std::integral_constant` with a template struct. > template constexpr int getIdForType() noexcept > { > constexpr int id{lastIdCounter::value}; // Get the compile-time > counter's current value > lastIdCounter::increment(); // Increment the compile-time counter - > it will remember its last value > return id; > } > > int main() > { > // Whenever `getIdForType()` gets called with a certain `T`, a > value from > // the compile-time counter is "bound" to that `T` for the rest of > the program. > // Since it is `constexpr` and evaluated at compile-time, there's no > need to store > // the id anywhere in memory - calling the `getIdForType()` > function can > // basically be thought of as replacing `getIdForType()` with a > constant > // at compile time. > > std::cout << getIdForType() << std::endl; // Prints '0' > std::cout << getIdForType() << std::endl; // Prints '1' > std::cout << getIdForType() << std::endl; // Prints '2' > > return 0; > } > > > > Thoughts? > What motivated me to write this post is the fact that we have all > necessary information at compile-time to assign an unique constant id to a > specific type - but there (apparently) is no way of doing so. > Q: What happens if used in different TUs? // in file a.cpp std::cout << getIdForType() << std::endl; // Prints '0' std::cout << getIdForType() << std::endl; // Prints '1' std::cout << getIdForType() << std::endl; // Prints '2' // in file b.cpp std::cout << getIdForType() << std::endl; // Prints '0' std::cout << getIdForType() << std::endl; // Prints '1' std::cout << getIdForType() << std::endl; // Prints '2' Is that the expected result? -- --- 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/. --20cf30223fc75cb59f05036b9e02 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
2014= -09-19 21:42 GMT+08:00 Vittorio Romeo <vittorio.romeo.vee@gmail= ..com>:
= Introduction
There have been many occasions in my g= ames/libraries where I need to assign a `0..n` compile-time integer to a series of types. Here are two e= xamples:
  • In one of my component-based entity management systems, I assi= gn an `std::bitset`=C2=A0to every entity, where every bit correspond= s to a specific component type.
  • One of my polymorphic memory management/recycling classes stores sev= eral "chunks" of allocated memory for specific types that are par= t of the same hierarchy.
    To quickly retrieve the chunks, they're st= ored in a contiguous array. Every index of the array corresponds to a chunk= of a specific type.
The pro= blem here is assigning an unique integer, starting from zero, to a specific= type, and maintaining it throughout the whole program. This requires keepi= ng track of the last used integer.

=


Cu= rrent solution/workaround
Sacri= ficing performance, it is currently possible to achieve what I described ab= ove. Not at compile-time, but at run-time instead.

// Statically store th= e last used global unique id.
inline int getLastId() noexcept
{
=C2= =A0 =C2=A0static int lastId{0};
=C2= =A0 =C2=A0return lastId+= +;
}

// Statically store an unique id for a speci= fic type `T`.
template<typename T> int getIdForType() no= except
{
=C2=A0 =C2=A0 static int id<= span style=3D"color:rgb(102,102,0)">{getLastId()};
=C2=A0 =C2=A0 return id;
}

struct Ty= peA { };
struct TypeB { };struct TypeC { };

int main()<= /span>
{
=C2=A0 =C2=A0 // Whenever `getIdForType<T>()`= gets instantiated,
=C2=A0 =C2= =A0 // an unique id is "boun= d" to `T` for the rest of the program.

=C2=A0 =C2=A0 std::cout << getIdFor= Type<TypeA>(= ) << std::e= ndl; // Prints '0= 9;
=C2=A0 =C2=A0 std::cout << getIdF= orType<TypeB>= ;() << std::endl; // Prints '1&= #39;
=C2=A0 =C2=A0 std::cout << getIdForType<TypeC>() <= /span><< std::endl; // Prints '2'<= br>
=C2= =A0 =C2=A0 return 0;
}
<= /code>

The workaround allows me to implement the aforementioned ex= amples. However, it requires `static` storage for something that cou= ld be determined at compile-time.=C2=A0
It also requires overhead to access this storage every time we need to get= a type's unique id.



Possible proposal
Implemen= t a stateful compile-time=C2=A0`std::integral_counter` class that so= mehow (compiler magic?) remembers its value.

// We need to "store" a counter during compile-time.
= // A new keyword/contextual keyword combination is probably required for th= is.

// We basically "allocate" memory for this coun= ter during compilation and
// use the counter during compilation.= The counter should not exist anymore
// at run-time (or be acces= sible at run-time).

<= span style=3D"color:rgb(0,0,136)">static template std::integral_counter<int, 0> lastIdCou= nter;
// ____________= _____________________ ___ =C2=A0_ =C2=A0_____________
// | =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0| =C2=A0L name
= // L contextual keyword combination =C2=A0 | =C2=A0 =C2=A0|
// = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0L counter star= ting value
// =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0L t= ype =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0L counter value = type

// Everything is done at compile-time. Constexpr should = work, but also using
// `std::integral_constant` with a template = struct.
template<<= /span>typename T> con= stexpr int getIdForType() noexcept
{
=C2=A0 =C2=A0 constexpr int = id{lastIdCounter::value}; // Get the compile-time counter= 's current value
=C2=A0 =C2=A0 lastIdCounter::i= ncrement(); // Increme= nt the compile-time counter - it will remember its last value
=C2=A0 =C2=A0 return id;
<= /span>}

int main()=
{
=C2=A0 =C2=A0 // Whenever `getIdForType<T>()= ` gets called with a certain `T`, a value from
=C2=A0 =C2=A0 // t= he compile-time counter is "bound" to that `T` for the rest of th= e program.
=C2=A0 =C2=A0 = // Since it is `constexpr` and evaluated= at compile-time, there's no need to store
=C2=A0 =C2=A0 // t= he id anywhere in memory - calling the `getIdForType<T>()` function c= an
=C2=A0 =C2=A0 // basically be thought of as replacing = `getIdForType<T>()` with a = constant
=C2=A0 = =C2=A0 // at compile time.=

=C2=A0 =C2=A0 std::cout <= /span><< getIdForType&l= t;TypeA>() <= span style=3D"color:rgb(102,102,0)"><< std::endl; // Prints '0'
=C2=A0 =C2=A0 std::cout= << getIdForType= <TypeB>() << std::endl;= // Prints '1'
= =C2=A0 =C2=A0 std::cout << getIdForType<TypeC>() <&= lt; std::endl; // Prints '2'

=C2=A0 =C2=A0 return 0;
}



Thoughts?=C2= =A0
What motivated me to write this post is the fact that we have= all necessary information at compile-time to assign an unique constant id = to a specific type - but there (apparently) is no way of doing so.=C2=A0

Q: What happens if used in = different TUs?

=C2=A0 =C2=A0= // in file a.cpp
=C2=A0 =C2=A0 std::cout &= lt;< getIdForType<TypeA>() << std::endl; // Prints '0= 9;
=C2=A0 =C2=A0 std::cout << getIdFo= rType<TypeB>() << std::endl; // Prints '1'
=C2=A0 =C2=A0 std::cout << getIdForType<TypeC&= gt;() << std::endl; // Prints '2'
=C2=A0 =C2=A0=C2=A0
=C2=A0 =C2=A0 // i= n file b.cpp
=C2=A0 =C2=A0 std::cout <&l= t; getIdForType<TypeC>() << std::endl; // Prints '0'
=C2=A0 =C2=A0 std::cout << getIdForType= <TypeB>() << std::endl; // Prints '1'
=C2=A0 =C2=A0 std::cout << getIdForType<TypeA>= () << std::endl; // Prints '2'

Is that the expected result?

--

---
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>.
--20cf30223fc75cb59f05036b9e02-- .