220 2808 article Path: news.gmane.org!not-for-mail From: ricardofabianodeandrade@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: minimal enum class improvements Date: Mon, 11 Feb 2013 05:55:35 -0800 (PST) Lines: 402 Approved: news@gmane.org Message-ID: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_7_19754698.1360590935717" X-Trace: ger.gmane.org 1360590944 28390 80.91.229.3 (11 Feb 2013 13:55:44 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 11 Feb 2013 13:55:44 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCJN7V7TRQMBBYHQ4OEAKGQEN6TEIZY@isocpp.org Mon Feb 11 14:56:06 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ia0-f200.google.com ([209.85.210.200]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1U4trZ-0007Z9-6x for gclcip-std-proposals@m.gmane.org; Mon, 11 Feb 2013 14:56:05 +0100 Original-Received: by mail-ia0-f200.google.com with SMTP id o25sf14680170iad.7 for ; Mon, 11 Feb 2013 05:55:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:x-beenthere:x-received:date:from:to:message-id:subject :mime-version:x-original-sender:reply-to:precedence:mailing-list :list-id:x-google-group-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe:content-type; bh=DwqR8/P7srP8NjfHsnpbsOu1JIK3w1QkQxlGc9JoPyQ=; b=O9spPvgBt1yO/z+hvqA+nEXiA/eMapHCPcM12fehFqDobSrJfu3UZYb1DmJzViu5c6 5PPBBgbA/lsTrAz3HCN/DjjlauLw58xVjiO+gaZHyeqkLyuJHgtnD06qFUX+lnMOQWyV dntGPsXsvJveaNZQglVJTLOcoeCaH4dnbJ7FlbWzOLBbabp2ddEfkTuMBSV0oBQd3AjP shmeYAD9e+dpWmTrJARBOmV/Hjxyw1Qx7HEL9uz+hbg+ZuLzs3S/2veIuyfPZyDbFjXI wUhCcdn7GZvQiVY36yVvxmSoepQ53vFgMUG8mvokZ6+cfb8qbp3cmBrPTxWfoojMVX71 e0DA== X-Received: by 10.42.96.1 with SMTP id h1mr10816578icn.9.1360590944624; Mon, 11 Feb 2013 05:55:44 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.179.72 with SMTP id de8ls1652142igc.9.gmail; Mon, 11 Feb 2013 05:55:37 -0800 (PST) X-Received: by 10.50.149.132 with SMTP id ua4mr288843igb.8.1360590937147; Mon, 11 Feb 2013 05:55:37 -0800 (PST) X-Original-Sender: ricardofabianodeandrade@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:2808 Archived-At: ------=_Part_7_19754698.1360590935717 Content-Type: text/plain; charset=ISO-8859-1 Hi all, Many things were said time to time about who the enum is broken by big names in the C++ community what I don't think needs to be repeated here. We've got great suggestions in this forum for improving the enum but being a bit realistic I'm afraid many won't be mature enough in time for C++14 or even C++17 standards. So I would like to describe here two minor improvements in the language support for enum which can lead to even more improvements in future STL implementations. It's important to say, they're not new ideas (see Vicente Escriba ordinal types in this forum and other enum libraries such as the experimental boost.enum). I'm just taking a step forward to make them minimal enough what might turn them into better candidates for standardization. Well, let's start this draft of a draft. :-) *Request for change:* Inclusion of the following features in the C++ language support for enum: - Obtain the number of enumerators of a given enum type. - Obtain the value of an enumerator of a given enumerator's index (or order, or position) and its enum type. *Example *(please note no syntax is being suggested initially, just a [magic] placeholder): enum class AnEnum : int { a = -1, b = 1000, c = 0 }; std::size_t enumerators = [magic](); AnEnum value = [magic](0); * * *Suggested Implementation* (to the compiler vendors): - Number of enumerators: The compiler counts the number of enumerators within a given enum and provides this information during compile-time at no cost. - Enumerator value: The compiler takes an index for the given enum type and provides the respective enumerator value at no cost *IF *the expression can be resolved in compile-time (such as const, constexpr, template deduction, etc.). Otherwise, *an immutable array with the length equal to the number of enumerators of the given enum and based in its underlying type* is created during compile-time and stored (somewhere) in the translation unit. Any expression can use this information in run-time to obtain the enumerator value (it's a O(1) operation with some space cost and you only pay if use it). Example: AnEnum values[] = { AnEnum::a, AnEnum::b, AnEnum::c }; AnEnum value = values[0]; // is the same as [magic](0) during run-time *Uses*: - enum pseudo-inheritance and/or sequence continuation. Example: enum class AnotherEnum { d = ([magic]([magic]() - 1) + 1) }; // compile-time last() would be handy here! - Range based operations over a given enum type. Example: for(size_t i = 0; i < [magic](); ++i) { AnEnum value = [magic](i); } - Implementation of the index (or order, or position) of a given enumerator within an enum. Example (can be greatly improved by STL vendors): class enum_index { vector values; enum_index() { values.resize([magic]()); for(size_t i = 0; i < [magic](); ++i) { [i] = [magic] (i); } } size_t index(const T& value) const { return (std::find(values.begin(), values.end(), AnEnum::a) - values.begin()); } }; size_t index = enum_index().index(AnEnum::a); *Discussions on standardization* (AKA my opinions): Although many can think about these two features (number of enumerators and enumerator value) as a reflection proposal I don't totally agree with that. C++ core language already provides limited compile-time information accessible during run-time in the form of sizeof and typeid (being the last heavier in terms of cost than this proposal). The final form of this proposal would contain well thought keywords for these features (or clever uses to the existing ones -- less likely), so they can also be part of the core language. The keyword chosen for this proposal could even serve as a base for future C++ reflection ones (maybe the member keyword?). One final question: instead going to SG7 (reflection) or SG9 (ranges) should this proposal go directly to the EWG? This is such a small improvement in terms of complexity and impact in the C++ language but it has the potential of improving a lot the readability and maintainability of any code which depends on enum to work properly. Additions, reviews and feedback are welcome. Thanks, Ricardo Andrade -- --- 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/?hl=en. ------=_Part_7_19754698.1360590935717 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all,

