Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #127831 > unrolled thread

enums in structs

Back to article view | Back to comp.lang.c

Contents

  enums in structs bartc <bc@freeuk.com> - 2018-03-15 00:20 +0000
    Re: enums in structs Keith Thompson <kst-u@mib.org> - 2018-03-14 17:57 -0700
      Re: enums in structs supercat@casperkitty.com - 2018-03-14 20:04 -0700
        Re: enums in structs Keith Thompson <kst-u@mib.org> - 2018-03-15 10:19 -0700
      Re: enums in structs Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-14 20:07 -0700
      Re: enums in structs David Brown <david.brown@hesbynett.no> - 2018-03-15 11:36 +0100
    Re: enums in structs Thiago Adams <thiago.adams@gmail.com> - 2018-03-15 05:33 -0700
    Re: enums in structs "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-03-15 05:39 -0700
      Re: enums in structs Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-15 06:35 -0700
    Re: enums in structs jameskuyper@verizon.net - 2018-03-15 06:26 -0700

#127831 — enums in structs

I thought I knew most of the C quirks, but here's another one which I 
don't think I've seen before (perhaps with enum tags, not names):

   typedef struct {enum {red,green,blue} x;} S;

Despite being declared inside the {...} of the struct, the scope of red, 
green and blue belong to the outer scope (the one containing the typedef).

Which also means that:

   typedef struct {enum {red,green,blue} x;} S;
   typedef struct {enum {red,green,blue} x;} T;

won't work, as the names will clash.

The construct cropped up in the new sources of Tiny C, and it didn't 
work (with my compiler) because the use of the enum name (not 'red' but 
somewhat longer) was not recognised. (Silly me, I'd assumed the names 
were local to the struct being declared.)

This appears rather crude behaviour for a language that makes a big deal 
about VLAs and name reuse inside functions via unlimited block scopes.

----------------------------------

(How does my language deal with it? Apparently, much better; enum names 
are properly local; the second example works; but you have to access 
them as S.red or T.red. You don't need (can't) declare the dummy x field.

So I can implement a feature better than C can, without even trying! As 
I wasn't aware this was even possible. I do however understand how 
lexical scope must work)

-- 
bartc

[toc] | [next] | [standalone]

#127834

bartc <bc@freeuk.com> writes:
> I thought I knew most of the C quirks, but here's another one which I 
> don't think I've seen before (perhaps with enum tags, not names):
>
>    typedef struct {enum {red,green,blue} x;} S;

The typedef is irrelevant.  This:

    struct S {
        enum { red, green, blue } x;
    };

illustrates the same thing.

> Despite being declared inside the {...} of the struct, the scope of red, 
> green and blue belong to the outer scope (the one containing the typedef).

Not all curly braces define scopes.  Take a look at N1570 6.2.1 "Scopes
of identifiers".  There's no such thing as "struct scope".  The only
scopes are:

- Function scope (applies only to labels)
- File scope
- Block scope (refers to a block / compound statement)
- Function prototype scope (not often used)

Note that the member name "x" also has a wider scope than the struct.
But member names always have to be prefixed with "s." or "p->".

> Which also means that:
>
>    typedef struct {enum {red,green,blue} x;} S;
>    typedef struct {enum {red,green,blue} x;} T;
>
> won't work, as the names will clash.

Right.

If "red", "green", and "blue" had scopes restricted to the struct
definition, you wouldn't be able to refer to their names outside the
struct definition.  C has no mechanism for prefixing an enumeration
constant with the name of a type.

(You'd usually want to define the enum type separately -- or at least I
would.)

[...]

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#127836

On Wednesday, March 14, 2018 at 7:57:16 PM UTC-5, Keith Thompson wrote:
> If "red", "green", and "blue" had scopes restricted to the struct
> definition, you wouldn't be able to refer to their names outside the
> struct definition.  C has no mechanism for prefixing an enumeration
> constant with the name of a type.

You can't refer to their names outside the context of an object of the
appropriate structure type.  There are times it would be helpful to
make names of aggregate members available in the enclosing context.
The usefulness of anonymous structs and unions is somewhat undermined
by the fact that there is no way within a structure to refer to a subset
of members as a group while being able to also treat them individually
as members of the outer group.  IMHO, there was a missed opportunity
to allow an "extern" qualifier on a struct member to serve as an
indication that the names should be exported to the enclosing context.
That would allow e.g.

    struct point { int x,y; };
    struct grafObj { struct point extern position; int color; };
    struct grafObj myObj;

    myObj.pt = objectOfTypePoint;
    myObj.x++; // shorthand for myObj.position.x++;

