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

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

C Names and Scopes

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

Contents

  C Names and Scopes BartC <bc@freeuk.com> - 2017-02-08 02:13 +0000
    Re: C Names and Scopes David Brown <david.brown@hesbynett.no> - 2017-02-08 10:09 +0100
      Re: C Names and Scopes mark.bluemel@gmail.com - 2017-02-08 02:37 -0800
        Re: C Names and Scopes BartC <bc@freeuk.com> - 2017-02-08 11:07 +0000
          Re: C Names and Scopes fir <profesor.fir@gmail.com> - 2017-02-08 09:03 -0800
            Re: C Names and Scopes BartC <bc@freeuk.com> - 2017-02-08 17:19 +0000
              Re: C Names and Scopes fir <profesor.fir@gmail.com> - 2017-02-08 09:42 -0800
        Re: C Names and Scopes David Brown <david.brown@hesbynett.no> - 2017-02-08 12:08 +0100
      Re: C Names and Scopes Moai <penultimategrill@gmail.com> - 2017-02-08 19:16 -0500
        Re: C Names and Scopes David Brown <david.brown@hesbynett.no> - 2017-02-09 01:32 +0100
        Re: C Names and Scopes Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-09 08:18 -0800
        Re: C Names and Scopes Jerry Stuckle <jstucklex@attglobal.net> - 2017-02-09 12:06 -0500
    Re: C Names and Scopes BartC <bc@freeuk.com> - 2017-02-08 10:51 +0000
    Re: C Names and Scopes Thiago Adams <thiago.adams@gmail.com> - 2017-02-08 03:11 -0800
      Re: C Names and Scopes BartC <bc@freeuk.com> - 2017-02-08 11:39 +0000
        Re: C Names and Scopes BartC <bc@freeuk.com> - 2017-02-08 12:06 +0000
          Re: C Names and Scopes BartC <bc@freeuk.com> - 2017-02-08 13:31 +0000
          Re: C Names and Scopes BartC <bc@freeuk.com> - 2017-02-08 13:40 +0000
            Re: C Names and Scopes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-08 16:39 +0000
              Re: C Names and Scopes BartC <bc@freeuk.com> - 2017-02-08 17:51 +0000
                Re: C Names and Scopes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-08 20:56 +0000
                  Re: C Names and Scopes BartC <bc@freeuk.com> - 2017-02-08 22:08 +0000
                    Re: C Names and Scopes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-08 23:27 +0000
        Re: C Names and Scopes David Brown <david.brown@hesbynett.no> - 2017-02-08 13:41 +0100
        Re: C Names and Scopes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-08 14:32 +0000
          Re: C Names and Scopes supercat@casperkitty.com - 2017-02-08 07:28 -0800
            Re: C Names and Scopes BartC <bc@freeuk.com> - 2017-02-08 20:12 +0000
              Re: C Names and Scopes Keith Thompson <kst-u@mib.org> - 2017-02-08 12:38 -0800
                Re: C Names and Scopes BartC <bc@freeuk.com> - 2017-02-08 21:54 +0000
                  Re: C Names and Scopes BartC <bc@freeuk.com> - 2017-02-08 22:40 +0000
    Re: C Names and Scopes BartC <bc@freeuk.com> - 2017-02-09 18:48 +0000
      Re: C Names and Scopes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-09 19:53 +0000
        Re: C Names and Scopes Keith Thompson <kst-u@mib.org> - 2017-02-09 12:25 -0800
          Re: C Names and Scopes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-09 21:27 +0000
            Re: C Names and Scopes Keith Thompson <kst-u@mib.org> - 2017-02-09 13:57 -0800
              Re: C Names and Scopes David Brown <david.brown@hesbynett.no> - 2017-02-13 10:54 +0100
          Re: C Names and Scopes BartC <bc@freeuk.com> - 2017-02-10 00:26 +0000
            Re: C Names and Scopes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-10 00:42 +0000
              Re: C Names and Scopes BartC <bc@freeuk.com> - 2017-02-10 01:03 +0000
                Re: C Names and Scopes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-10 01:49 +0000
                  Re: C Names and Scopes BartC <bc@freeuk.com> - 2017-02-10 12:31 +0000
                    Re: C Names and Scopes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-10 23:48 +0000
                      Re: C Names and Scopes supercat@casperkitty.com - 2017-02-10 16:06 -0800
                        Re: C Names and Scopes Keith Thompson <kst-u@mib.org> - 2017-02-10 16:22 -0800
                          Re: C Names and Scopes supercat@casperkitty.com - 2017-02-12 09:17 -0800
                          Re: C Names and Scopes Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-15 16:26 -0800
                Re: C Names and Scopes Keith Thompson <kst-u@mib.org> - 2017-02-09 17:56 -0800
                Re: C Names and Scopes supercat@casperkitty.com - 2017-02-10 07:42 -0800
                  Re: C Names and Scopes Keith Thompson <kst-u@mib.org> - 2017-02-10 08:44 -0800
                    Re: C Names and Scopes supercat@casperkitty.com - 2017-02-10 09:25 -0800
                    Re: C Names and Scopes Jerry Stuckle <jstucklex@attglobal.net> - 2017-02-10 16:43 -0500
                      Re: C Names and Scopes supercat@casperkitty.com - 2017-02-10 14:04 -0800
                        Re: C Names and Scopes BartC <bc@freeuk.com> - 2017-02-10 22:52 +0000
                          Re: C Names and Scopes Andrey Tarasevich <andreytarasevich@hotmail.com> - 2017-02-10 15:10 -0800
          Re: C Names and Scopes Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-15 16:31 -0800
        Re: C Names and Scopes BartC <bc@freeuk.com> - 2017-02-09 23:09 +0000
          Re: C Names and Scopes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-09 23:36 +0000
            Re: C Names and Scopes BartC <bc@freeuk.com> - 2017-02-10 00:19 +0000
              Re: C Names and Scopes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-10 00:38 +0000
    Re: C Names and Scopes BartC <bc@freeuk.com> - 2017-03-04 01:23 +0000
      Re: C Names and Scopes jameskuyper@verizon.net - 2017-03-03 18:23 -0800
        Re: C Names and Scopes GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-04 14:42 +0100
          Re: C Names and Scopes "James R. Kuyper" <jameskuyper@verizon.net> - 2017-03-04 11:02 -0500
            Re: C Names and Scopes GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-04 23:35 +0100
              Re: C Names and Scopes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-03-04 14:50 -0800
              Re: C Names and Scopes Richard Heathfield <rjh@cpax.org.uk> - 2017-03-05 13:39 +0000
                Re: C Names and Scopes GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-05 15:10 +0100
                  Re: C Names and Scopes Richard Heathfield <rjh@cpax.org.uk> - 2017-03-05 14:34 +0000
                  Re: C Names and Scopes Keith Thompson <kst-u@mib.org> - 2017-03-05 19:25 -0800
                Re: C Names and Scopes raltbos@xs4all.nl (Richard Bos) - 2017-03-06 09:37 +0000
                  Re: C Names and Scopes Richard Heathfield <rjh@cpax.org.uk> - 2017-03-06 10:34 +0000
                  Re: C Names and Scopes James Kuyper <jameskuyper@verizon.net> - 2017-03-06 07:23 -0500
                    Re: C Names and Scopes GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-06 14:26 +0100
      Re: C Names and Scopes Keith Thompson <kst-u@mib.org> - 2017-03-04 11:52 -0800
        Re: C Names and Scopes BartC <bc@freeuk.com> - 2017-03-04 20:13 +0000
          Re: C Names and Scopes BartC <bc@freeuk.com> - 2017-03-04 20:17 +0000
          Re: C Names and Scopes Keith Thompson <kst-u@mib.org> - 2017-03-04 12:38 -0800
          Re: C Names and Scopes jameskuyper@verizon.net - 2017-03-04 13:50 -0800
            Re: C Names and Scopes BartC <bc@freeuk.com> - 2017-03-04 22:37 +0000
              Re: C Names and Scopes jameskuyper@verizon.net - 2017-03-04 16:15 -0800
                Re: C Names and Scopes BartC <bc@freeuk.com> - 2017-03-05 00:31 +0000
                  Re: C Names and Scopes jameskuyper@verizon.net - 2017-03-04 16:47 -0800
                    Re: C Names and Scopes BartC <bc@freeuk.com> - 2017-03-05 01:42 +0000
                      Re: C Names and Scopes jameskuyper@verizon.net - 2017-03-04 19:20 -0800
                      Re: C Names and Scopes Keith Thompson <kst-u@mib.org> - 2017-03-05 01:40 -0800

