Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #103427 > unrolled thread
| Started by | BartC <bc@freeuk.com> |
|---|---|
| First post | 2017-02-08 02:13 +0000 |
| Last post | 2017-03-05 01:40 -0800 |
| Articles | 5 on this page of 85 — 19 participants |
Back to article view | Back to comp.lang.c
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 5 of 5 — ← Prev page 1 2 3 4 [5]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-03-05 00:31 +0000 |
| Message-ID | <o9fm5j$mu2$1@dont-email.me> |
| In reply to | #105397 |
On 05/03/2017 00:15, jameskuyper@verizon.net wrote: > 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. What happens in a different language /is/ relevant, because it is has been suggested that handling struct-tag names the way C does /has/ to be done that way. I'm saying it was a choice (and not as intuitive a one as I've seen elsewhere). (However, the set of name-spaces tags I listed, was from a fragment - in a different language but that was hardly relevant except it saved me some editing - of my /C/ implementation.) >> 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. I'm not expecting to change C. But having struct tag names be local to the struct they're declared /could/ have been useful. For a start, you can reuse the same tags in different, unrelated structs; or import a struct definition from elsewhere without worrying about clashed of embedded struct names. Making use of a struct tag from outside is less useful; if you wanted to do that, you would define it outside. However, it can happen that are there two 'MS' struct tags defined locally, that you want to use from outside; it would be handy to make use of them via FS::MS or GS::MS (or equivalent syntax) without having to disrupt each one. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2017-03-04 16:47 -0800 |
| Message-ID | <a3d6e6cf-f226-437f-a2da-9e99d3353c97@googlegroups.com> |
| In reply to | #105398 |
On Saturday, March 4, 2017 at 7:31:45 PM UTC-5, Bart wrote: > On 05/03/2017 00:15, jameskuyper@verizon.net wrote: ... > > 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. > > What happens in a different language /is/ relevant, because it is has > been suggested that handling struct-tag names the way C does /has/ to be > done that way. I'm saying it was a choice (and not as intuitive a one as > I've seen elsewhere). I made no such suggestion. My message was entirely about your incorrect expectations about how some C code would work. I explicitly pointed out that C++ does work roughly as you expected, which should make it pretty clear that I thought it was feasible. Rebutting such a suggestion in a message where I did not make that suggestion is ... confusing.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2017-03-05 01:42 +0000 |
| Message-ID | <o9fqa9$282$1@dont-email.me> |
| In reply to | #105399 |
On 05/03/2017 00:47, jameskuyper@verizon.net wrote: > On Saturday, March 4, 2017 at 7:31:45 PM UTC-5, Bart wrote: >> On 05/03/2017 00:15, jameskuyper@verizon.net wrote: > ... >>> 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. >> >> What happens in a different language /is/ relevant, because it is has >> been suggested that handling struct-tag names the way C does /has/ to be >> done that way. I'm saying it was a choice (and not as intuitive a one as >> I've seen elsewhere). > > I made no such suggestion. It was made by Keith: > 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. > My message was entirely about your incorrect expectations about how some C code would work. I explicitly pointed out that C++ does work roughly as you expected, which should make it pretty clear that I thought it was feasible. Rebutting such a suggestion in a message where I did not make that suggestion is ... confusing. I've haven't looked too closely at C++ (I don't want to). Actually I haven't looked at it at all, not for a while. Since it also, apparently, has to compile C code and treat names and scopes the same as C compilers do, I can't see how it's going to be anything but confusing to use it for comparison. The general concept is broader and much simpler; if you define anything within any nested lexical scope, such as might be denoted with braces, then the scope and visibility is restricted to that or inner spans. (C of course has to break all such rules! However, one of my concerns had been that it would make it inefficient to compile, having to deal with a myriad special cases. But that has been unfounded so far.) -- bartc
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2017-03-04 19:20 -0800 |
| Message-ID | <cfe2a3a3-c630-4caa-9956-d370a118904e@googlegroups.com> |
| In reply to | #105400 |
On Saturday, March 4, 2017 at 8:42:30 PM UTC-5, Bart wrote: > On 05/03/2017 00:47, jameskuyper@verizon.net wrote: > > On Saturday, March 4, 2017 at 7:31:45 PM UTC-5, Bart wrote: ... > >> What happens in a different language /is/ relevant, because it is has > >> been suggested that handling struct-tag names the way C does /has/ to be > >> done that way. I'm saying it was a choice (and not as intuitive a one as > >> I've seen elsewhere). > > > > I made no such suggestion. > > It was made by Keith: > > > 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. That paragraph is also completely lacking with any statements about how C could be changed - it was very explicitly only about C as it currently is. C as it currently is doesn't have a scope type with the characteristics you expected it to have. That expectation would not have existed if you had actually been familiar with the four scope types C currently has - and that's all that Keith was telling you. ... > > My message was entirely about your incorrect expectations about how some C > > code would work. I explicitly pointed out that C++ does work roughly as you > > expected, which should make it pretty clear that I thought it was feasible. > > Rebutting such a suggestion in a message where I did not make that > > suggestion is ... confusing. > > I've haven't looked too closely at C++ (I don't want to). Actually I > haven't looked at it at all, not for a while. > > Since it also, apparently, has to compile C code and treat names and > scopes the same as C compilers do, I can't see how it's going to be > anything but confusing to use it for comparison. I'm not sure what "it" is in that sentence. If by any chance "it" is C++, you're wrong. C++ does NOT treat names and scopes exactly the same way C does. Most of the big, flashy differences between the two languages are syntax errors if used in the wrong language. Many of the other differences between them involve code that has undefined behavior in one of the two languages (which means it's possible for conforming implementations to give such code the same behavior in both languages). However, the cases where code has different well-defined behavior in each language mostly involves differences in the way names an scopes are handled.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-03-05 01:40 -0800 |
| Message-ID | <ln4lz8awnv.fsf@kst-u.example.com> |
| In reply to | #105400 |
BartC <bc@freeuk.com> writes:
> On 05/03/2017 00:47, jameskuyper@verizon.net wrote:
>> On Saturday, March 4, 2017 at 7:31:45 PM UTC-5, Bart wrote:
>>> On 05/03/2017 00:15, jameskuyper@verizon.net wrote:
>> ...
>>>> 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.
>>>
>>> What happens in a different language /is/ relevant, because it is has
>>> been suggested that handling struct-tag names the way C does /has/ to be
>>> done that way. I'm saying it was a choice (and not as intuitive a one as
>>> I've seen elsewhere).
>>
>> I made no such suggestion.
>
> It was made by Keith:
Then you misunderstood what I wrote.
>> 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.
I said there is no "struct definition scope". I did not say or imply
that it would be impossible for some other language (C-like or
otherwise) to have such a scope. I was answering a question about C; it
did not occur to me to confuse the answer with speculations about other
possible languages.
--
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] | [standalone]
Page 5 of 5 — ← Prev page 1 2 3 4 [5]
Back to top | Article view | comp.lang.c
csiph-web