As it is, C11 allows a struct within another struct to export its
members, but only if there's no way to treat that struct as a unit.
Consequently, the only thing that feature is good for is making
struct/union hybrids whose semantics end up being dodgy because C11
lacks any meaningful rules about when struct and union members of
non-character types can be used as lvalues.

[toc] | [prev] | [next] | [standalone]

#127877

supercat@casperkitty.com writes:
> On Wednesday, March 14, 2018 at 7:57:16 PM UTC-5, Keith Thompson wrote:
>> If "red", "green", and "blue" had scopes restricted to the struct
>> definition, you wouldn't be able to refer to their names outside the
>> struct definition.  C has no mechanism for prefixing an enumeration
>> constant with the name of a type.
>
> You can't refer to their names outside the context of an object of the
> appropriate structure type.

Look back at the example (which you snipped, of course).  "red",
"green", and "blue" are enumeration constants, not member names.

[SNIP]

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#127837

On Wednesday, March 14, 2018 at 5:57:16 PM UTC-7, Keith Thompson wrote:
> bartc <bc@freeuk.com> writes:
> > I thought I knew most of the C quirks, but here's another one which I 
> > don't think I've seen before (perhaps with enum tags, not names):
> >
> >    typedef struct {enum {red,green,blue} x;} S;
> 
> The typedef is irrelevant.  This:
> 
>     struct S {
>         enum { red, green, blue } x;
>     };
> 
> illustrates the same thing.
> 
> > Despite being declared inside the {...} of the struct, the scope of red, 
> > green and blue belong to the outer scope (the one containing the typedef).
> 
> Not all curly braces define scopes.  Take a look at N1570 6.2.1 "Scopes
> of identifiers".  There's no such thing as "struct scope".  The only
> scopes are:
> 
> - Function scope (applies only to labels)
> - File scope
> - Block scope (refers to a block / compound statement)
> - Function prototype scope (not often used)
> 
> Note that the member name "x" also has a wider scope than the struct.
> But member names always have to be prefixed with "s." or "p->".
> 
> > Which also means that:
> >
> >    typedef struct {enum {red,green,blue} x;} S;
> >    typedef struct {enum {red,green,blue} x;} T;
> >
> > won't work, as the names will clash.
> 
> Right.
> 
> If "red", "green", and "blue" had scopes restricted to the struct
> definition, you wouldn't be able to refer to their names outside the
> struct definition.  C has no mechanism for prefixing an enumeration
> constant with the name of a type.
> 
> (You'd usually want to define the enum type separately -- or at least I
> would.)
> 
> [...]
> 
> -- 
> Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
> Working, but not speaking, for JetHead Development, Inc.
> "We must do something.  This is something.  Therefore, we must do this."
>     -- Antony Jay and Jonathan Lynn, "Yes Minister"



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512


- --
sex n 
1. either of the two reproductive categories, male or female, of animals  and plants 
2. sexual intercourse 
3. sexual activity or behavior leading to it 
4. the genitals (literary) 
5. the set of characteristics that determine whether the reproductive role of an animal or plant is male or female 
- --

