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 1 of 5  [1] 2 3 4 5  Next page →

#103427 — C Names and Scopes

I've been trying to understand this aspect, and the more I learn the 
more chaotic it seems compared with other languages.

I've written up what I understand of it here:

http://pastebin.com/UgcT0Mag

If it's on totally the wrong lines then perhaps someone can point it out.

Thanks..

-- 
bartc

[toc] | [next] | [standalone]

#103434

On 08/02/17 03:13, BartC wrote:
> 
> I've been trying to understand this aspect, and the more I learn the
> more chaotic it seems compared with other languages.
> 
> I've written up what I understand of it here:
> 
> http://pastebin.com/UgcT0Mag
> 
> If it's on totally the wrong lines then perhaps someone can point it out.
> 
> Thanks..
> 

Why not just read section 6.2 of the standards that gives the /actual/
names and rules for scopes, linkage and duration of identifiers?  That
way you could use the same terms as everyone else, and learn the correct
rules rather than guessing?

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

#103442

On Wednesday, 8 February 2017 09:09:40 UTC, David Brown  wrote:
> On 08/02/17 03:13, BartC wrote:
> > 
> > I've been trying to understand this aspect, ...
> 
> Why not just read section 6.2 of the standards that gives the /actual/
> names and rules for scopes, linkage and duration of identifiers?  That
> way you could use the same terms as everyone else, and learn the correct
> rules rather than guessing?

That would spoil his fun, I presume. Heaven forfend that he should actually learn the language properly...

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

#103444

On 08/02/2017 10:37, mark.bluemel@gmail.com wrote:
> On Wednesday, 8 February 2017 09:09:40 UTC, David Brown  wrote:
>> On 08/02/17 03:13, BartC wrote:
>>>
>>> I've been trying to understand this aspect, ...
>>
>> Why not just read section 6.2 of the standards that gives the /actual/
>> names and rules for scopes, linkage and duration of identifiers?  That
>> way you could use the same terms as everyone else, and learn the correct
>> rules rather than guessing?
>
> That would spoil his fun, I presume. Heaven forfend that he should actually learn the language properly...
>

I'm trying to summarise the rules in ordinary, colloquial English 
preparatory to trying to write code. That was a first draft.

But if you're going to take the piss then forget it.

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

#103477

W dniu środa, 8 lutego 2017 12:08:01 UTC+1 użytkownik Bart napisał:
> On 08/02/2017 10:37, mark.bluemel@gmail.com wrote:
> > On Wednesday, 8 February 2017 09:09:40 UTC, David Brown  wrote:
> >> On 08/02/17 03:13, BartC wrote:
> >>>
> >>> I've been trying to understand this aspect, ...
> >>
> >> Why not just read section 6.2 of the standards that gives the /actual/
> >> names and rules for scopes, linkage and duration of identifiers?  That
> >> way you could use the same terms as everyone else, and learn the correct
> >> rules rather than guessing?
> >
> > That would spoil his fun, I presume. Heaven forfend that he should actually learn the language properly...
> >
> 
> I'm trying to summarise the rules in ordinary, colloquial English 
> preparatory to trying to write code. That was a first draft.
> 
> But if you're going to take the piss then forget it.

put this text in the group (as a text paste in message)
what is provided here may be treated with more attention i think

besides no offence, i usually terated you and maclean as a two most sane users here probably (you bein probably even a 
bit more better than mclean) but in recent months i think 
youre to much involved in topics that are not so much interesting or not at leas much interesting to me ...

i know this may be my private attitude in some part
- but there is a vast area of farm more interesting topics 
that are not discussed here - like optimisation was better that language (unles that are especially good topics on language maybe) and crative coding (of something) is yet much better even then optimistation...

wouldnt it be better to spent some energy on those 
creative topics? it would be really worth it

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

#103478

On 08/02/2017 17:03, fir wrote:

> besides no offence, i usually terated you and maclean as a two most sane users here probably (you bein probably even a
> bit more better than mclean) but in recent months i think
> youre to much involved in topics that are not so much interesting or not at leas much interesting to me ...

You mean, my posts have been getting more on-topic?!

> i know this may be my private attitude in some part
> - but there is a vast area of farm more interesting topics
> that are not discussed here - like optimisation was better that language (unles that are especially good topics on language maybe) and crative coding (of something) is yet much better even then optimistation...
>
> wouldnt it be better to spent some energy on those
> creative topics? it would be really worth it

