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

Groups > comp.lang.c > #151106

Re: Ways to avoid global variables

Show all headers | View raw

ram@zedat.fu-berlin.de (Stefan Ram) writes:
> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>>On 4/5/20 11:07 AM, Stefan Ram wrote:
>>>Pointers can be the null pointer or point to entities
>>>(functions or objects), but not to variables.
>>I'm curious - what do you consider the definition of "variable" to be,
>>that justifies your claim that pointers can't point at them?
>
>   A variable contains all the information that is given by the
>   declaration of a name and by the scope of this declaration.
>   This encompasses the name itself, its type, and also, for
>   example, whether this is an automatic variable.
>
>   For example, in the block,
>
> { int x; }
>
>   , a variable with the name "x" and the type "int" and
>   automatic storage duration is declared.

Like most definitions of the word "variable" I've seen, this makes
statements about variables or about what they do, but it doesn't
tell me what a variable *is*.

I think most programmers would assume that a "variable" is a kind
of object.  Others might say that it's some kind of abstract thing
that can refer to an object.  My best guess from your wording is
that a "variable" is a compile-time symbol table entry.

Given:

    int x;
    int *p = &x;

I would say that p points to a variable -- or, since C doesn't say
what a "variable" is, that p points to a named object.  It's certainly
true that p does not give access to the name "x".

>   Akin to:
>
> |In C, all variables must be declared before they are used,
> |usually at the beginning of the function before any
> |executable statements. A declaration announces the
> |properties of variables; it consists of a name and a list of
> |variables, such as
> |int fahr, celsius;
> |int lower, upper, step;
> The C Programming Language, Second Edition
>
>   When one has a pointer to an object that is bound to a name,
>   one cannot reach information about the name.
>
>   When a pointer would be able to point to a variable, I would
>   then also expect to be able to obtain the name via the pointer.
>
>   Via recursion, several objects can be bound to a variable that
>   is declared once. This shows that there is not a 1:1 correspondence
>   between variables and objects.
>
>>In my experience, by far the most common problem with global variables
>>IS their excessive visibility, so I would not describe that as "merely".
>
>   Global variables /hide/ dependencies of functions.
>
>   For example, the behavior of
>
> void print( int const n ){ printf( "%d\n", n ); }
>
>   depends on "stdout", but this is not shown in the interface.
>
>

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Ways to avoid global variables Mehdi Amini <atorrses@gmail.com> - 2020-04-05 13:10 +0430
  Re: Ways to avoid global variables Mehdi Amini <atorrses@gmail.com> - 2020-04-05 13:23 +0430
  Re: Ways to avoid global variables felix@palmen-it.de (Felix Palmen) - 2020-04-05 11:11 +0200
  Re: Ways to avoid global variables Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-05 02:34 -0700
  Re: Ways to avoid global variables James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-04-05 10:48 -0400
    Re: Ways to avoid global variables James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-04-05 11:43 -0400
      Re: Ways to avoid global variables James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-04-05 16:49 -0400
      Re: Ways to avoid global variables Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-04-05 16:12 -0700
    Re: Ways to avoid global variables James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-04-05 11:49 -0400
      Re: Ways to avoid global variables Mehdi Amini <atorrses@gmail.com> - 2020-04-06 14:11 +0430
        Re: Ways to avoid global variables Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-04-06 12:08 +0100
  Re: Ways to avoid global variables David Brown <david.brown@hesbynett.no> - 2020-04-05 22:03 +0200
    Re: Ways to avoid global variables James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-04-05 16:53 -0400
      Re: Ways to avoid global variables Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-05 14:11 -0700
      Ice cream (Was: Ways to avoid global variables) gazelle@shell.xmission.com (Kenny McCormack) - 2020-04-06 06:45 +0000
      Re: Ways to avoid global variables David Brown <david.brown@hesbynett.no> - 2020-04-06 09:19 +0200
    Re: Ways to avoid global variables Mehdi Amini <atorrses@gmail.com> - 2020-04-06 13:30 +0430
      Re: Ways to avoid global variables Spiros Bousbouras <spibou@gmail.com> - 2020-04-06 09:25 +0000
        Re: Ways to avoid global variables Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-06 03:03 -0700
          Re: Ways to avoid global variables Spiros Bousbouras <spibou@gmail.com> - 2020-04-06 10:16 +0000
            Re: Ways to avoid global variables Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-04-06 03:21 -0700
              Re: Ways to avoid global variables Spiros Bousbouras <spibou@gmail.com> - 2020-04-06 10:50 +0000
              Re: Ways to avoid global variables David Brown <david.brown@hesbynett.no> - 2020-04-06 13:46 +0200
  Re: Ways to avoid global variables scott@slp53.sl.home (Scott Lurndal) - 2020-04-06 18:05 +0000
    Re: Ways to avoid global variables Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-04-06 20:37 +0100

csiph-web