Page 4 of 5 — ← Prev page 1 2 3 [4] 5  Next page →

#105364

On Friday, March 3, 2017 at 8:23:14 PM UTC-5, Bart wrote:
...
> Does this mean that struct tag names declared inside other structs don't 
> have a scope constrained by the immediate enclosing struct, but by 
> either file-scope or by a normal block-scope?

Correct. C++ added the concept of class scope; there is no corresponding C concept.

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

#105372

On Fri, 3 Mar 2017 18:23:45 -0800 (PST)
jameskuyper@verizon.net wrote:

> On Friday, March 3, 2017 at 8:23:14 PM UTC-5, Bart wrote:
> ...
> > Does this mean that struct tag names declared inside other structs don't 
> > have a scope constrained by the immediate enclosing struct, but by 
> > either file-scope or by a normal block-scope?
> 
> Correct. C++ added the concept of class scope; there is no corresponding C concept.

Indeed, the class concept is for unskilled C programmers such as CS students or professors. :o)

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

#105377

On 03/04/2017 08:42 AM, GOTHIER Nathan wrote:
...
> Indeed, the class concept is for unskilled C programmers such as CS students or professors. :o)

Arguing against a given point of view by insulting the people who hold 
it is a very weak argument. Choosing that argument implies that all of 
your other arguments are even weaker. "insulting" someone by pointing 
out that they've studied the issue more carefully than you have is 
positively counter-productive.
In general, you've given the impression of being someone with strong but 
poorly-justified opinions, who's willing to insult anyone who doesn't 
share those opinions. Is that the image you want to project?

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

