Topic: Ordinal types
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Wed, 21 Nov 2012 22:54:26 +0100
Raw View
This is a multi-part message in MIME format.
--------------070808030408030606020303
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
While C++11 provides enums, the standard doesn't see an enum as an
ordinal type. Language as Pascal and Ada had defined since the beginning
attributes that allows to map an enumeration to a continuous range
|0..N-1|, so it can be used in for statements and as index of an array.
Another example of ordinal type could be a range of integers.
An ordinal type will have associated the following informations:
* |size|: the number of elements in the ordinal type.
* |pos|: the position relative of an element in the ordinal type.
* |val|: the element in the ordinal type at a given position.
In addition the fist, last, succ and pred informations are easy to
deduce from the preceding ones.
Ordinal Types are trivially ordered so that they can be used as key for
ordered containers.
Ordinal types have a trivial hash function so that they can be used as
key for unordered containers.
The ordinal type closure can be seen as a range and we should be able to
iterate over all its elements.
Associated to ordinal types we could define the following containers:
ordinal_set and ordinal_array:
* ordinal_set<OT> is based on the std::bitset interface
* ordinal_array<T,OT> class is based on the |std::array<T,N>| class that
uses instead an ordinal type as index.
The question is, would it be an interest on ordinal types for the
standard? if yes, should ordinal types be defined as part of the C++
language or just a concept and provide some basic models? IMO, seen C++
enums (or a subset of them) as ordinal types should imply a change on
the language so that the intrinsic size, pos and val informations are
provided by the compiler. Range of integers would not need a change on
the language.
Waiting for your feedback,
Vicente
--
--------------070808030408030606020303
Content-Type: text/html; charset=ISO-8859-1
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<p> While C++11 provides enums, the standard doesn't see an enum as
an ordinal type. Language as Pascal and Ada had defined since the
beginning attributes that allows to map an enumeration to a
continuous range <code class="computeroutput"><span
class="number">0.</span><span class="special">.</span><span
class="identifier">N</span><span class="special">-</span><span
class="number">1</span></code>, so it can be used in for
statements and as index of an array. Another example of ordinal
type could be a range of integers. <br>
</p>
<p>An ordinal type will have associated the following informations:<br>
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
</p>
<div class="itemizedlist">
<ul class="itemizedlist" type="disc">
<li class="listitem"> <code class="computeroutput"><span
class="identifier">size</span></code>: the number of
elements in the ordinal type. </li>
<li class="listitem"> <code class="computeroutput"><span
class="identifier">pos</span></code>: the position
relative of an element in the ordinal type. </li>
<li class="listitem"> <code class="computeroutput"><span
class="identifier">val</span></code>: the element in the
ordinal type at a given position. </li>
</ul>
</div>
<p>In addition the fist, last, succ and pred informations are easy
to deduce from the preceding ones.<br>
</p>
<p>Ordinal Types are trivially ordered so that they can be used as
key for ordered containers.</p>
<p>Ordinal types have a trivial hash function so that they can be
used as key for unordered containers.</p>
The ordinal type closure can be seen as a range and we should be
able to iterate over all its elements.<br>
<p>Associated to ordinal types we could define the following
containers: ordinal_set and ordinal_array:<br>
</p>
<p>* ordinal_set<OT> is based on the std::bitset interface <br>
</p>
<p>* ordinal_array<T,OT>
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
class is based on the <code class="computeroutput"><span
class="identifier">std</span><span class="special">::</span><span
class="identifier">array</span><span class="special"><</span><span
class="identifier">T</span><span class="special">,</span><span
class="identifier">N</span><span class="special">></span></code>
class that uses instead an ordinal type as index.<br>
</p>
<p>The question is, would it be an interest on ordinal types for the
standard? if yes, should ordinal types be defined as part of the
C++ language or just a concept and provide some basic models? IMO,
seen C++ enums (or a subset of them) as ordinal types should imply
a change on the language so that the intrinsic size, pos and val
informations are provided by the compiler. Range of integers would
not need a change on the language.<br>
</p>
<p>Waiting for your feedback,<br>
Vicente<br>
</p>
</body>
</html>
<p></p>
-- <br />
<br />
<br />
<br />
--------------070808030408030606020303--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Wed, 21 Nov 2012 14:08:12 -0800 (PST)
Raw View
------=_Part_700_25134713.1353535692530
Content-Type: text/plain; charset=ISO-8859-1
On Wednesday, November 21, 2012 1:54:28 PM UTC-8, viboes wrote:
>
> While C++11 provides enums, the standard doesn't see an enum as an
> ordinal type. Language as Pascal and Ada had defined since the beginning
> attributes that allows to map an enumeration to a continuous range 0..N-1,
> so it can be used in for statements and as index of an array. Another
> example of ordinal type could be a range of integers.
>
> An ordinal type will have associated the following informations:
>
> - size: the number of elements in the ordinal type.
> - pos: the position relative of an element in the ordinal type.
> - val: the element in the ordinal type at a given position.
>
> In addition the fist, last, succ and pred informations are easy to
> deduce from the preceding ones.
>
> Ordinal Types are trivially ordered so that they can be used as key for
> ordered containers.
>
> Ordinal types have a trivial hash function so that they can be used as key
> for unordered containers.
> The ordinal type closure can be seen as a range and we should be able to
> iterate over all its elements.
>
> Associated to ordinal types we could define the following containers:
> ordinal_set and ordinal_array:
>
> * ordinal_set<OT> is based on the std::bitset interface
>
> * ordinal_array<T,OT> class is based on the std::array<T,N> class that
> uses instead an ordinal type as index.
>
> The question is, would it be an interest on ordinal types for the
> standard? if yes, should ordinal types be defined as part of the C++
> language or just a concept and provide some basic models? IMO, seen C++
> enums (or a subset of them) as ordinal types should imply a change on the
> language so that the intrinsic size, pos and val informations are provided
> by the compiler. Range of integers would not need a change on the language.
>
> Waiting for your feedback,
> Vicente
>
Isn't this just a range? Outside of the ability to turn an enumeration into
a range (I have no idea how you would specify a subset of an enumeration),
this all seems to just be boost::irange. And, as you've pointed out, even
the set stuff is just a variation on std::array.
Outside of building an array of enumerators (which should be handled by
compile-time reflection capabilities), I don't see a specific need for any
language changes. And the range study-group will handle the standard
library changes.
--
------=_Part_700_25134713.1353535692530
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Wednesday, November 21, 2012 1:54:28 PM UTC-8, viboes wrote:<blockquote =
class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1p=
x #ccc solid;padding-left: 1ex;">
=20
=20
=20
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
=20
<p> While C++11 provides enums, the standard doesn't see an enum as
an ordinal type. Language as Pascal and Ada had defined since the
beginning attributes that allows to map an enumeration to a
continuous range <code><span>0.</span><span>.</span><span>N</span><sp=
an>-</span><span>1</span></code>, so it can be used in for
statements and as index of an array. Another example of ordinal
type could be a range of integers. <br>
</p>
<p>An ordinal type will have associated the following informations:<br>
=20
</p>
<div>
<ul type=3D"disc">
<li> <code><span>size</span></code>: the number of
elements in the ordinal type. </li>
<li> <code><span>pos</span></code>: the position
relative of an element in the ordinal type. </li>
<li> <code><span>val</span></code>: the element in the
ordinal type at a given position. </li>
</ul>
</div>
<p>In addition the fist, last, succ and pred informations are easy
to deduce from the preceding ones.<br>
</p>
<p>Ordinal Types are trivially ordered so that they can be used as
key for ordered containers.</p>
<p>Ordinal types have a trivial hash function so that they can be
used as key for unordered containers.</p>
The ordinal type closure can be seen as a range and we should be
able to iterate over all its elements.<br>
<p>Associated to ordinal types we could define the following
containers: ordinal_set and ordinal_array:<br>
</p>
<p>* ordinal_set<OT> is based on the std::bitset interface <br>
</p>
<p>* ordinal_array<T,OT>
=20
class is based on the <code><span>std</span><span>::</span><span>arra=
y</span><span><</span><span>T</span><span>,</span><span>N</span><span>&g=
t;</span></code>
class that uses instead an ordinal type as index.<br>
</p>
<p>The question is, would it be an interest on ordinal types for the
standard? if yes, should ordinal types be defined as part of the
C++ language or just a concept and provide some basic models? IMO,
seen C++ enums (or a subset of them) as ordinal types should imply
a change on the language so that the intrinsic size, pos and val
informations are provided by the compiler. Range of integers would
not need a change on the language.<br>
</p>
<p>Waiting for your feedback,<br>
Vicente<br></p></div></blockquote><div>Isn't this just a range? Outsi=
de of the ability to turn an enumeration into a range (I have no idea how y=
ou would specify a subset of an enumeration), this all seems to just be boo=
st::irange. And, as you've pointed out, even the set stuff is just a variat=
ion on std::array.<br><br>Outside of building an array of enumerators (whic=
h should be handled by compile-time reflection capabilities), I don't see a=
specific need for any language changes. And the range study-group will han=
dle the standard library changes.<br></div>
<p></p>
-- <br />
<br />
<br />
<br />
------=_Part_700_25134713.1353535692530--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Thu, 22 Nov 2012 08:39:13 +0100
Raw View
This is a multi-part message in MIME format.
--------------080003030209050507030302
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 21/11/12 23:08, Nicol Bolas a =E9crit :
> On Wednesday, November 21, 2012 1:54:28 PM UTC-8, viboes wrote:
>
> While C++11 provides enums, the standard doesn't see an enum as an
> ordinal type. Language as Pascal and Ada had defined since the
> beginning attributes that allows to map an enumeration to a
> continuous range |0..N-1|, so it can be used in for statements and
> as index of an array. Another example of ordinal type could be a
> range of integers.
>
> An ordinal type will have associated the following informations:
>
> * |size|: the number of elements in the ordinal type.
> * |pos|: the position relative of an element in the ordinal type.
> * |val|: the element in the ordinal type at a given position.
>
> In addition the fist, last, succ and pred informations are easy to
> deduce from the preceding ones.
>
> Ordinal Types are trivially ordered so that they can be used as
> key for ordered containers.
>
> Ordinal types have a trivial hash function so that they can be
> used as key for unordered containers.
>
> The ordinal type closure can be seen as a range and we should be
> able to iterate over all its elements.
>
> Associated to ordinal types we could define the following
> containers: ordinal_set and ordinal_array:
>
> * ordinal_set<OT> is based on the std::bitset interface
>
> * ordinal_array<T,OT> class is based on the |std::array<T,N>|
> class that uses instead an ordinal type as index.
>
> The question is, would it be an interest on ordinal types for the
> standard? if yes, should ordinal types be defined as part of the
> C++ language or just a concept and provide some basic models? IMO,
> seen C++ enums (or a subset of them) as ordinal types should imply
> a change on the language so that the intrinsic size, pos and val
> informations are provided by the compiler. Range of integers would
> not need a change on the language.
>
> Waiting for your feedback,
> Vicente
>
> Isn't this just a range?
The closure of an ordinal type, which is a static concept, could be=20
viewed as a range. An ordinal type is more than a range, is a meta-range.
> Outside of the ability to turn an enumeration into a range (I have no=20
> idea how you would specify a subset of an enumeration),
Well, if we associate the pos/val meta-informations I don't see any=20
impediment.
> this all seems to just be boost::irange.
> And, as you've pointed out, even the set stuff is just a variation on=20
> std::array.
Exactly, and today, you need to define some artificial SIZE constant=20
that could be used as size of the array. This is maybe a minor change,=20
but as I understand ordinal types, this SIZE attribute should be given=20
by the compiler.
>
> Outside of building an array of enumerators (which should be handled=20
> by compile-time reflection capabilities), I don't see a specific need=20
> for any language changes.
We agree here.
> And the range study-group will handle the standard library changes.
You can consider this as my contribution to the range study-group and=20
consider myself as a member of the range SG if this could help ;-)
Vicente
--=20
--------------080003030209050507030302
Content-Type: text/html; charset=ISO-8859-1
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Le 21/11/12 23:08, Nicol Bolas a
écrit :<br>
</div>
<blockquote
cite="mid:f1bebf29-36e1-4612-b5e4-90fd957533ac@isocpp.org"
type="cite">On Wednesday, November 21, 2012 1:54:28 PM UTC-8,
viboes wrote:
<blockquote class="gmail_quote" style="margin: 0;margin-left:
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<div bgcolor="#FFFFFF" text="#000000">
<p> While C++11 provides enums, the standard doesn't see an
enum as an ordinal type. Language as Pascal and Ada had
defined since the beginning attributes that allows to map an
enumeration to a continuous range <code><span>0.</span><span>.</span><span>N</span><span>-</span><span>1</span></code>,
so it can be used in for statements and as index of an
array. Another example of ordinal type could be a range of
integers. <br>
</p>
<p>An ordinal type will have associated the following
informations:<br>
</p>
<div>
<ul type="disc">
<li> <code><span>size</span></code>: the number of
elements in the ordinal type. </li>
<li> <code><span>pos</span></code>: the position relative
of an element in the ordinal type. </li>
<li> <code><span>val</span></code>: the element in the
ordinal type at a given position. </li>
</ul>
</div>
<p>In addition the fist, last, succ and pred informations are
easy to deduce from the preceding ones.<br>
</p>
<p>Ordinal Types are trivially ordered so that they can be
used as key for ordered containers.</p>
<p>Ordinal types have a trivial hash function so that they can
be used as key for unordered containers.</p>
The ordinal type closure can be seen as a range and we should
be able to iterate over all its elements.<br>
<p>Associated to ordinal types we could define the following
containers: ordinal_set and ordinal_array:<br>
</p>
<p>* ordinal_set<OT> is based on the std::bitset
interface <br>
</p>
<p>* ordinal_array<T,OT> class is based on the <code><span>std</span><span>::</span><span>array</span><span><</span><span>T</span><span>,</span><span>N</span><span>></span></code>
class that uses instead an ordinal type as index.<br>
</p>
<p>The question is, would it be an interest on ordinal types
for the standard? if yes, should ordinal types be defined as
part of the C++ language or just a concept and provide some
basic models? IMO, seen C++ enums (or a subset of them) as
ordinal types should imply a change on the language so that
the intrinsic size, pos and val informations are provided by
the compiler. Range of integers would not need a change on
the language.<br>
</p>
<p>Waiting for your feedback,<br>
Vicente<br>
</p>
</div>
</blockquote>
<div>Isn't this just a range? </div>
</blockquote>
The closure of an ordinal type, which is a static concept, could be
viewed as a range. An ordinal type is more than a range, is a
meta-range. <br>
<blockquote
cite="mid:f1bebf29-36e1-4612-b5e4-90fd957533ac@isocpp.org"
type="cite">
<div>Outside of the ability to turn an enumeration into a range (I
have no idea how you would specify a subset of an enumeration),
</div>
</blockquote>
Well, if we associate the pos/val meta-informations I don't see any
impediment. <br>
<blockquote
cite="mid:f1bebf29-36e1-4612-b5e4-90fd957533ac@isocpp.org"
type="cite">
<div>this all seems to just be boost::irange.<br>
</div>
</blockquote>
<blockquote
cite="mid:f1bebf29-36e1-4612-b5e4-90fd957533ac@isocpp.org"
type="cite">
<div>And, as you've pointed out, even the set stuff is just a
variation on std::array.<br>
</div>
</blockquote>
Exactly, and today, you need to define some artificial SIZE constant
that could be used as size of the array. This is maybe a minor
change, but as I understand ordinal types, this SIZE attribute
should be given by the compiler.<br>
<blockquote
cite="mid:f1bebf29-36e1-4612-b5e4-90fd957533ac@isocpp.org"
type="cite">
<div><br>
Outside of building an array of enumerators (which should be
handled by compile-time reflection capabilities), I don't see a
specific need for any language changes. </div>
</blockquote>
We agree here.<br>
<blockquote
cite="mid:f1bebf29-36e1-4612-b5e4-90fd957533ac@isocpp.org"
type="cite">
<div>And the range study-group will handle the standard library
changes.<br>
</div>
</blockquote>
You can consider this as my contribution to the range study-group
and consider myself as a member of the range SG if this could help
;-)<br>
<br>
Vicente<br>
</body>
</html>
<p></p>
-- <br />
<br />
<br />
<br />
--------------080003030209050507030302--
.
Author: ricardofabianodeandrade@gmail.com
Date: Fri, 8 Feb 2013 04:38:35 -0800 (PST)
Raw View
------=_Part_151_31159999.1360327115823
Content-Type: text/plain; charset=ISO-8859-1
Hi all,
I have been spending some time thinking about enums, reading articles on
the matter (Sutter, Stroustrup) and experiment different implementations of
improvements on the C++ enums (including Vincente's one).
I feel that we really need 2 small changes in the C++ enums (citing Vicente
here):
- size: the number of elements in the ordinal type.
- val: the element in the ordinal type at a given position.
size of a enum is a compile-time information that many may consider a form
o reflection but I see no difference between it and the information
retrieved by a sizeof <http://en.cppreference.com/w/cpp/keyword/sizeof>.
There are a number of situations where today we place out-of-domain values
inside a enum to represent this information.
Or there are cases where enum values are not sequential and we end up
placing this information outside of the enum and controlling it 'manually'.
val of a enum is another compile-time info but this one can made be
available at run-time for a very low cost.
Think about an array with all the enum elements in their order of declaration.
Obtaining val is just a O(1) operation.
Currently, there is no way under the DRY principle to have this information
for a given C++ enum (besides lots of macros).
Once again, many could consider this a form of reflection, but the C++
compiler already does things much more complex than this (such as vtables).
Also, according to C++ philosophy, we should only pay for what we use.
So the compiler may be smart enough to *not *generate such val 'array' if
it is called *only *with constant/literal values (constexpr<http://en.cppreference.com/w/cpp/keyword/constexpr>
anyone?).
Why do I think we just need size and val?
Because, pos can be implemented in terms of val and size.
pos is heavily dependent on the enumerators' values (defined by the
programmer), differently of val which is based only the number
of enumerators (counted by the compiler).
Example: enum X { a = -1, b = 1000, c = 3 };
What is be best approach to obtain pos(b)? A loop? (which is O(n) but very
simple for compiler to do) a hash table? a tree? (too complex don't you
think?), sort+bin search? (hum, no way)
I don't know for sure but I know that if the compiler doesn't provide me posI can loop from
0 to size, calling val for obtaining each enumerator and finally, picking
the best suitable data structure to save this info.
I invite all interested people in having such improvements in the C++ enum to
think about any other potential features.
My conclusions so far is that the standard library can provide many of
these features in terms of size and val (ranges, iterators).
Although, I must agree that conversion of enum to string is a whole
different beast with its own sets of challenges.
enum inheritance is out of the scope here but I personally see many
potential uses of both size and val from a base enum in a derived one.
Additionally, because size and val are compile-time info I think we would
need new keywords (or at least reusing some of them) to properly capture
the spirit of such feature.
What may lead to a question: is the EWG group of the standard committee the
right one to handle this feature?
I have been working with C++ for the last 12 years and I'm looking forward
to have these features in the next standard.
Regards,
Ricardo
On Wednesday, November 21, 2012 7:54:28 PM UTC-2, Vicente J. Botet Escriba
wrote:
>
> While C++11 provides enums, the standard doesn't see an enum as an
> ordinal type. Language as Pascal and Ada had defined since the beginning
> attributes that allows to map an enumeration to a continuous range 0..N-1,
> so it can be used in for statements and as index of an array. Another
> example of ordinal type could be a range of integers.
>
> An ordinal type will have associated the following informations:
>
> - size: the number of elements in the ordinal type.
> - pos: the position relative of an element in the ordinal type.
> - val: the element in the ordinal type at a given position.
>
> In addition the fist, last, succ and pred informations are easy to
> deduce from the preceding ones.
>
> Ordinal Types are trivially ordered so that they can be used as key for
> ordered containers.
>
> Ordinal types have a trivial hash function so that they can be used as key
> for unordered containers.
> The ordinal type closure can be seen as a range and we should be able to
> iterate over all its elements.
>
> Associated to ordinal types we could define the following containers:
> ordinal_set and ordinal_array:
>
> * ordinal_set<OT> is based on the std::bitset interface
>
> * ordinal_array<T,OT> class is based on the std::array<T,N> class that
> uses instead an ordinal type as index.
>
> The question is, would it be an interest on ordinal types for the
> standard? if yes, should ordinal types be defined as part of the C++
> language or just a concept and provide some basic models? IMO, seen C++
> enums (or a subset of them) as ordinal types should imply a change on the
> language so that the intrinsic size, pos and val informations are provided
> by the compiler. Range of integers would not need a change on the language.
>
> Waiting for your feedback,
> Vicente
>
--
---
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_151_31159999.1360327115823
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div>Hi all,</div><div><br></div><div>I have been spending some time thinki=
ng about <font face=3D"courier new, monospace">enum</font>s, reading articl=
es on the matter (Sutter, Stroustrup) and experiment different implementati=
ons of improvements on the C++ enums (including Vincente's one).</div><div>=
I feel that we really need 2 small changes in the C++ enums (citing Vicente=
here):</div><div><ul type=3D"disc"><li><code><font color=3D"#ff0000">size<=
/font></code>: the number of elements in the ordinal type.</li><li><code><f=
ont color=3D"#ff0000">val</font></code>: the element in the ordinal type at=
a given position.<br></li></ul><div><span style=3D"line-height: 17px;"><fo=
nt face=3D"courier new, monospace" color=3D"#ff0000">size </font>of a enum =
is a compile-time information that many may consider a form o reflection bu=
t I see no difference between it and the information retrieved by a </=
span><code style=3D"text-decoration: underline; color: rgb(11, 0, 128); bac=
kground-image: none; background-color: transparent; font-family: DejaVuSans=
Mono, 'DejaVu Sans Mono', courier, monospace !important; line-height: 15.35=
9375px;"><a href=3D"http://en.cppreference.com/w/cpp/keyword/sizeof" title=
=3D"cpp/keyword/sizeof" style=3D"text-decoration: underline; color: rgb(11,=
0, 128); background-image: none; background-color: rgb(249, 249, 249); fon=
t-family: DejaVuSans, 'DejaVu Sans', arial, sans-serif; line-height: 15.359=
375px;">sizeof</a></code><span style=3D"line-height: 17px;">.</span></div><=
/div><blockquote style=3D"margin: 0 0 0 40px; border: none; padding: 0px;">=
<div><span style=3D"line-height: 17px;">There are a number of situations wh=
ere today we place out-of-domain values inside a <font face=3D"courier new,=
monospace">enum</font> to represent this information.</span></div><di=
v><span style=3D"line-height: 17px;">Or there are cases where <font fa=
ce=3D"courier new, monospace">enum</font> values are not sequential an=
d we end up placing this information outside of the <font face=3D"courier n=
ew, monospace">enum</font> and controlling it 'manually'.</span></div>=
</blockquote><blockquote style=3D"margin: 0 0 0 40px; border: none; padding=
: 0px;"><br></blockquote><div><span style=3D"line-height: 17px;"><font colo=
r=3D"#ff0000"><font face=3D"courier new, monospace">val</font> </font>of a =
enum is another compile-time info but this one can made be available at run=
-time for a very low cost.</span></div><blockquote style=3D"margin: 0 0 0 4=
0px; border: none; padding: 0px;"><div><span style=3D"line-height: 17px;">T=
hink about an <font face=3D"courier new, monospace">array</font> with all t=
he <font face=3D"courier new, monospace">enum</font> elements in their =
;</span><span style=3D"line-height: 17px;">order of </span><span style=
=3D"line-height: 17px;">declaration. Obtaining </span><font face=3D"courier=
new, monospace" style=3D"line-height: 17px;">val</font><span style=3D"line=
-height: 17px;"> is just a </span><font face=3D"courier new, monospace=
" style=3D"line-height: 17px;">O(1)</font><span style=3D"line-height: 17px;=
"> operation.</span></div><div><span style=3D"line-height: 17px;">Currently=
, there is no way under the DRY principle to have this information for a gi=
ven C++ <font face=3D"courier new, monospace">enum </font>(besides lots of =
macros).</span></div><div><span style=3D"line-height: 17px;">Once again, ma=
ny could consider this a form of reflection, but the C++ compiler already d=
oes things much more complex than this (such as <font face=3D"courier new, =
monospace">vtable</font>s).</span></div><div><span style=3D"line-height: 17=
px;">Also, according to C++ philosophy, we should </span><span style=
=3D"line-height: 17px;">only </span><span style=3D"line-height: 17px;"=
>pay for what we use.</span></div><div><span style=3D"line-height: 17px;">S=
o the compiler may be smart enough to <b>not </b>generate such <font color=
=3D"#ff0000"><font face=3D"courier new, monospace">val</font> </font>'=
array' if it is called </span><span style=3D"line-height: 17px;"><b>on=
ly </b></span><span style=3D"line-height: 17px;">with constant/literal=
values (</span><a href=3D"http://en.cppreference.com/w/cpp/keyword/constex=
pr" title=3D"cpp/keyword/constexpr" style=3D"text-decoration: underline; co=
lor: rgb(11, 0, 128); background-image: none; background-color: rgb(249, 24=
9, 249); font-family: DejaVuSans, 'DejaVu Sans', arial, sans-serif; line-he=
ight: 15.359375px;"><code style=3D"font-family: DejaVuSansMono, 'DejaVu San=
s Mono', courier, monospace !important; background-color: transparent;">con=
stexpr</code></a><span style=3D"line-height: 17px;"> anyone?).</span><=
/div></blockquote><div><span style=3D"line-height: 17px;"><br></span></div>=
<div><span style=3D"line-height: 17px;">Why do I think we just need <font f=
ace=3D"courier new, monospace" color=3D"#ff0000">size </font>and <font face=
=3D"courier new, monospace" color=3D"#ff0000">val</font>?</span></div><bloc=
kquote style=3D"margin: 0 0 0 40px; border: none; padding: 0px;"><div><span=
style=3D"line-height: 17px;">Because</span><font color=3D"#000000" style=
=3D"line-height: 17px;">, <font face=3D"courier new, monospace">pos </font>=
can be implemented in terms of <font face=3D"courier new, monospace">val</f=
ont> and <font face=3D"courier new, monospace">size</font>.</font></di=
v><div><font face=3D"courier new, monospace" style=3D"line-height: 17px;">p=
os </font><span style=3D"line-height: 17px;">is heavily dependent on t=
he enumerators' values (defined by the programmer), differently of</span><s=
pan style=3D"line-height: 17px;"> </span><font face=3D"times new roman=
, serif" style=3D"line-height: 17px;">val </font><span style=3D"line-h=
eight: 17px;">which is based only the number of enumerators (counted b=
y the compiler)</span><span style=3D"line-height: 17px;">.</span></div><div=
><span style=3D"line-height: 17px;">Example: </span><font face=3D"courier n=
ew, monospace" style=3D"line-height: 17px;">enum X { a =3D -1, b =3D 1000, =
c =3D 3 };</font></div><div><span style=3D"line-height: 17px;">What is be b=
est approach to obtain </span><font face=3D"courier new, monospace" style=
=3D"line-height: 17px;">pos(b)</font><span style=3D"line-height: 17px;">? A=
loop? (which is <font face=3D"courier new, monospace">O(n)</font> but very=
simple for compiler to do) a hash table? a tree? (too complex don't you th=
ink?), sort+bin search</span><span style=3D"line-height: 17px;">?</span><sp=
an style=3D"line-height: 17px;"> (hum, no way)</span></div><div><span =
style=3D"line-height: 17px;">I don't know for sure but I know that if the c=
ompiler doesn't provide me </span><font face=3D"courier new, monospace" sty=
le=3D"line-height: 17px;">pos</font><span style=3D"line-height: 17px;"> I c=
an loop from </span><font face=3D"courier new, monospace" style=3D"line-hei=
ght: 17px;">0</font><span style=3D"line-height: 17px;"> to </span><font fac=
e=3D"courier new, monospace" style=3D"line-height: 17px;">size</font><span =
style=3D"line-height: 17px;">, calling </span><font face=3D"courier new, mo=
nospace" style=3D"line-height: 17px;">val</font><span style=3D"line-height:=
17px;"> for obtaining each enumerator and finally, picking the best s=
uitable data structure to save this info.</span></div></blockquote><div><br=
></div><div>I invite all interested people in having such improvements in t=
he C++ <font face=3D"courier new, monospace">enum</font> to think abou=
t any other potential features.</div><div>My conclusions so far is that the=
standard library can provide many of these features in terms of <font=
face=3D"courier new, monospace">size</font> and <font face=3D"co=
urier new, monospace">val</font> (ranges, iterators).</div><div>Althou=
gh, I must agree that conversion of <font face=3D"courier new, monospa=
ce">enum</font> to <font face=3D"courier new, monospace">string</font>=
is a whole different beast with its own sets of challenges.<br></div>=
<div><font face=3D"courier new, monospace">enum</font> inheritance is =
out of the scope here but I personally see many potential uses of both <fon=
t face=3D"courier new, monospace">size</font> and <font face=3D"courier new=
, monospace">val</font> from a base <font face=3D"courier new, monospace">e=
num</font> in a derived one.</div><div><br></div><div>Additionally, be=
cause <font face=3D"courier new, monospace">size</font> and <font face=3D"c=
ourier new, monospace">val</font> are compile-time info I think we would ne=
ed new keywords (or at least reusing some of them) to properly capture the =
spirit of such feature.</div><div>What may lead to a question: is the EWG g=
roup of the standard committee the right one to handle this feature?</=
div><div><br></div><div>I have been working with C++ for the last 12 years =
and I'm looking forward to have these features in the next standard.</div><=
div><br></div><div>Regards,</div><div>Ricardo</div><div><br></div><br>On We=
dnesday, November 21, 2012 7:54:28 PM UTC-2, Vicente J. Botet Escriba wrote=
:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bo=
rder-left: 1px #ccc solid;padding-left: 1ex;">
=20
=20
=20
<div bgcolor=3D"#FFFFFF" text=3D"#000000">
=20
<p> While C++11 provides enums, the standard doesn't see an enum as
an ordinal type. Language as Pascal and Ada had defined since the
beginning attributes that allows to map an enumeration to a
continuous range <code><span>0.</span><span>.</span><span>N</span><sp=
an>-</span><span>1</span></code>, so it can be used in for
statements and as index of an array. Another example of ordinal
type could be a range of integers. <br>
</p>
<p>An ordinal type will have associated the following informations:<br>
=20
</p>
<div>
<ul type=3D"disc">
<li> <code><span>size</span></code>: the number of
elements in the ordinal type. </li>
<li> <code><span>pos</span></code>: the position
relative of an element in the ordinal type. </li>
<li> <code><span>val</span></code>: the element in the
ordinal type at a given position. </li>
</ul>
</div>
<p>In addition the fist, last, succ and pred informations are easy
to deduce from the preceding ones.<br>
</p>
<p>Ordinal Types are trivially ordered so that they can be used as
key for ordered containers.</p>
<p>Ordinal types have a trivial hash function so that they can be
used as key for unordered containers.</p>
The ordinal type closure can be seen as a range and we should be
able to iterate over all its elements.<br>
<p>Associated to ordinal types we could define the following
containers: ordinal_set and ordinal_array:<br>
</p>
<p>* ordinal_set<OT> is based on the std::bitset interface <br>
</p>
<p>* ordinal_array<T,OT>
=20
class is based on the <code><span>std</span><span>::</span><span>arra=
y</span><span><</span><span>T</span><span>,</span><span>N</span><span>&g=
t;</span></code>
class that uses instead an ordinal type as index.<br>
</p>
<p>The question is, would it be an interest on ordinal types for the
standard? if yes, should ordinal types be defined as part of the
C++ language or just a concept and provide some basic models? IMO,
seen C++ enums (or a subset of them) as ordinal types should imply
a change on the language so that the intrinsic size, pos and val
informations are provided by the compiler. Range of integers would
not need a change on the language.<br>
</p>
<p>Waiting for your feedback,<br>
Vicente<br>
</p>
</div>
</blockquote>
<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/?hl=3Den">http://groups.google.com/a/isocpp.org/group/std-pro=
posals/?hl=3Den</a>.<br />
<br />
<br />
------=_Part_151_31159999.1360327115823--
.
Author: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Date: Tue, 12 Feb 2013 20:42:29 +0100
Raw View
This is a multi-part message in MIME format.
--------------010903060401080505040702
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Le 08/02/13 13:38, ricardofabianodeandrade@gmail.com a =E9crit :
> Hi all,
>
> I have been spending some time thinking about enums, reading articles=20
> on the matter (Sutter, Stroustrup) and experiment different=20
> implementations of improvements on the C++ enums (including Vincente's=20
> one).
> I feel that we really need 2 small changes in the C++ enums (citing=20
> Vicente here):
>
> * |size|: the number of elements in the ordinal type.
> * |val|: the element in the ordinal type at a given position.
>
> <snip>
> Why do I think we just need size and val?
>
> Because, pos can be implemented in terms of val and size.
> pos is heavily dependent on the enumerators' values (defined by
> the programmer), differently ofval which is based only the number
> of enumerators (counted by the compiler).
> Example: enum X { a =3D -1, b =3D 1000, c =3D 3 };
> What is be best approach to obtain pos(b)? A loop? (which is O(n)
> but very simple for compiler to do) a hash table? a tree? (too
> complex don't you think?), sort+bin search? (hum, no way)
>
I would say that the approach the compiler uses to implement a switch=20
could be a good start.
Vicente
--=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/?hl=3Den.
--------------010903060401080505040702
Content-Type: text/html; charset=ISO-8859-1
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Le 08/02/13 13:38,
<a class="moz-txt-link-abbreviated" href="mailto:ricardofabianodeandrade@gmail.com">ricardofabianodeandrade@gmail.com</a> a écrit :<br>
</div>
<blockquote
cite="mid:477b548e-b7f6-44a4-9fce-1bf7c407d2f8@isocpp.org"
type="cite">
<div>Hi all,</div>
<div><br>
</div>
<div>I have been spending some time thinking about <font
face="courier new, monospace">enum</font>s, reading articles
on the matter (Sutter, Stroustrup) and experiment different
implementations of improvements on the C++ enums (including
Vincente's one).</div>
<div>I feel that we really need 2 small changes in the C++ enums
(citing Vicente here):</div>
<div>
<ul type="disc">
<li><code><font color="#ff0000">size</font></code>: the number
of elements in the ordinal type.</li>
<li><code><font color="#ff0000">val</font></code>: the element
in the ordinal type at a given position.<br>
</li>
</ul>
</div>
<snip><br>
<div><span style="line-height: 17px;">Why do I think we just need
<font color="#ff0000" face="courier new, monospace">size </font>and
<font color="#ff0000" face="courier new, monospace">val</font>?</span></div>
<blockquote style="margin: 0 0 0 40px; border: none; padding:
0px;">
<div><span style="line-height: 17px;">Because</span><font
style="line-height: 17px;" color="#000000">, <font
face="courier new, monospace">pos </font>can be
implemented in terms of <font face="courier new, monospace">val</font> and
<font face="courier new, monospace">size</font>.</font></div>
<div><font style="line-height: 17px;" face="courier new,
monospace">pos </font><span style="line-height: 17px;">is
heavily dependent on the enumerators' values (defined by the
programmer), differently of</span><span style="line-height:
17px;"> </span><font style="line-height: 17px;" face="times
new roman, serif">val </font><span style="line-height:
17px;">which is based only the number of enumerators
(counted by the compiler)</span><span style="line-height:
17px;">.</span></div>
<div><span style="line-height: 17px;">Example: </span><font
style="line-height: 17px;" face="courier new, monospace">enum
X { a = -1, b = 1000, c = 3 };</font></div>
<div><span style="line-height: 17px;">What is be best approach
to obtain </span><font style="line-height: 17px;"
face="courier new, monospace">pos(b)</font><span
style="line-height: 17px;">? A loop? (which is <font
face="courier new, monospace">O(n)</font> but very simple
for compiler to do) a hash table? a tree? (too complex don't
you think?), sort+bin search</span><span style="line-height:
17px;">?</span><span style="line-height: 17px;"> (hum, no
way)</span></div>
</blockquote>
</blockquote>
I would say that the approach the compiler uses to implement a
switch could be a good start. <br>
<br>
Vicente<br>
</body>
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en">http://groups.google.com/a/isocpp.org/group/std-proposals/?hl=en</a>.<br />
<br />
<br />
--------------010903060401080505040702--
.