Re: c/5581: Feaure request for GNU extension to find number of elems in an enum

[Mark Veltzer <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-----