#105394

On Sat, 4 Mar 2017 11:02:35 -0500
"James R. Kuyper" <jameskuyper@verizon.net> wrote:

> Arguing against a given point of view by insulting the people who hold 
> it is a very weak argument. Choosing that argument implies that all of 
> your other arguments are even weaker. "insulting" someone by pointing 
> out that they've studied the issue more carefully than you have is 
> positively counter-productive.
> In general, you've given the impression of being someone with strong but 
> poorly-justified opinions, who's willing to insult anyone who doesn't 
> share those opinions. Is that the image you want to project?

I was joking on the words "class", "student" and "professor" but actually I
don't care if you felt insulted about this after vomiting your so-called
smartness about a C++ feature, even more deeming uneducated each individual who
don't share your point. Bullying people like this exhibit your own intellectual
weakness...

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

#105395

On Saturday, March 4, 2017 at 10:37:49 PM UTC, GOTHIER Nathan wrote:
> On Sat, 4 Mar 2017 11:02:35 -0500
> "James R. Kuyper" <jameskuyper@verizon.net> wrote:
> 
> > Arguing against a given point of view by insulting the people who hold 
> > it is a very weak argument. Choosing that argument implies that all of 
> > your other arguments are even weaker. "insulting" someone by pointing 
> > out that they've studied the issue more carefully than you have is 
> > positively counter-productive.
> > In general, you've given the impression of being someone with strong but 
> > poorly-justified opinions, who's willing to insult anyone who doesn't 
> > share those opinions. Is that the image you want to project?
> 
> I was joking on the words "class", "student" and "professor" but 
> actually I don't care if you felt insulted about this after vomiting
> your so-called smartness about a C++ feature, even more deeming 
> uneducated each individual who don't share your point. Bullying people
> like this exhibit your own intellectual weakness...
>
The polite response to that would have been a "whoosh" - the point goes
over the respondent's head.

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