And, notably, Snit wrote:
"Sex is a subset of sexual activities" - Snit - (I guess he didn't comprehend point 3 very well) 

Of course, he also wrote:
"Sexual activities are sex by definition, you moron" - Snit 

And this:
"A passionate kiss could be called a "sexual activity" but it is not sex" 

In Snit's world, a passionate kiss is not sex... but it is sex. LOL!

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJVRYvKAAoJEC03b6bOr/+dgbUP/icm7kQOjm2kSNou+JmBBgHb
A4tmqQKGn3RwkS88wbmhuGrc7bj+Mn0olYmozNufRMG1hB+cjJR/a3K4qEN+hZP7
6KNdfvYKxSOcdtrsYEezCOPK6yu9tlwspR5w61vMaEWxmGX8CZ8FuZWnZhiul1CA
WXRpPDK8GJnWecK7wqDw8wJCKu4ENRw0AUTFWdmmGIUO1n3x/NSbCXIftMop4MBd
9NHP3v26pA5NB9tlh//BtQa8Ys03DASuViFd1VRgtuL4wSnctDDLUE4zQGp+GcS7
DOhjROy9ExDGqer4uLwPwDD59eUef8s4WI/XRivl2uQSl7rs/XWKw4OStOzXajGX
EMcJ4c9zPjtwKB2F781+U3DH2l9YLBii/UZCpgcblvvuXSb/b/7D64AxpzvEfPpZ
TTq/OcOEDsbhaOijEdELMw/IjuQ+Pp+5cMEOey7BK3uPAjr8gOLU0xmChJimNP8r
o9RzphsO8O+mJMK0sdke9FEJByCgX3LbJYro21v0ZS0Nt2JW16Z8VakHNKfUbuLg
IYHbShHiEQ1GCWOQ+AIfpwG6td/NE/EhiCE9OixWAsvGq6e0w4k7vARG8hSfZDpp
3hp7rD8x9EVp4v4e7G34Wr6FIZlfYzD2fX6SRu9wYpG/v87sgvrN9klY1YLn/zig
oZmOKJM5cC0iwnvHsavO
=4yFU
-----END PGP SIGNATURE-----

- 
Puppy Videos!!
https://youtu.be/iztSc_msHuo
https://groups.google.com/forum/#!topic/comp.sys.mac.advocacy/RSikBcWxBLo
Jonas Eklundh

[toc] | [prev] | [next] | [standalone]

#127855

On 15/03/18 01:57, Keith Thompson wrote:
> bartc <bc@freeuk.com> writes:
>> I thought I knew most of the C quirks, but here's another one which I 
>> don't think I've seen before (perhaps with enum tags, not names):
>>
>>    typedef struct {enum {red,green,blue} x;} S;
> 
> The typedef is irrelevant.  This:
> 
>     struct S {
>         enum { red, green, blue } x;
>     };
> 
> illustrates the same thing.
> 
>> Despite being declared inside the {...} of the struct, the scope of red, 
>> green and blue belong to the outer scope (the one containing the typedef).
> 
> Not all curly braces define scopes.  Take a look at N1570 6.2.1 "Scopes
> of identifiers".  There's no such thing as "struct scope".  The only
> scopes are:
> 
> - Function scope (applies only to labels)
> - File scope
> - Block scope (refers to a block / compound statement)
> - Function prototype scope (not often used)
> 
> Note that the member name "x" also has a wider scope than the struct.
> But member names always have to be prefixed with "s." or "p->".
> 
>> Which also means that:
>>
>>    typedef struct {enum {red,green,blue} x;} S;
>>    typedef struct {enum {red,green,blue} x;} T;
>>
>> won't work, as the names will clash.
> 
> Right.
> 
> If "red", "green", and "blue" had scopes restricted to the struct
> definition, you wouldn't be able to refer to their names outside the
> struct definition.  

Further, if the brackets in "enum { red, green, blue }" introduced a
scope, you wouldn't be able to use any enum constants anywhere!

> C has no mechanism for prefixing an enumeration
> constant with the name of a type.

Yes.  In general, C has quite limited flexibility for name scoping and
prefixing.  The usual solution is to use constants named "colour_red",
or with a similar manual prefix on the identifier.

(Cue the obligatory comment about C++ namespaces and enum classes, to be
found across the hall.)

> 
> (You'd usually want to define the enum type separately -- or at least I
> would.)
> 
> [...]
> 

[toc] | [prev] | [next] | [standalone]

#127861

On Wednesday, March 14, 2018 at 9:20:30 PM UTC-3, Bart wrote:
> I thought I knew most of the C quirks, but here's another one which I 
> don't think I've seen before (perhaps with enum tags, not names):
> 
>    typedef struct {enum {red,green,blue} x;} S;
> 
> Despite being declared inside the {...} of the struct, the scope of red, 
> green and blue belong to the outer scope (the one containing the typedef).
> 
> Which also means that:
> 
>    typedef struct {enum {red,green,blue} x;} S;
>    typedef struct {enum {red,green,blue} x;} T;
> 
> won't work, as the names will clash.
> 
> The construct cropped up in the new sources of Tiny C, and it didn't 
> work (with my compiler) because the use of the enum name (not 'red' but 
> somewhat longer) was not recognised. (Silly me, I'd assumed the names 
> were local to the struct being declared.)
> 
> This appears rather crude behaviour for a language that makes a big deal 
> about VLAs and name reuse inside functions via unlimited block scopes.
> 
> ----------------------------------
> 
> (How does my language deal with it? Apparently, much better; enum names 
> are properly local; the second example works; but you have to access 
> them as S.red or T.red. You don't need (can't) declare the dummy x field.
> 
> So I can implement a feature better than C can, without even trying! As 
> I wasn't aware this was even possible. I do however understand how 
> lexical scope must work)
> 
> -- 
> bartc

