This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: c/5581: Feaure request for GNU extension to find number of elems in an enum
- From: Mark Veltzer <mark2776 at yahoo dot com>
- To: nathan at gcc dot gnu dot org, gcc-bugs at gcc dot gnu dot org, gcc-prs at gcc dot gnu dot org, mark2776 at yahoo dot com, nobody at gcc dot gnu dot org, gcc-gnats at gcc dot gnu dot org
- Date: Tue, 5 Feb 2002 22:46:10 +0200
- Subject: Re: c/5581: Feaure request for GNU extension to find number of elems in an enum
- Organization: Meta Ltd.
- References: <20020205102331.22696.qmail@sources.redhat.com>
- Reply-to: mark2776 at yahoo dot com
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Tuesday 05 February 2002 12:23, you wrote:
> Synopsis: Feaure request for GNU extension to find number of elems in an
> enum
>
> State-Changed-From-To: open->closed
> State-Changed-By: nathan
> State-Changed-When: Tue Feb 5 02:23:31 2002
> State-Changed-Why:
> The normal idiom for what you want is
> enum {red, green, num_elems};
> BTW, how many elements do you consider there are in
> enum {red, green =-2, blue, pink};
> ?
I consider it to be 4 elements (as there are 4 elements in the hash that the
compiler stores at compile time).
Lets assume that I do have enum {red, green =-2, blue, pink} and I want to
allocate a string for each. How many strings do I need to allocate ? Beats
me. But the info is there. The compiler knows it. It just keeps it secret.
Don't think about traditional compilers - if anything - history shows that
they didn't know what they were doing. If you want to state that this is
a GNU only extension you can do it - but don't claim that the semantics are
not clear. I want to state the semantics again:
numberof(enum_type)= [number of elements the compiler has in it's
compile time hash for enum_type]
NOT - last element index+1
NOT - highest element index
There is nothing unsound about this semantic interpretation and everyone
will understand it the same way. And yes, I fully understand that users who
do not understand the implications of using a non sequential enumeration
combined with this extension could shoot themselves in the leg. but they could
easily do this with (char*)0=0. Since when did C prevent you from doing
things in order to protect you ? Users who don't understand should not
program. Very simple.
How many elements do you consider there are in:
enum {red, green=-2,blue,pink,num_elems} ?!?
I don't understand this attitude - the compiler has the info - why not just
give it ? hiding information in computer software engineering is very bad.
Languages and systems that flurish aren't the ones that hide info from users
but rather the ones that let the users have all the info. Some of the users
use info that they better not use and shoot themselves in the leg. That's
their prerogative. Some of the users will do nice things with the information.
That is also their prerogative. Denying the users the info on some theoretical
ground doens't sound right. There is no runtime overhead. There is no
semantic murky ground. The info is readily available. There is actually no
theoretical ground for denying this except the old - "but brian and dennis
didn't think of this" argument. Well - they didn't think of half the
extensions in todays gcc either...:) (did they think of typeof ? could a user
shoot himself in the leg using typeof if he didn't understand the implications
correctly in C++ ? I think so...).
You may deny the request again but I'm developing my own patch to do this.
There are several large projects that I know that could cut down their
insistance that enumerated values be sequential from 0 if they had this
feature and save code - or isn't this what we all want ?
Regards,
Mark
>
> http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&
>pr=5581
- --
Name: Mark Veltzer
Title: Research and Development
Company: Meta Ltd.
Address: Habikaa 17/3, Kiriat Sharet
City: Holon
Zip code: 58495
County: Gush-Dan
Country: Israel
Home Phone: +972-3-5508163
Business Phone: +972-3-5508163
Extension: none
Fax: +972-3-5508163
Mobile: +972-53-514132
Email: mailto:mark2776@yahoo.com
Icq: 25787273
Aol: mark2776
Yahoo: mark2776
Homepage: http://www.geocities.com/mark2776
CPAN id: VELTZER (http://cpan.org)
SourceForge id: veltzer (http://www.sourceforge.net)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE8YESa2mxGJGQAmakRAtUfAJ0Rm/9Iir1wHtvRQL4dKmHz7OiwyACeNJv4
2UiXM1x9XZPDe0RBl5mmoKo=
=aMqQ
-----END PGP SIGNATURE-----