#105418

On 04/03/17 22:35, GOTHIER Nathan wrote:
> On Sat, 4 Mar 2017 11:02:35 -0500
> "James R. Kuyper" <jameskuyper@verizon.net> wrote:
>
>> Arguing against a given point of view by insulting the people who hold
>> it is a very weak argument. Choosing that argument implies that all of
>> your other arguments are even weaker. "insulting" someone by pointing
>> out that they've studied the issue more carefully than you have is
>> positively counter-productive.
>> In general, you've given the impression of being someone with strong but
>> poorly-justified opinions, who's willing to insult anyone who doesn't
>> share those opinions. Is that the image you want to project?
>
> I was joking on the words "class", "student" and "professor" but actually I
> don't care if you felt insulted about this after vomiting your so-called
> smartness about a C++ feature, even more deeming uneducated each individual who
> don't share your point. Bullying people like this exhibit your own intellectual
> weakness...

You are confusing "reasoning on logical grounds" with "bullying". They 
don't mean the same thing. Are you trying to give people reasons to 
filter out your articles?

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

#105422

On Sun, 5 Mar 2017 13:39:07 +0000
Richard Heathfield <rjh@cpax.org.uk> wrote:

> You are confusing "reasoning on logical grounds" with "bullying". They 
> don't mean the same thing. Are you trying to give people reasons to 
> filter out your articles?

If you can't bear democracy just go back to your cave... since it seems that's
the only logic you're able to understand.

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

#105426

On 05/03/17 14:10, GOTHIER Nathan wrote:
> On Sun, 5 Mar 2017 13:39:07 +0000
> Richard Heathfield <rjh@cpax.org.uk> wrote:
>
>> You are confusing "reasoning on logical grounds" with "bullying". They
>> don't mean the same thing. Are you trying to give people reasons to
>> filter out your articles?
>
> If you can't bear democracy just go back to your cave... since it seems that's
> the only logic you're able to understand.

I take it that's a "yes".

Thanks for the heads-up.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

#105459

GOTHIER Nathan <nathan.gothier@gmail.com> writes:
> On Sun, 5 Mar 2017 13:39:07 +0000
> Richard Heathfield <rjh@cpax.org.uk> wrote:
>
>> You are confusing "reasoning on logical grounds" with "bullying". They 
>> don't mean the same thing. Are you trying to give people reasons to 
>> filter out your articles?
>
> If you can't bear democracy just go back to your cave... since it seems that's
> the only logic you're able to understand.

*PLONK*

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

#105469

Richard Heathfield <rjh@cpax.org.uk> wrote:

> On 04/03/17 22:35, GOTHIER Nathan wrote:
> > On Sat, 4 Mar 2017 11:02:35 -0500
> > "James R. Kuyper" <jameskuyper@verizon.net> wrote:
> >
> >> Arguing against a given point of view by insulting the people who hold
> >> it is a very weak argument. Choosing that argument implies that all of
> >> your other arguments are even weaker. "insulting" someone by pointing
> >> out that they've studied the issue more carefully than you have is
> >> positively counter-productive.
> >> In general, you've given the impression of being someone with strong but
> >> poorly-justified opinions, who's willing to insult anyone who doesn't
> >> share those opinions. Is that the image you want to project?
> >
> > I was joking on the words "class", "student" and "professor" but actually I
> > don't care if you felt insulted about this after vomiting your so-called
> > smartness about a C++ feature, even more deeming uneducated each individual who
> > don't share your point. Bullying people like this exhibit your own intellectual
> > weakness...
> 
> You are confusing "reasoning on logical grounds" with "bullying".

No, he's confusing "being too ready to take insult" with "bullying".