These rules also make C and C++ incompatible.

For instance, this sample is valid in C, but not C++.

struct X
{
    struct Y {
        int i;
    } y;
};

int main()
{
    struct X x;
    struct Y y;
}

In C++, Y is accessed using X::Y.

[toc] | [prev] | [next] | [standalone]

#127863

On Wednesday, March 14, 2018 at 8:20:30 PM UTC-4, Bart wrote:
> I thought I knew most of the C quirks, but here's another one which I 
> don't think I've seen before (perhaps with enum tags, not names):
> 
>    typedef struct {enum {red,green,blue} x;} S;
> 
> Despite being declared inside the {...} of the struct, the scope of red, 
> green and blue belong to the outer scope (the one containing the typedef).
> 
> Which also means that:
> 
>    typedef struct {enum {red,green,blue} x;} S;
>    typedef struct {enum {red,green,blue} x;} T;
> 
> won't work, as the names will clash.
> 
> The construct cropped up in the new sources of Tiny C, and it didn't 
> work (with my compiler) because the use of the enum name (not 'red' but 
> somewhat longer) was not recognised. (Silly me, I'd assumed the names 
> were local to the struct being declared.)
> 
> This appears rather crude behaviour for a language that makes a big deal 
> about VLAs and name reuse inside functions via unlimited block scopes.
> 
> ----------------------------------
> 
> (How does my language deal with it? Apparently, much better; enum names 
> are properly local; the second example works; but you have to access 
> them as S.red or T.red. You don't need (can't) declare the dummy x field.
> 
> So I can implement a feature better than C can, without even trying! As 
> I wasn't aware this was even possible. I do however understand how 
> lexical scope must work)
> 
> -- 
> bartc

I agree the enum should be scoped.  If there were ever a name
collision the developer could use the scope modifier to hone it
down.

But, I also think it should be contextually aware.  If I'm refer-
encing something that relates to that structure, then use the
local name scope enum by default, and possibly generate a diagnostic
on the assumption, but it shouldn't require rocket science to nail
these things down... just common sense.

-- 
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#127866

On Thursday, March 15, 2018 at 5:39:12 AM UTC-7, Rick C. Hodgin wrote:
> On Wednesday, March 14, 2018 at 8:20:30 PM UTC-4, Bart wrote:
> > I thought I knew most of the C quirks, but here's another one which I 
> > don't think I've seen before (perhaps with enum tags, not names):
> > 
> >    typedef struct {enum {red,green,blue} x;} S;
> > 
> > Despite being declared inside the {...} of the struct, the scope of red, 
> > green and blue belong to the outer scope (the one containing the typedef).
> > 
> > Which also means that:
> > 
> >    typedef struct {enum {red,green,blue} x;} S;
> >    typedef struct {enum {red,green,blue} x;} T;
> > 
> > won't work, as the names will clash.
> > 
> > The construct cropped up in the new sources of Tiny C, and it didn't 
> > work (with my compiler) because the use of the enum name (not 'red' but 
> > somewhat longer) was not recognised. (Silly me, I'd assumed the names 
> > were local to the struct being declared.)
> > 
> > This appears rather crude behaviour for a language that makes a big deal 
> > about VLAs and name reuse inside functions via unlimited block scopes.
> > 
> > ----------------------------------
> > 
> > (How does my language deal with it? Apparently, much better; enum names 
> > are properly local; the second example works; but you have to access 
> > them as S.red or T.red. You don't need (can't) declare the dummy x field.
> > 
> > So I can implement a feature better than C can, without even trying! As 
> > I wasn't aware this was even possible. I do however understand how 
> > lexical scope must work)
> > 
> > -- 
> > bartc
> 
> I agree the enum should be scoped.  If there were ever a name
> collision the developer could use the scope modifier to hone it
> down.
> 
> But, I also think it should be contextually aware.  If I'm refer-
> encing something that relates to that structure, then use the
> local name scope enum by default, and possibly generate a diagnostic
> on the assumption, but it shouldn't require rocket science to nail
> these things down... just common sense.
> 
> -- 
> Rick C. Hodgin