Many things were said time to time about who the=  enum is broken by big na= mes in the C++ community what I don't think needs to be repeated here.
<= /div>

We've got great suggestions in this forum for impr= oving the enum but being a bit= realistic I'm afraid many won't be mature enough in time for C++14 or even= C++17 standards.
So I would like to describe here two minor = improvements in the language support for enum which can lead to even more improvements in future STL= implementations.

It's important to say, they'= re not new ideas (see Vicente Escriba ordinal types in this forum and other= enum libraries such as the ex= perimental boost.enum).
I'm just taking a step forward to make th= em minimal enough what might turn them into better candidates for standardi= zation.

Well, let's start this draft of a draft. := -)

Request for change:

Inclusion of the following features in the C++ language support fo= r enum:
  • Obta= in the number of enumerators of a given enum type.
  • Obtain the value of an enumerator of a gi= ven enumerator's index (or order, or position) and its enum type.
Example (please note no syntax is = being suggested initially, just a [ma= gic] placeholder):
enum= class AnEnum : int { a =3D -1, b =3D 1000<= span style=3D"color: #660;" class=3D"styled-by-prettify">, c =3D 0 };<= br>std::size_t enume= rators =3D= [magic]<AnEnum>();
AnEnum value =3D [magic]<<= span style=3D"color: #606;" class=3D"styled-by-prettify">AnEnum>(0);

Suggested Implementation (to the compiler = vendors):
  • Number of enumerators:
    The comp= iler counts the number of enumerators within a given enum and provides this information during compi= le-time at no cost.
  • Enumerator value:
    The compiler takes an= index for the given enum type= and provides the respective enumerator value at no cost IF the expr= ession can be resolved in compile-time (such as const, constexpr, template deduction, etc.).
    Otherwise, an immutable array with t= he length equal to the number of enumerators of the given enum and based in= its underlying type is created during compile-time and stored (somewhe= re) in the translation unit.
    Any expression can use this information in = run-time to obtain the enumerator value (it's a O(1) operation with some space cost and you only pay if u= se it).
    Example:
    =
    AnEnum values[] <= /span>=3D<= span style=3D"color: #000;" class=3D"styled-by-prettify"> { AnEnum::a,= AnEnum::b, AnEnum::c };
    AnEnu= m value =3D values[0]; // is the same as [magic]<AnEnum>(0) during run-tim= e
Uses:
  • enum pseudo-inheritan= ce and/or sequence continuation.
    Example:
    = enum class AnotherEnum { d =3D <= /span>([magic]<AnEnum>([magic]<AnEnum>() - 1) + 1) };<= /span> // compile-time last= <AnEnum>() would be handy here!
  • Range based operations over a given enum type.
    Example:
    for(size_t i =3D 0; i < [magic]<AnEnum>= ;(); ++i)
    { AnEnum value =3D [magic]<AnEnum>(i); }
  • Implementation of the in= dex (or order, or position) of a given enumerator within an enum.
    Example (can be greatly improved by = STL vendors):
    <typename = T>
    class enum_= index
    {
        vector    <AnEnum> values;
        enum_index() {
    &nb= sp;       values.resize([magic]    <T>());
            for(= size_t i =3D 0; i < [magic]    <AnEnum>(); ++i) { [i] =3D [magic]<AnEnum>(i); }
        }
    &n= bsp;   size_t index(const T& value) const
        { retur= n (std::find(values.begin(), values.end(), AnEnum::a) - values.begin()); }<= br>};
    size_t index =3D enum_index    <AnEnum>().index(AnEnum::a);
Discussions on standardization (AKA my = opinions):
Although many can think about these two features (number of= enumerators and enumerator value) as a reflection proposal I don't totally= agree with that.
 
C++ core language alre= ady provides limited compile-time information accessible during run-time in= the form of sizeof and <= font face=3D"courier new, monospace">typeid (being the last hea= vier in terms of cost than this proposal).
The final form= of this proposal would contain well thought keywords for these features (o= r clever uses to the existing ones -- less likely), so they can also be par= t of the core language.
The keyword chosen for this propo= sal could even serve as a base for future C++ reflection ones (maybe the member keyword?).
 
One final question: instead going to SG7 (reflection) = or SG9 (ranges) should this proposal go directly to the EWG?

This is such a small improvement in terms of complex= ity and impact in the C++ language but it has the potential of improving a = lot the readability and maintainability of any code which depends= on enum to work properly.

Additions, reviews and feedback are welcome.

Thanks,
Ricardo Andrade

--
 
---
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-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-pro= posals/?hl=3Den.
 
 
------=_Part_7_19754698.1360590935717-- .