It was very obvious that Nathan was trying to make a joke. The quality
of that joke I leave to every reader's judgement, but that it _was_
meant as a joke was completely transparent to anyone, except someone so
full of himself that he interprets every needle-point as a full-on
attack on his favourite language, and by extension, his personal honour.

Richard

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

#105470

On 06/03/17 09:37, Richard Bos wrote:
> Richard Heathfield <rjh@cpax.org.uk> wrote:
>
>> On 04/03/17 22:35, GOTHIER Nathan wrote:
>>> On Sat, 4 Mar 2017 11:02:35 -0500
>>> "James R. Kuyper" <jameskuyper@verizon.net> wrote:
>>>
>>>> Arguing against a given point of view by insulting the people who hold
>>>> it is a very weak argument. Choosing that argument implies that all of
>>>> your other arguments are even weaker. "insulting" someone by pointing
>>>> out that they've studied the issue more carefully than you have is
>>>> positively counter-productive.
>>>> In general, you've given the impression of being someone with strong but
>>>> poorly-justified opinions, who's willing to insult anyone who doesn't
>>>> share those opinions. Is that the image you want to project?
>>>
>>> I was joking on the words "class", "student" and "professor" but actually I
>>> don't care if you felt insulted about this after vomiting your so-called
>>> smartness about a C++ feature, even more deeming uneducated each individual who
>>> don't share your point. Bullying people like this exhibit your own intellectual
>>> weakness...
>>
>> You are confusing "reasoning on logical grounds" with "bullying".
>
> No, he's confusing "being too ready to take insult" with "bullying".

A matter of opinion, but I can see why you might think that.

> It was very obvious that Nathan was trying to make a joke.

Trying and failing.

> The quality
> of that joke I leave to every reader's judgement, but that it _was_
> meant as a joke was completely transparent to anyone,

Sure. And personally I chose not to bother responding to the "joke" 
itself, which was harmless enough, albeit not particularly amusing. But 
his subsequent umbrage was an unnecessary over-reaction.

> except someone so
> full of himself that he interprets every needle-point as a full-on
> attack on his favourite language, and by extension, his personal honour.

I wouldn't be quite so quick to condemn James. He has a reasonably thick 
skin, and in my view his reply was sensible and measured rather than 
touchy. I've seen touchy on Usenet and, believe me, that ain't it.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

#105472

On 03/06/2017 04:37 AM, Richard Bos wrote:
> Richard Heathfield <rjh@cpax.org.uk> wrote:
> 
>> On 04/03/17 22:35, GOTHIER Nathan wrote:
>>> On Sat, 4 Mar 2017 11:02:35 -0500
>>> "James R. Kuyper" <jameskuyper@verizon.net> wrote:
>>>
>>>> Arguing against a given point of view by insulting the people who hold
>>>> it is a very weak argument. Choosing that argument implies that all of
>>>> your other arguments are even weaker. "insulting" someone by pointing
>>>> out that they've studied the issue more carefully than you have is
>>>> positively counter-productive.
>>>> In general, you've given the impression of being someone with strong but
>>>> poorly-justified opinions, who's willing to insult anyone who doesn't
>>>> share those opinions. Is that the image you want to project?
>>>
>>> I was joking on the words "class", "student" and "professor" but actually I
>>> don't care if you felt insulted about this after vomiting your so-called
>>> smartness about a C++ feature, even more deeming uneducated each individual who
>>> don't share your point. Bullying people like this exhibit your own intellectual
>>> weakness...
>>
>> You are confusing "reasoning on logical grounds" with "bullying".
> 
> No, he's confusing "being too ready to take insult" with "bullying".
> 
> It was very obvious that Nathan was trying to make a joke. The quality
> of that joke I leave to every reader's judgement, but that it _was_
> meant as a joke was completely transparent to anyone, except someone so

Yes, I fully recognized it as a joke. However, the joke expressed
prejudiced views about both C++ and academia, and I don't see how he
could have made such a joke without actually possessing those prejudices.
C++ has plenty of flaws, and pointing out those flaws is a reasonable
thing to do. Joking in this manner about those who don't share your
value judgments about the importance of those flaws is not.