Facts about Steve "Steven Petruzzellis" Carroll

Steve "Steven Petruzzellis" Carroll is a nearly 60 year old guy who is single, broke and has no skills. He blames Rob 'The Shill' Speed for his loss of his wife and girlfriend. Steven is jealous of what Rob 'The Shill' Speed has and in a narcissistic rage repeatedly works to take it away from him. For over 10 years he has failed at even this. Steve "Steven Petruzzellis" Carroll is an utter failure in life.

Of his online life Steven says

    I've been booted off by past providers before because people
    complain about me and all my bullshit. I don't want to lose my ISP
    *again* but I still need my army of sock puppets so I continually
    search usenet for whatever servers I haven't yet been booted
    from.
    
Some examples where Steven has been booted

X10 Hosting booted Steven for inappropriate activity
http://tinyurl.com/z92qmz4

Comcast booted Steven for inappropriate activity 
http://tinyurl.com/h75nh9l

FreeHostingEU booted Steven for copyright infringement http://devsite.eu.pn

AwardSpace (atwebpages.com) booted Steven for breaking terms of service
http://demsites.atwebpages.com/pokeman

Imgur took down an image for breaking terms of service http://imgur.com/yv2XppE

Had a GigaNews account which was removed for harassing Rob 'The Shill' Speed

Stopped posting from his fretwizzen Google account since shortly after I complained. Seems he lost that too.

His wife booted Steven to the curb for cheating on her


    
Only site Steven Petruzzellis has pointed to that has ever been available
http://web.archive.org/web/20161019062351/http://www.oldneighborhoodrestaurant.net/
https://goo.gl/DMno6J

Made by the Go Daddy Website builder and is utter crap. Later he denied he said he was merely taking credit for someone else's work but Steven is the contact person http://tinyurl.com/hcw6dul
http://web.archive.org/web/20161202192456/http://www.reservationdiary.eu/eng/reservation/d76d1156-e9f7-43c1-b77b-b07189857820

He also bragged he was working on an update and showed it here https://vid.me/u6RK

The business still failed.

He likely went to the Go Daddy Website Builder after he failed to get WordPress installed.

https://mu.wordpress.org/forums/topic/13879


This is why Steve "Steven Petruzzellis" Carroll attacks Rob 'The Shill' Speed. 


Steven Petruzzellis was is divorced because his wife caught him screwing another woman.

Rob 'The Shill' Speed is married and by all appearances happily so. 
He never complains about his wife in COLA.


Steven Petruzzellis is living on charity of a friend in a single room.

Rob 'The Shill' Speed does not live in a mansion or even a high end home but has a house and a yard.


Steven Petruzzellis has two kids but no respect. He repeatedly called Ryan his "little screwup" and refers to his son Steve as a "dick" and worse. He says at least one of them likely hacked his computer and is a "mentally deficient child." He mocks his possible future daughter-in-law as someone who takes too many selfies and is focused only on herself

Rob 'The Shill' Speed has two kids (or more) and never speaks poorly of them in public. 
No reason to think they are not a happy family.


Steven Petruzzellis claims to be a stay at home dad who pays thousands of dollars for day care. Steven has no job and no purpose in life. Steven has given up and now seeks a mother-figure to date. 

Rob 'The Shill' Speed has his own business doing technical work and also teaches. 
Rob 'The Shill' Speed offers a true contribution to society. 
Teachers are truly under appreciated.

--
Do not click this link!!
https://youtu.be/E3m_i-x92D0
Jonas Eklundh Communication

[toc] | [prev] | [next] | [standalone]

#127865

On Wednesday, March 14, 2018 at 8:20:30 PM UTC-4, Bart wrote:
> I thought I knew most of the C quirks, but here's another one which I 
> don't think I've seen before (perhaps with enum tags, not names):
> 
>    typedef struct {enum {red,green,blue} x;} S;
> 
> Despite being declared inside the {...} of the struct, the scope of red, 
> green and blue belong to the outer scope (the one containing the typedef).

The general rule in C is that, in just about any location where you can
specify a type, that type can be a user-defined type (enum, union,
struct) that is defined for the very first time, in that declaration.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c

csiph-web