public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
* Re: c/5581: Feaure request for GNU extension to find number of elems in an enum
@ 2002-02-05  2:23 nathan
  0 siblings, 0 replies; 3+ messages in thread
From: nathan @ 2002-02-05  2:23 UTC (permalink / raw)
  To: gcc-bugs, gcc-prs, mark2776, nobody

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};
    ?

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=5581


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: c/5581: Feaure request for GNU extension to find number of elems in an enum
@ 2002-02-05 12:46 Mark Veltzer
  0 siblings, 0 replies; 3+ messages in thread
From: Mark Veltzer @ 2002-02-05 12:46 UTC (permalink / raw)
  To: nobody; +Cc: gcc-prs

The following reply was made to PR c/5581; it has been noted by GNATS.

From: Mark Veltzer <mark2776@yahoo.com>
To: nathan@gcc.gnu.org, gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org,
        mark2776@yahoo.com, nobody@gcc.gnu.org, gcc-gnats@gcc.gnu.org
Cc:  
Subject: Re: c/5581: Feaure request for GNU extension to find number of elems in an enum
Date: Tue, 5 Feb 2002 22:46:10 +0200

 -----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-----


^ permalink raw reply	[flat|nested] 3+ messages in thread

* c/5581: Feaure request for GNU extension to find number of elems in an enum
@ 2002-02-04 11:06 mark2776
  0 siblings, 0 replies; 3+ messages in thread
From: mark2776 @ 2002-02-04 11:06 UTC (permalink / raw)
  To: gcc-gnats


>Number:         5581
>Category:       c
>Synopsis:       Feaure request for GNU extension to find number of elems in an enum
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    unassigned
>State:          open
>Class:          support
>Submitter-Id:   net
>Arrival-Date:   Mon Feb 04 11:06:02 PST 2002
>Closed-Date:
>Last-Modified:
>Originator:     mark2776@yahoo.com
>Release:        gcc-2.95.3
>Organization:
>Environment:

>Description:
I'd like to be able to get compile time information about the
size of an enum. For instance:
enum _enum_type {
	ONE,
	TWO
};
int t=numberof(_enum_type);
will make t=2

I fully understand that I have to use this information correctly
since there may be gaps in the enumeration but the fact that I
could shoot myself in the leg with this is not a reason not to
give this to me (with correct programming I could do good stuff
with this too...).
The same goes for unions.

Other possible attributes could be:
- lastof(enum_type) = the value of the last element.
- firstof(enum_type) = the value of the first element.
>How-To-Repeat:

>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted:


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2002-02-05 20:46 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-02-05  2:23 c/5581: Feaure request for GNU extension to find number of elems in an enum nathan
  -- strict thread matches above, loose matches on Subject: below --
2002-02-05 12:46 Mark Veltzer
2002-02-04 11:06 mark2776

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).