> full of himself that he interprets every needle-point as a full-on
> attack on his favourite language, and by extension, his personal honour.

I did not confuse this in any way with having anything to do with my
personal honor, and it would not have mattered whether he was making
similarly ignorant remarks about my least favorite language. It was the
ignorance he was expressing that I was objecting to, not some imaginary
slight on my honor.

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

#105474

On Mon, 6 Mar 2017 07:23:25 -0500
James Kuyper <jameskuyper@verizon.net> wrote:

> I did not confuse this in any way with having anything to do with my
> personal honor, and it would not have mattered whether he was making
> similarly ignorant remarks about my least favorite language. It was the
> ignorance he was expressing that I was objecting to, not some imaginary
> slight on my honor.

Please tell us I haven't touched your honor whereas you said here you were an
ex-academia worker and your wife is...

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

#105385

BartC <bc@freeuk.com> writes:
> Take these declarations at file-scope:
>
>    struct FS {
>      struct MS *M;
>    };
>
>    struct MS {
>      int (*C)(int*);
>    };
>
> The behaviour I'm observing with existing C compilers is that struct tag 
> MS defined inside struct tag FS appears to have file-scope.
[...]

Of course.  What other scope could it have?  There is no "struct
definition scope".  Not all sets of curly braces create new scopes,
only those that create compound statements.

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

#105386

On 04/03/2017 19:52, Keith Thompson wrote:
> BartC <bc@freeuk.com> writes:
>> Take these declarations at file-scope:
>>
>>    struct FS {
>>      struct MS *M;
>>    };
>>
>>    struct MS {
>>      int (*C)(int*);
>>    };
>>
>> The behaviour I'm observing with existing C compilers is that struct tag
>> MS defined inside struct tag FS appears to have file-scope.
> [...]
>
> Of course.  What other scope could it have?

The same scope as M?

> There is no "struct
> definition scope".  Not all sets of curly braces create new scopes,
> only those that create compound statements.

So what about struct member names? Here:

struct {
     struct {
         int x,y,z;
     } p;
     struct {
         int x,y,z;
     } q;
};

The two lots of x,y,z are isolated from here other. So they don't belong 
to either the outer struct of the enclosing compound statement block or 
to file-scope.

I expect that enum tags work the same way, but that enum names have to 
exist at file-scope or the outer file scope, as otherwise there is no 
way to qualify the names, when accessed from outside.

-- 
bartc

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

#105387

On 04/03/2017 20:13, BartC wrote:


> I expect that enum tags work the same way, but that enum names have to
> exist at file-scope or the outer file scope,

... 'or outer block scope,'

Block scope meaning that of a compound statement that is part of a 
function definition. Outside of struct definition anyway.

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

#105389

BartC <bc@freeuk.com> writes:
> On 04/03/2017 19:52, Keith Thompson wrote:
>> BartC <bc@freeuk.com> writes:
>>> Take these declarations at file-scope:
>>>
>>>    struct FS {
>>>      struct MS *M;
>>>    };
>>>
>>>    struct MS {
>>>      int (*C)(int*);
>>>    };
>>>
>>> The behaviour I'm observing with existing C compilers is that struct tag
>>> MS defined inside struct tag FS appears to have file-scope.
>> [...]
>>
>> Of course.  What other scope could it have?
>
> The same scope as M?

Essentially, yes.  Of course since M is a member name, it's in a
different name space.  It has file scope, but it can only be referred
to immediately following a "." or "->" operator whose LHS is of the
appropriate type.  The requirement to precede a member name with
"obj." or "ptr->" is not part of what we refer to as "scope".

[...]

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

#105391

On Saturday, March 4, 2017 at 3:13:12 PM UTC-5, Bart wrote:
> On 04/03/2017 19:52, Keith Thompson wrote:
> > BartC <bc@freeuk.com> writes:
> >> Take these declarations at file-scope:
> >>
> >>    struct FS {
> >>      struct MS *M;
> >>    };
> >>
> >>    struct MS {
> >>      int (*C)(int*);
> >>    };
> >>
> >> The behaviour I'm observing with existing C compilers is that struct tag
> >> MS defined inside struct tag FS appears to have file-scope.
> > [...]
> >
> > Of course.  What other scope could it have?
> 
> The same scope as M?