Try starting a thread. It might be picked up (perhaps slowly as I think 
we're both kill-filed by various people).

But if I want to talk about something else entirely (eg. non-technical) 
I use a different forum; not usenet.

-- 
Bartc

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

#103481

W dniu środa, 8 lutego 2017 18:19:25 UTC+1 użytkownik Bart napisał:
> On 08/02/2017 17:03, fir wrote:
> 
> > besides no offence, i usually terated you and maclean as a two most sane users here probably (you bein probably even a
> > bit more better than mclean) but in recent months i think
> > youre to much involved in topics that are not so much interesting or not at leas much interesting to me ...
> 
> You mean, my posts have been getting more on-topic?!
> 

no.. i mean you waste possibly your own skill of taking
bad subjects ... if you will only spend your tiome on 
language you will not go far in real coding (it is
like studying grammar for 50 years instead of writing 
books)
 
this is side note by me but i thinki in general people
here should talk more on programming (of something, i dont know games, scientific apps, tools etc etc) in c  not
on this damn c language over and over 


[ this on-topic is some mania of simple minds btw,

it does not on-topic matter but a quality of insight
- many people produces a lot of weak quality posts on
on-topic matter, it is not worth reading (same with off topic also not worth reading) ]

besides programming in c is imo ontopic




> > i know this may be my private attitude in some part
> > - but there is a vast area of farm more interesting topics
> > that are not discussed here - like optimisation was better that language (unles that are especially good topics on language maybe) and crative coding (of something) is yet much better even then optimistation...
> >
> > wouldnt it be better to spent some energy on those
> > creative topics? it would be really worth it
> 
> Try starting a thread. It might be picked up (perhaps slowly as I think 
> we're both kill-filed by various people).
> 

those who killfilled me are not worth reading me,

i may starting a thread on codeing something but it
wouldnt suffice this group need change/ going to some
more programming topics instead writing this damn language
fundamentals only :C


> But if I want to talk about something else entirely (eg. non-technical) 
> I use a different forum; not usenet.
> 

if i want do some raytracing or physics etc i read articles.. but it would be fine to talk this interesting
topics and share some views instead of this damn language fundamentals like anybody would be 7 years old 

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

#103445

On 08/02/17 11:37, mark.bluemel@gmail.com wrote:
> On Wednesday, 8 February 2017 09:09:40 UTC, David Brown  wrote:
>> On 08/02/17 03:13, BartC wrote:
>>>
>>> I've been trying to understand this aspect, ...
>>
>> Why not just read section 6.2 of the standards that gives the /actual/
>> names and rules for scopes, linkage and duration of identifiers?  That
>> way you could use the same terms as everyone else, and learn the correct
>> rules rather than guessing?
> 
> That would spoil his fun, I presume. Heaven forfend that he should actually learn the language properly...
> 

It would be fine for him to put together a summary or re-wording of that
section of the standard, to make it easier to understand or with more
examples.  The standard is a reference, not a tutorial, introduction, or
guidelines.  But he study the standards first and then base his
information on the standard terms and correct rules.

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

#103502

On 2017-02-08 04:09, David Brown wrote:
> Why not just read section 6.2 of the standards that gives the /actual/
> names and rules for scopes, linkage and duration of identifiers?  That
> way you could use the same terms as everyone else, and learn the correct
> rules rather than guessing?
The standard costs money because ISO is greedy.  Therefore, most people 
cannot read the standard.

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

#103504

On 09/02/17 01:16, Moai wrote:
> On 2017-02-08 04:09, David Brown wrote:
>> Why not just read section 6.2 of the standards that gives the /actual/
>> names and rules for scopes, linkage and duration of identifiers?  That
>> way you could use the same terms as everyone else, and learn the correct
>> rules rather than guessing?
> The standard costs money because ISO is greedy.  Therefore, most people
> cannot read the standard.

The standards cost money because ISO has to raise money somehow.

However, the draft standards are available for free, and usually the 
final draft is virtually identical to the final version.  The last C11 
draft is known as N1570 - you can quickly find it with google, and 
download it for free (perfectly legally).  Drafts like that are what 
most people use for C (and C++) standards.

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

#103527

Moai <penultimategrill@gmail.com> writes:

> On 2017-02-08 04:09, David Brown wrote:
>> Why not just read section 6.2 of the standards that gives the /actual/
>> names and rules for scopes, linkage and duration of identifiers?  That
>> way you could use the same terms as everyone else, and learn the correct
>> rules rather than guessing?
>
> The standard costs money because ISO is greedy.  Therefore, most
> people cannot read the standard.

Most people can read what is nearly indistinguishable from the
official ISO C standards, by downloading drafts that are
available at no cost -

  C99  http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf
  C11  http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf

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

#103533

On 2/8/2017 7:16 PM, Moai wrote:
> On 2017-02-08 04:09, David Brown wrote:
>> Why not just read section 6.2 of the standards that gives the /actual/
>> names and rules for scopes, linkage and duration of identifiers?  That
>> way you could use the same terms as everyone else, and learn the correct
>> rules rather than guessing?
> The standard costs money because ISO is greedy.  Therefore, most people
> cannot read the standard.

No, ISO is not greedy.  They have costs associated with creating the
standards, and they like to recoup those costs.  People do like to eat,
after all.

Perhaps you would like to undertake creating and distributing standards
at no charge.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

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

#103443

On 08/02/2017 02:13, BartC wrote:
>
> I've been trying to understand this aspect, and the more I learn the
> more chaotic it seems compared with other languages.
>
> I've written up what I understand of it here:
>
> http://pastebin.com/UgcT0Mag

[Link deleted]

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

#103446

On Wednesday, February 8, 2017 at 12:13:30 AM UTC-2, Bart wrote:
> I've been trying to understand this aspect, and the more I learn the 
> more chaotic it seems compared with other languages.
> 
> I've written up what I understand of it here:
> 
> http://pastebin.com/UgcT0Mag
> 
> If it's on totally the wrong lines then perhaps someone can point it out.
> 

I have the same questions on my mind and more how to implement these scopes.

I have used a multi-map. A "key" can point for more than one symbol.
So for instance, for function "F" I can point to the declaration and 
also implementation and for multi-declarations of F.
If I have a struct X and enum X the key "X"points 
to both and then the disambiguation can be done looking into 
the pointed data.
For the local variables I have an stack of symbol-maps and an 
algorithm to find the variable going up into this stack.

(
To implement a warning in my static analiser for hidden variable 
(when you declare a variable with the same name of one from
the scope above) it's a easy task.
)

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

#103449

On 08/02/2017 11:11, Thiago Adams wrote:
> On Wednesday, February 8, 2017 at 12:13:30 AM UTC-2, Bart wrote:
>> I've been trying to understand this aspect, and the more I learn the
>> more chaotic it seems compared with other languages.
>>
>> I've written up what I understand of it here:
>>
>> http://pastebin.com/UgcT0Mag
>>
>> If it's on totally the wrong lines then perhaps someone can point it out.
>>
>
> I have the same questions on my mind and more how to implement these scopes.
>
> I have used a multi-map. A "key" can point for more than one symbol.
> So for instance, for function "F" I can point to the declaration and
> also implementation and for multi-declarations of F.
> If I have a struct X and enum X the key "X"points
> to both and then the disambiguation can be done looking into
> the pointed data.

I think I also have a rather strange symbol table arrangement that has 
worked successfully on /my/ languages but am trying to adapt it to C...

> For the local variables I have an stack of symbol-maps and an
> algorithm to find the variable going up into this stack.

... although C's block scopes are going to be a bit of a challenge. I've 
developed a scheme to deal with them efficientlu but still need to try 
it out. But it is essential that I know exactly what the capabilities 
are, including all the corner cases that even experienced C coders don't 
know exist.

(With block scopes, here is one tricky case:

    int A;        // A1
    { A = 0;      // A1
      int A;      // A2
      A = 0;      // A2
    }

Supposed this is parsed to an AST, without doing name resolving. By 
then, I have A1 in the outer scope, and A2 in the inner one.

But if later trying to resolve the A's in either of the A=0 expressions, 
how to stop them both resolving to A2? The second 'int A' doesn't result 
in an AST node, but even if it did, it wouldn't help.

The language is forcing my hand in doing the resolving as I go along, so 
the first expression is name-resolved before the second 'int A' is 
encountered. I would rather have had the choice.)

> (
> To implement a warning in my static analiser for hidden variable
> (when you declare a variable with the same name of one from
> the scope above) it's a easy task.
> )

Your task is different. I assume the code is correct if it's legal C.

-- 
bartc

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

#103451

On 08/02/2017 11:52, Stefan Ram wrote:
> BartC <bc@freeuk.com> writes:
>> (With block scopes, here is one tricky case:
>> int A;        // A1
>> { A = 0;      // A1
>>  int A;      // A2
>>  A = 0;      // A2
>> }
>
>   I teach this in my C beginners courses in Berlin community
>   education centers for years, wait, for decades! In this lesson,
>
> http://www.purl.org/stefan_ram/pub/c_konstanten_de

('zehn' is 11?)

>   (see »int const c = 9;«). It's one of the very first things
>   they learn directly after the introduction of variable declarations.
>   So I feel allowed to deem it trivial, not tricky.

It's more than trivial when you have to implement it.

But even writing such code, I wouldn't be happy with the idea of having 
two identical names in the same block scope referring to different objects.

And I gave an example in one of my links where there are five identical 
names in the same block all meaning different things!

-- 
Bartc

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

#103461

On 08/02/2017 12:15, Stefan Ram wrote:
> BartC <bc@freeuk.com> writes:
>> On 08/02/2017 11:52, Stefan Ram wrote:
>>> http://www.purl.org/stefan_ram/pub/c_konstanten_de
>> ('zehn' is 11?)
>
>   Yes. Once a participiant wondered whether the implementation
>   understands German. So I use this to show that it does /not/
>   understand German, but just uses whatever value you give to it.
>
>> It's more than trivial when you have to implement it.
>
>   Admitted.
>
>> And I gave an example in one of my links where there are five identical
>> names in the same block all meaning different things!
>
>   For teaching purposes I often use this, to make it clear
>   when the implementation can deduce the scope of a name.
>
>   Here's one example from my C++ course:
>
> #include <iostream>
> #include <ostream>
> #include <string>
>
> struct entity { ::std::string entity; };
>
> int main()
> { entity entity; ::std::cout << '"' << entity.entity << '"' << '\n'; }
>

So, using {n} to disambiguate, that means:

  struct entity{1} { ::std::string entity{2}; };

  int main()
  { entity{1} entity{3}; ::std::cout << '"' << entity{3}.entity{2} <<
    '"' << '\n'; }

The only surprise here is allowing {1} and {3], a type name and variable 
name, to co-exist, something not even C allows (entity{1} would need to 
be tagged with 'struct').

(The languages I create are old-fashioned - they only allow one instance 
of a top-level name, and only once *per function*. So here, entity{3} 
wouldn't be allowed, not with the same name. (Names after "." are OK.)

I don't think it causes code to be less readable; quite the opposite in 
fact.)

-- 
Bartc

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

#103463

On 08/02/2017 12:06, BartC wrote:

> And I gave an example in one of my links where there are five identical
> names in the same block all meaning different things!

Here's that example:

struct A {int x,y,z;};      // declare A1
int A;                      // declare A2
{
     struct A B;             // use A1
     A;                      // use A2
     struct A {int x,y,z;};  // declare A3
     int A;                  // declare A4
     A:;                     // declare A5 as label
     struct A C;             // use A3
     A;                      // use A4
     goto A;                 // use A5
}

These are all 'top-level' names, that is, not following "." or "->". 
Otherwise there can be an unlimited number of different A's within one 
block.

I have, of course, disregarded case, otherwise this is possible:

struct A {int x,y,z;};      // declare A1
int A;                      // declare A2
struct a {int x,y,z;};      // declare a6
int a;                      // declare a7
{
     struct A B;             // use A1
     A;                      // use A2
     struct A {int x,y,z;};  // declare A3
     int A;                  // declare A4
     A:;                     // declare A5 as label
     struct A C;             // use A3
     A;                      // use A4
     goto A;                 // use A5
     struct a b;             // use a6
     a;                      // use a7
     struct a {int x,y,z;};  // declare a8
     int a;                  // declare a9
     a:;                     // declare a10 as label
     struct a c;             // use a8
     a;                      // use a9
     goto a;                 // use a10
}

-- 
Bartc

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

#103476

BartC <bc@freeuk.com> writes:

> On 08/02/2017 12:06, BartC wrote:
>
>> And I gave an example in one of my links where there are five identical
>> names in the same block all meaning different things!

The ! makes you sound surprised but why should, say, a label called
"link" not be usable at the same time as a struct link type?  One can
only be used after goto, and the other only after struct.  Seems
reasonable to me, though as a programmer you might rarely come across
such cases.

<snip>
-- 
Ben.

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

#103483

On 08/02/2017 16:39, Ben Bacarisse wrote:
> BartC <bc@freeuk.com> writes:
>
>> On 08/02/2017 12:06, BartC wrote:
>>
>>> And I gave an example in one of my links where there are five identical
>>> names in the same block all meaning different things!
>
> The ! makes you sound surprised but why should, say, a label called
> "link" not be usable at the same time as a struct link type?  One can
> only be used after goto, and the other only after struct.  Seems
> reasonable to me, though as a programmer you might rarely come across
> such cases.

I disagree; why go to the trouble in the first place? What advantage is 
there to have A meaning a variable, a struct tag, and a label in the 
same scope?

It may technically be possible because certain kinds of names belong in 
particular contexts, but that doesn't make it any easier when confronted 
with code that makes use of that and that can throw you, because you 
weren't even aware that something was possible:

   struct A A;

or:

   Point p;
   struct Point q;

or (with a gcc extension):

   void *L;

   goto  L;
   goto *L;
   L:

or:

  struct L*L;

  if (L)
    L: goto L;

I didn't even need to go to the trouble of declaring new names halfway 
through a block. (It already reminds me of that scene in Being John 
Malkovich where everyone has the same face!)

Without that ability, people would be forced to write that last example as:

  struct S*P;

  if (P)
    L: goto L;

L is a label, P is a pointer, S is presumably a struct tag. Win-win.

-- 
Bartc

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

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

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

csiph-web