It already has that.

> > There is no "struct
> > definition scope".  Not all sets of curly braces create new scopes,
> > only those that create compound statements.
> 
> So what about struct member names? Here:
> 
> struct {
>      struct {
>          int x,y,z;
>      } p;
>      struct {
>          int x,y,z;
>      } q;
> };
> 
> The two lots of x,y,z are isolated from here other. So they don't belong 
> to either the outer struct of the enclosing compound statement block or 
> to file-scope.

You're confusing scopes with name spaces. Note that a "name space" is NOT the
same thing as a C++ namespace. C++ also has the concept of a "name space", but
it has fewer name spaces than C, using scopes instead. As a result, it says
almost nothing about "name spaces".

"... Different entities designated by the same identifier either have different
scopes, or are in different name spaces. ..." (6.2.1p2)
"... each structure or union has a separate name space for its members ... "
(6.2.3p1)

It's the fact that M is in the name space associated with struct FS that allows
it to have the same name as a different member of a different struct type, even
if that other member has a completely different type.

The obvious next question: why couldn't we do the same thing for struct tags?
The key thing that allows struct members to have a different name space for
each struct type, is that struct member names must ALWAYS be connected with a
particular struct type - normally, by a member selection operator whose first
operand is (or points to) that specific struct type. That's the same reason why the offsetof() macro takes both a member name and struct type.

In C++, where different struct types have different scopes, a similar construct
is needed. It's the scope resolution operator "::", and would be used to
distinguish between FS::MS (the first MS you defined) and ::MS (the second
one). C's rules don't distinguish them, and therefore don't need the scope
resolution operator to do so.

p and q have different tagless struct types, even though they have precisely
the same definitions for those types. Therefore, they have different name
spaces.

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

#105393

On 04/03/2017 21:50, jameskuyper@verizon.net wrote:
> On Saturday, March 4, 2017 at 3:13:12 PM UTC-5, Bart wrote:

>> So what about struct member names? Here:
>>
>> struct {
>>      struct {
>>          int x,y,z;
>>      } p;
>>      struct {
>>          int x,y,z;
>>      } q;
>> };
>>
>> The two lots of x,y,z are isolated from here other. So they don't belong
>> to either the outer struct of the enclosing compound statement block or
>> to file-scope.
>
> You're confusing scopes with name spaces. Note that a "name space" is NOT the
> same thing as a C++ namespace. C++ also has the concept of a "name space", but
> it has fewer name spaces than C, using scopes instead. As a result, it says
> almost nothing about "name spaces".
>
> "... Different entities designated by the same identifier either have different
> scopes, or are in different name spaces. ..." (6.2.1p2)
> "... each structure or union has a separate name space for its members ... "
> (6.2.3p1)
>
> It's the fact that M is in the name space associated with struct FS that allows
> it to have the same name as a different member of a different struct type, even
> if that other member has a completely different type.

I don't think I'm confusing them, just maybe using them a little 
differently. Here are the set of name-spaces I use in my implementation 
(adapted from non-C code, they correspond to a set of enums):

      ns_general,       # vars, functions, typedefs, enum names
      ns_tags,          # struct, union, enum tags
      ns_labels,        # label names
      ns_fields,        # field names [ie. member names]

There are three main name-spaces ('general', 'tags' and 'labels'), which 
allow the same identifiers to exist in the same lexical scope, provided 
they have a different name-space attribute.

Field or member names are listed as having their own name-space, but 
that is probably not necessary because in the lexical scopes in which 
they exist, there will only be member names. Especially now that struct, 
union and enum tags constructed on-the-fly have been banished elsewhere.

This would however have allowed member names to co-exist with such tags. 
And it would have allowed this:

    struct S {
       struct S {
          struct S {...

Name visibility is just as it would be for variables, types, and tags 
defined in nested block scopes in a function.

> The obvious next question: why couldn't we do the same thing for struct tags?
> The key thing that allows struct members to have a different name space for
> each struct type, is that struct member names must ALWAYS be connected with a
> particular struct type

And any name in a block will always be connected with that block.

  - normally, by a member selection operator whose first
> operand is (or points to) that specific struct type. That's the same reason why the offsetof() macro takes both a member name and struct type.

The language doesn't have a mechanism to make use of any other names 
defined inside a struct (to make use of a handy struct definition for 
example). Only by making them belong outside.

So struct (and enum) tags could have been treated just like member 
names. The language decided not to do that, but it could just as easily 
have chosen differently. There's nothing innate about struct tags that 
they /have/ to be handled a certain way.

> In C++, where different struct types have different scopes, a similar construct
> is needed. It's the scope resolution operator "::", and would be used to
> distinguish between FS::MS (the first MS you defined) and ::MS (the second
> one). C's rules don't distinguish them, and therefore don't need the scope
> resolution operator to do so.

(In my languages, you can declare all sorts of things inside a struct. 
The names of those things are local to that struct. They can be accessed 
from outside with a qualified name (using "." rather than "::") 
involving the struct type, or an instance of the struct. However this 
was mainly because I neglected to prohibit such declarations. It seems 
to work fine though...)

-- 
bartc

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

#105397

On Saturday, March 4, 2017 at 5:37:23 PM UTC-5, Bart wrote:
> On 04/03/2017 21:50, jameskuyper@verizon.net wrote:
...
> > You're confusing scopes with name spaces. Note that a "name space" is NOT the
> > same thing as a C++ namespace. C++ also has the concept of a "name space", but
> > it has fewer name spaces than C, using scopes instead. As a result, it says
> > almost nothing about "name spaces".
> >
> > "... Different entities designated by the same identifier either have
> > different scopes, or are in different name spaces. ..." (6.2.1p2)
> > "... each structure or union has a separate name space for its members ... "
> > (6.2.3p1)
> >
> > It's the fact that M is in the name space associated with struct FS that
> > allows it to have the same name as a different member of a different struct
> > type, even if that other member has a completely different type.
> 
> I don't think I'm confusing them, just maybe using them a little 
> differently.

If you're using those concepts differently from the way the C standard specifies that they should be used, then expecting a C compiler to conform to your different usage does reflect some confusion. What you do in your own language is a different issue entirely, and not on-topic in this newsgroup, nor of interest to me.

...
> > The obvious next question: why couldn't we do the same thing for struct tags?
> > The key thing that allows struct members to have a different name space for
> > each struct type, is that struct member names must ALWAYS be connected with a
> > particular struct type
> 
> And any name in a block will always be connected with that block.
> 
>   - normally, by a member selection operator whose first
> > operand is (or points to) that specific struct type. That's the same reason why the offsetof() macro takes both a member name and struct type.
> 
> The language doesn't have a mechanism to make use of any other names 
> defined inside a struct (to make use of a handy struct definition for 
> example). Only by making them belong outside.
> 
> So struct (and enum) tags could have been treated just like member 
> names. ...

No, that wouldn't make much sense: mystruct.x makes sense, because you don't
have a member named x unless you also have an object of the struct type
containing it. mystruct.struct MS would not make sense, because you often need
to declare an object of a given type without having access to any object of the
containing struct's type. That's why C++ uses FS::MS for that purpose. You
could not usefully change C in this way without adding some feature
functionally equivalent to that syntax.

> ... The language decided not to do that, but it could just as easily 
> have chosen differently. There's nothing innate about struct tags that 
> they /have/ to be handled a certain way.

No, it would be perfectly feasible to do things that way, as C++ demonstrated.
But you're misunderstanding C if you expect it to work the same way

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

Page 4 of 5 — ← Prev page 1 2 3 [4] 5  Next page →

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

csiph-web