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

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

global/static variables & loops

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

Contents

  global/static variables & loops Rob Janecek <robs@invalid.com> - 2012-02-14 19:56 +0000
    Re: global/static variables & loops Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-02-14 12:42 -0800
    Re: global/static variables & loops Stephen Sprunk <stephen@sprunk.org> - 2012-02-14 15:01 -0600
    Re: global/static variables & loops Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-02-14 20:35 -0500
      Re: global/static variables & loops Philip Lantz <prl@canterey.us> - 2012-02-14 21:18 -0800
      Re: global/static variables & loops pete <pfiland@mindspring.com> - 2012-02-15 00:53 -0500
        Re: global/static variables & loops Jonathan Leffler <jleffler@earthlink.net> - 2012-02-18 21:15 -0800
          Re: global/static variables & loops Kaz Kylheku <kaz@kylheku.com> - 2012-02-19 06:05 +0000
            Re: global/static variables & loops Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2012-02-22 03:15 +0200
          Re: global/static variables & loops Shao Miller <sha0.miller@gmail.com> - 2012-02-19 04:14 -0500
            Re: global/static variables & loops Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-02-19 12:32 +0000
              Re: Array 'typedef's and exclusive use of '->' versus '.' Shao Miller <sha0.miller@gmail.com> - 2012-02-19 17:00 -0500
                Re: Array 'typedef's and exclusive use of '->' versus '.' Keith Thompson <kst-u@mib.org> - 2012-02-19 16:43 -0800
                  Re: Array 'typedef's and exclusive use of '->' versus '.' Shao Miller <sha0.miller@gmail.com> - 2012-02-19 20:32 -0500
                Re: Array 'typedef's and exclusive use of '->' versus '.' Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2012-02-22 03:27 +0200
                  Re: Array 'typedef's and exclusive use of '->' versus '.' Shao Miller <sha0.miller@gmail.com> - 2012-02-25 02:19 -0500
                    Re: Array 'typedef's and exclusive use of '->' versus '.' Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2012-02-25 10:14 +0200
      Re: global/static variables & loops "BartC" <bc@freeuk.com> - 2012-02-15 10:47 +0000
        Re: global/static variables & loops Kaz Kylheku <kaz@kylheku.com> - 2012-02-15 11:42 +0000
          Re: global/static variables & loops "BartC" <bc@freeuk.com> - 2012-02-15 12:54 +0000
          Re: global/static variables & loops Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-02-15 05:17 -0800
        Re: global/static variables & loops Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2012-02-22 03:28 +0200
      Re: global/static variables & loops August Karlstrom <fusionfile@gmail.com> - 2012-02-15 15:19 +0100
      Re: global/static variables & loops Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2012-02-22 03:12 +0200
    Re: global/static variables & loops Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-02-15 01:23 -0800
      Re: global/static variables & loops August Karlstrom <fusionfile@gmail.com> - 2012-02-15 14:03 +0100
        Re: global/static variables & loops Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-02-15 05:20 -0800
          Re: global/static variables & loops James Kuyper <jameskuyper@verizon.net> - 2012-02-15 08:41 -0500
            Re: global/static variables & loops Kaz Kylheku <kaz@kylheku.com> - 2012-02-16 00:20 +0000
              Re: global/static variables & loops Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-02-15 21:02 -0500
                Re: global/static variables & loops "BartC" <bc@freeuk.com> - 2012-02-16 10:03 +0000
                  Re: global/static variables & loops Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-02-16 07:58 -0500
                Re: global/static variables & loops Markus Wichmann <nullplan@gmx.net> - 2012-02-19 20:44 +0100
                  Re: global/static variables & loops Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-02-19 15:37 -0500
                  Re: global/static variables & loops Kaz Kylheku <kaz@kylheku.com> - 2012-02-22 05:01 +0000
                    Re: global/static variables & loops Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-02-22 08:12 -0500
      Re: global/static variables & loops Anders Wegge Keller <wegge@wegge.dk> - 2012-02-15 15:55 +0100
        Re: global/static variables & loops James Kuyper <jameskuyper@verizon.net> - 2012-02-15 11:05 -0500
        Re: global/static variables & loops Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-02-15 09:13 -0800
          Re: global/static variables & loops Anders Wegge Keller <wegge@wegge.dk> - 2012-02-15 18:25 +0100
            Re: global/static variables & loops James Kuyper <jameskuyper@verizon.net> - 2012-02-15 13:25 -0500
              Re: global/static variables & loops Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-02-15 10:51 -0800
                Re: global/static variables & loops James Kuyper <jameskuyper@verizon.net> - 2012-02-15 14:45 -0500
                Re: global/static variables & loops Anders Wegge Keller <wegge@wegge.dk> - 2012-02-15 20:47 +0100
                  Re: global/static variables & loops Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-02-16 04:45 -0800
                    Re: global/static variables & loops Anders Wegge Keller <wegge@wegge.dk> - 2012-02-16 14:25 +0100
                      Re: global/static variables & loops Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-02-16 08:10 -0800
                      Re: global/static variables & loops Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-02-17 00:59 -0800
              Re: global/static variables & loops Anders Wegge Keller <wegge@wegge.dk> - 2012-02-15 20:30 +0100
                Re: global/static variables & loops James Kuyper <jameskuyper@verizon.net> - 2012-02-15 15:00 -0500
                  Re: global/static variables & loops Anders Wegge Keller <wegge@wegge.dk> - 2012-02-15 21:30 +0100
                    Re: global/static variables & loops James Kuyper <jameskuyper@verizon.net> - 2012-02-15 16:00 -0500
                      Re: global/static variables & loops Anders Wegge Keller <wegge@wegge.dk> - 2012-02-15 23:10 +0100
                        Re: global/static variables & loops Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-02-15 15:50 -0800
                        Re: global/static variables & loops James Kuyper <jameskuyper@verizon.net> - 2012-02-15 19:50 -0500
                          Re: global/static variables & loops Anders Wegge Keller <wegge@wegge.dk> - 2012-02-16 14:36 +0100
              Re: global/static variables & loops Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-02-16 03:29 -0800
        Re: global/static variables & loops Anders Wegge Keller <wegge@wegge.dk> - 2012-02-15 23:37 +0100
        Re: global/static variables & loops Kaz Kylheku <kaz@kylheku.com> - 2012-02-16 00:23 +0000
          Re: global/static variables & loops Anders Wegge Keller <wegge@wegge.dk> - 2012-02-16 01:29 +0100
          Re: global/static variables & loops Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-02-15 21:20 -0500
        Re: global/static variables & loops Shao Miller <sha0.miller@gmail.com> - 2012-02-15 22:24 -0500
          Re: global/static variables & loops Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-02-16 01:08 -0800
        Re: global/static variables & loops Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-02-16 03:17 -0800

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

#17326 — global/static variables & loops

Hello,
In some coding advice I saw on the internet, we are urged to "avoid 
referring to global or static variables inside the tightest loops".

I also read (elsewhere) that access time to global/static and
automatic variables can be different on different hardware
(i.e., automatic variables cannot always be counted on being
faster).

What is then the justification for the above quote? Could it be
that the compiler might avoid using registers for global/static
variables? But then why could it not just copy the variable to a
register and restore it's value after the loop's over (assuming,
of course, that there are no function calls or other side
effects in that tight loop)? I can see a problem with multi-
threading but is this not a special case that could be treated
separately by the compiler only when it arises?

[I have no problem following the advice, I'm just curious why it
is true...]

[toc] | [next] | [standalone]

#17329

On Feb 14, 7:56 pm, Rob Janecek <r...@invalid.com> wrote:
>
> In some coding advice I saw on the internet, we are urged to "avoid
> referring to global or static variables inside the tightest loops".
>
> What is then the justification for the above quote?
>
Reading and writing to main memory is now slow in comparison to
arithemtical operations with registers.

A global is maybe less likely to be in the cache or optimised away in
a register than an automatic scope variable.

But the advice isn't much use, really. If you need to step through a
large global array in an inner loop, it's unlikely that you can
rewrite the code to remove this requirement.
--
Visit my website
http://www.malcolmmclean.site11.com/www

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

#17334

On 14-Feb-12 13:56, Rob Janecek wrote:
> In some coding advice I saw on the internet, we are urged to "avoid 
> referring to global or static variables inside the tightest loops".
> 
> I also read (elsewhere) that access time to global/static and
> automatic variables can be different on different hardware
> (i.e., automatic variables cannot always be counted on being
> faster).

The Standard makes no guarantees at all about performance, so you can't
really "count on" anything always being faster or slower.

> What is then the justification for the above quote? Could it be
> that the compiler might avoid using registers for global/static
> variables? But then why could it not just copy the variable to a
> register and restore it's value after the loop's over (assuming,
> of course, that there are no function calls or other side
> effects in that tight loop)? I can see a problem with multi-
> threading but is this not a special case that could be treated
> separately by the compiler only when it arises?

Those are possible optimizations that any given implementation may or
may not perform.

As a general rule, I avoid global variables in the first place because
they tend to lead to violations of encapsulation, which IMHO is far more
important in most cases than absolute performance.  Focus on making your
code clear and correct; let the compiler worry about the low-level
stuff.  It will almost certainly do a better job of it anyway, and most
performance problems are caused by using the wrong algorithm anyway;
doing the wrong thing slightly faster rarely helps enough to make it
worth the effort.

> [I have no problem following the advice, I'm just curious why it
> is true...]

Before following any such advice, you should determine if it is correct
_for your implementation_.  And, before that, you should determine if
the performance difference, if any, actually matters _for your program_.

S

-- 
Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking

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

#17348

On 2/14/2012 2:56 PM, Rob Janecek wrote:
> Hello,
> In some coding advice I saw on the internet, we are urged to "avoid
> referring to global or static variables inside the tightest loops".

     Reasonable advice.  I'd go a little further, and delete the
final four words.  Global variables have a way of tying together
pieces of your program that you didn't realize were related, and
this effect increases as the program grows larger.  It's no good
having modular code if you also have spaghetti data.

     That said, I'd also point out that "avoid" is not absolute;
perhaps "prefer not" would capture the notion more aptly.  For
example, it's hard to argue against the global variable in

	printf ("Hello, world!\n");

(If you don't see the global variable, try using fprintf() instead.)
That's a sort of yardstick you might want to use: When you're thinking
of making some variable global, as yourself whether it's as "useful"
to the program at large as `stdout' is.  If it is, there's probably
a pretty good case for making it global.  But if, say, 30% of your
program has no use for the variable, maybe it's not useful enough
to merit globality.

> I also read (elsewhere) that access time to global/static and
> automatic variables can be different on different hardware
> (i.e., automatic variables cannot always be counted on being
> faster).

     No specific usage X can always be counted on to be faster than
some other usage Y.  Still, global variables are likely to be out
of reach for some optimizations.  For example, in

	for (i = 0;  i < global;  ++i)
	    foobar[i] = func(i);

... the compiler may need to assume that func() might change the
value of `global'.  That would require re-fetching `global' at
each iteration, instead of fetching it once and parking it in a
(fast) CPU register.  It's even worse if `i' is global ...

> What is then the justification for the above quote? Could it be
> that the compiler might avoid using registers for global/static
> variables? But then why could it not just copy the variable to a
> register and restore it's value after the loop's over (assuming,
> of course, that there are no function calls or other side
> effects in that tight loop)? I can see a problem with multi-
> threading but is this not a special case that could be treated
> separately by the compiler only when it arises?

     See above.  Without inspecting func(), whose source may be
separately compiled, can you *prove* that `global' retains the
same value throughout the loop?

     Advice 1: Don't make a variable global unless there's a truly
excellent case for it.

     Advice 2: Don't fret too much about micro-optimization; the
time saved by choosing a (possibly) faster construct is unlikely
to repay the time spent in the choosing.

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

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

#17352

Stefan Ram wrote:

> Eric Sosman <esosman@ieee-dot-org.invalid> writes:
> >printf ("Hello, world!\n");
> >(If you don't see the global variable, try using fprintf() instead.)
> 
>   If you had intended to refer to »stdout«: It's really /not/
>   there! There is no such thing as an invisible variable in C.

Would you say the same thing if he had instead used the example
    putchar('\n');
?

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

#17355

Eric Sosman wrote:
> 
> On 2/14/2012 2:56 PM, Rob Janecek wrote:
> > Hello,
> > In some coding advice I saw on the internet, we are urged to "avoid
> > referring to global or static variables inside the tightest loops".
> 
>      Reasonable advice.  I'd go a little further, and delete the
> final four words.  Global variables have a way of tying together
> pieces of your program that you didn't realize were related, and
> this effect increases as the program grows larger.  It's no good
> having modular code if you also have spaghetti data.
> 
>      That said, I'd also point out that "avoid" is not absolute;
> perhaps "prefer not" would capture the notion more aptly.  For
> example, it's hard to argue against the global variable in
> 
>         printf ("Hello, world!\n");
> 
> (If you don't see the global variable, try using fprintf() instead.)
> That's a sort of yardstick you might want to use: When you're thinking
> of making some variable global, as yourself whether it's as "useful"
> to the program at large as `stdout' is.  

On my machine, stdout is an address constant,
which is not something that I would refer to as a "variable".

I can compile this: 

    FILE *array[] = {stdout};


-- 
pete

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

#17596

On 2/14/12 9:53 PM, pete wrote:
> On my machine, stdout is an address constant,
> which is not something that I would refer to as a "variable".
> 
> I can compile this: 
> 
>     FILE *array[] = {stdout};

That will work at file scope or global scope on some platforms - such as
Solaris and probably HP-UX and AIX.  It will not work on Linux or BSD
(including Mac OS X), so portable code doesn't try to initialize global
or file-scope (static) variables like that, nuisance though it be.

Inside a function, you can do such initializations (under C99 - not
under C89 with GCC and -pedantic), though an array of dimension 1 is
modestly pointless.

-- 
Jonathan Leffler                   #include <disclaimer.h>
Email: jleffler@earthlink.net, jleffler@us.ibm.com
Guardian of DBD::Informix v2011.0612 -- http://dbi.perl.org/

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

#17598

On 2012-02-19, Jonathan Leffler <jleffler@earthlink.net> wrote:
> On 2/14/12 9:53 PM, pete wrote:
>> On my machine, stdout is an address constant,
>> which is not something that I would refer to as a "variable".
>> 
>> I can compile this: 
>> 
>>     FILE *array[] = {stdout};
>
> That will work at file scope or global scope on some platforms - such as
> Solaris and probably HP-UX and AIX.  It will not work on Linux or BSD
> (including Mac OS X), so portable code doesn't try to initialize global
> or file-scope (static) variables like that, nuisance though it be.

I think the point was to make exactly that point. And that was pointless
to begin with. stdout is morally a global variable. It's a good example of
a use for global variables: pervasive symbols that refer to something.

It is useful to be able assign a value to stdout to redirect output elsewhere,
and then restore the value. 

So stdout is actually functionally crippled by /not/ being defined as a
variable.

Common Lisp:

  ;; write to standard output
  (defun produce-output ()
    (format t "Hello, world"))

  ;; temporarily redirect standard output to a string
  ;; works because *standard-output* is a variable
  ;; (and not something else like a symbol macro, or constant).
  (with-output-to-string (*standard-output*)
    (produce-output))
  -> "Hello, world" ;; string pops out

Global variables need the discipline of dynamic scoping: the ability to
locally "re-bind" the global so that it appears to be saved and restored over
a dynamic extent.

Emacs Lisp has only dynamically scoped variables, yet it "does OK".  

Saving and restoring is the key, and it has to be automated. Saving and
restoring is what allows the entire environment of an entire machine to share
a handful of global registers, making it look like every thread (or other
context) has its own.

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

#17761

Kaz Kylheku <kaz@kylheku.com> writes:
> On 2012-02-19, Jonathan Leffler <jleffler@earthlink.net> wrote:
> > On 2/14/12 9:53 PM, pete wrote:
> >> On my machine, stdout is an address constant,
> >> which is not something that I would refer to as a "variable".
> >> 
> >> I can compile this: 
> >> 
> >>     FILE *array[] = {stdout};
> >
> > That will work at file scope or global scope on some platforms - such as
> > Solaris and probably HP-UX and AIX.  It will not work on Linux or BSD
> > (including Mac OS X), so portable code doesn't try to initialize global
> > or file-scope (static) variables like that, nuisance though it be.
> 
> I think the point was to make exactly that point. And that was pointless
> to begin with. stdout is morally a global variable. It's a good example of
> a use for global variables: pervasive symbols that refer to something.
> 
> It is useful to be able assign a value to stdout to redirect output elsewhere,
> and then restore the value. 
> 
> So stdout is actually functionally crippled by /not/ being defined as a
> variable.

Why do you want to leak both its value and its address, when all that 
is needed by the clients is the value? (c.f. errno.)

Phil
-- 
> I'd argue that there is much evidence for the existence of a God.
Pics or it didn't happen.
-- Tom (/. uid 822)

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

#17601

On 2/19/2012 00:15, Jonathan Leffler wrote:
>
> Inside a function, you can do such initializations (under C99 - not
> under C89 with GCC and -pedantic), though an array of dimension 1 is
> modestly pointless.
>

Actually, I think that some folks use an '[1]' for 'struct's and 
'union's in their code just for the sake of using only the '->' operator 
throughout their code.

   struct s_foo {
       int x;
     };

   struct s_bar {
       struct s_foo foo[1];
     };

   void baz(struct s_bar * bar) {
       struct s_foo foo[1];

       init_foo(bar->foo);
       bar->foo->x = 42;

       init_foo(foo);
       foo->x = 13;

       something_with_two_foos(bar->foo, foo);
       return;
     }

Someday, it might be a fair idea to allocate the 's_foo' associated with 
an 's_bar' separately from that 's_bar', so the code might include the 
change:

   struct s_bar {
       struct s_foo * foo;
     };

and then the body of 'baz' doesn't need to be changed, assuming the 
caller has populated the 'foo' pointer member.  Contrast with if the 
'foo' member had originally been a non-array and the body of 'baz' had 
used the '.' membership operator.

Not really related to the thread, but an example of a use for an array 
with one element.

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

#17605

Shao Miller <sha0.miller@gmail.com> writes:

> On 2/19/2012 00:15, Jonathan Leffler wrote:
>>
>> Inside a function, you can do such initializations (under C99 - not
>> under C89 with GCC and -pedantic), though an array of dimension 1 is
>> modestly pointless.
>>
>
> Actually, I think that some folks use an '[1]' for 'struct's and
> union's in their code just for the sake of using only the '->'
> operator throughout their code.
<snip example>

I've also seen in used in some APIs.  You get a sort of automatic call
by reference and copying (by assignment) is prohibited:

  typedef struct { /* stuff */ } MyType[1];

  MyType a, b;
  /* ... */
  a = b; /* illegal */
  mytype_copy(a, b); /* no need for &a on the target */

I don't know if I like it or hate it!  To decide, I think I'd have to
maintain a large body of code that uses such an API.  That usually
sorts out the good ideas from the bad ones.

-- 
Ben.

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

#17628 — Re: Array 'typedef's and exclusive use of '->' versus '.'

On 2/19/2012 07:32, Ben Bacarisse wrote:
> Shao Miller<sha0.miller@gmail.com>  writes:
>
>> On 2/19/2012 00:15, Jonathan Leffler wrote:
>>>
>>> Inside a function, you can do such initializations (under C99 - not
>>> under C89 with GCC and -pedantic), though an array of dimension 1 is
>>> modestly pointless.
>>>
>>
>> Actually, I think that some folks use an '[1]' for 'struct's and
>> union's in their code just for the sake of using only the '->'
>> operator throughout their code.
> <snip example>
>
> I've also seen in used in some APIs.  You get a sort of automatic call
> by reference and copying (by assignment) is prohibited:
>
>    typedef struct { /* stuff */ } MyType[1];
>
>    MyType a, b;
>    /* ... */
>    a = b; /* illegal */
      *a = *b; /* legal */
>    mytype_copy(a, b); /* no need for&a on the target */
>
> I don't know if I like it or hate it!  To decide, I think I'd have to
> maintain a large body of code that uses such an API.  That usually
> sorts out the good ideas from the bad ones.
>

Yeah.

On another note, 'clang -ansi -pedantic' appears to be ok with the 
following code, but 'gcc -ansi -pedantic' doesn't (4.3.3):

   #include <stdio.h>

   struct s_foo { unsigned char bytes[2]; };
   typedef struct s_foo foo_t[1];
   struct s_foo_wrapper { foo_t foo; };

   int main(void) {
       register const struct s_foo_wrapper reg_foo =
         { { { { 42, 42 } } } };
       struct s_foo_wrapper normal_foo;

       normal_foo = reg_foo;
       printf(
           "%d and %d\n",
           normal_foo.foo->bytes[0],
           normal_foo.foo->bytes[1]
         );
       return 0;
     }

I am possibly overlooking something...

   register.c: In function 'main':
   register.c:8: error: register name not specified for 'reg_foo'

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

#17634 — Re: Array 'typedef's and exclusive use of '->' versus '.'

Shao Miller <sha0.miller@gmail.com> writes:
[,,,]
> On another note, 'clang -ansi -pedantic' appears to be ok with the 
> following code, but 'gcc -ansi -pedantic' doesn't (4.3.3):
>
>    #include <stdio.h>
>
>    struct s_foo { unsigned char bytes[2]; };
>    typedef struct s_foo foo_t[1];
>    struct s_foo_wrapper { foo_t foo; };
>
>    int main(void) {
>        register const struct s_foo_wrapper reg_foo =
>          { { { { 42, 42 } } } };
>        struct s_foo_wrapper normal_foo;
>
>        normal_foo = reg_foo;
>        printf(
>            "%d and %d\n",
>            normal_foo.foo->bytes[0],
>            normal_foo.foo->bytes[1]
>          );
>        return 0;
>      }
>
> I am possibly overlooking something...
>
>    register.c: In function 'main':
>    register.c:8: error: register name not specified for 'reg_foo'

That's a bug in gcc.  Nothing in standard C requires a "register name".

Why did you bother with the "register" keyword there anyway?

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#17635 — Re: Array 'typedef's and exclusive use of '->' versus '.'

On 2/19/2012 19:43, Keith Thompson wrote:
> Shao Miller<sha0.miller@gmail.com>  writes:
> [,,,]
>> On another note, 'clang -ansi -pedantic' appears to be ok with the
>> following code, but 'gcc -ansi -pedantic' doesn't (4.3.3):
>>
>>     #include<stdio.h>
>>
>>     struct s_foo { unsigned char bytes[2]; };
>>     typedef struct s_foo foo_t[1];
>>     struct s_foo_wrapper { foo_t foo; };
>>
>>     int main(void) {
>>         register const struct s_foo_wrapper reg_foo =
>>           { { { { 42, 42 } } } };
>>         struct s_foo_wrapper normal_foo;
>>
>>         normal_foo = reg_foo;
>>         printf(
>>             "%d and %d\n",
>>             normal_foo.foo->bytes[0],
>>             normal_foo.foo->bytes[1]
>>           );
>>         return 0;
>>       }
>>
>> I am possibly overlooking something...
>>
>>     register.c: In function 'main':
>>     register.c:8: error: register name not specified for 'reg_foo'
>
> That's a bug in gcc.  Nothing in standard C requires a "register name".
>
> Why did you bother with the "register" keyword there anyway?
>

Well, 'register' suggests that an access be "as fast as possible" and I 
was pondering 'reg_foo' having the potential to be "an immediate 
operand" for some given architecture.  In that case, not only would 
'reg_foo' not be addressable, but it mightn't even be stored in "a 
register," but still could contain a C array value and still be useful 
for assignment.

I'd assume that a decent compiler could do the same thing if 'register' 
was replaced with 'static', there, or even with no explicit storage 
class specifier.

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

#17762 — Re: Array 'typedef's and exclusive use of '->' versus '.'

Shao Miller <sha0.miller@gmail.com> writes:
> On 2/19/2012 07:32, Ben Bacarisse wrote:
> > Shao Miller<sha0.miller@gmail.com>  writes:
> >
> >> On 2/19/2012 00:15, Jonathan Leffler wrote:
> >>>
> >>> Inside a function, you can do such initializations (under C99 - not
> >>> under C89 with GCC and -pedantic), though an array of dimension 1 is
> >>> modestly pointless.
> >>>
> >>
> >> Actually, I think that some folks use an '[1]' for 'struct's and
> >> union's in their code just for the sake of using only the '->'
> >> operator throughout their code.
> > <snip example>
> >
> > I've also seen in used in some APIs.  You get a sort of automatic call
> > by reference and copying (by assignment) is prohibited:
> >
> >    typedef struct { /* stuff */ } MyType[1];
> >
> >    MyType a, b;
> >    /* ... */
> >    a = b; /* illegal */
>       *a = *b; /* legal */
> >    mytype_copy(a, b); /* no need for&a on the target */
> >
> > I don't know if I like it or hate it!  To decide, I think I'd have to
> > maintain a large body of code that uses such an API.  That usually
> > sorts out the good ideas from the bad ones.
> >
> 
> Yeah.
> 
> On another note, 'clang -ansi -pedantic' appears to be ok with the
> following code, but 'gcc -ansi -pedantic' doesn't (4.3.3):
> 
>    #include <stdio.h>
> 
>    struct s_foo { unsigned char bytes[2]; };
>    typedef struct s_foo foo_t[1];
>    struct s_foo_wrapper { foo_t foo; };
> 
>    int main(void) {
>        register const struct s_foo_wrapper reg_foo =
>          { { { { 42, 42 } } } };
>        struct s_foo_wrapper normal_foo;
> 
>        normal_foo = reg_foo;
>        printf(
>            "%d and %d\n",
>            normal_foo.foo->bytes[0],

I would hope that would be UB, but it seems to sneak past the combination 
of 4.p2 (giving precise meaning to "shall" and "shall not") and 6.7.1.p6's 
(informative) footnote 121 ("the only operators that can be applied...",
which appears to be at least morally violated).

Phil
-- 
> I'd argue that there is much evidence for the existence of a God.
Pics or it didn't happen.
-- Tom (/. uid 822)

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

#17910 — Re: Array 'typedef's and exclusive use of '->' versus '.'

On 2/21/2012 20:27, Phil Carmody wrote:
> Shao Miller<sha0.miller@gmail.com>  writes:
>> On another note, 'clang -ansi -pedantic' appears to be ok with the
>> following code, but 'gcc -ansi -pedantic' doesn't (4.3.3):
>>
>>     #include<stdio.h>
>>
>>     struct s_foo { unsigned char bytes[2]; };
>>     typedef struct s_foo foo_t[1];
>>     struct s_foo_wrapper { foo_t foo; };
>>
>>     int main(void) {
>>         register const struct s_foo_wrapper reg_foo =
>>           { { { { 42, 42 } } } };
>>         struct s_foo_wrapper normal_foo;
>>
>>         normal_foo = reg_foo;
>>         printf(
>>             "%d and %d\n",
>>             normal_foo.foo->bytes[0],
>
> I would hope that would be UB, but it seems to sneak past the combination
> of 4.p2 (giving precise meaning to "shall" and "shall not") and 6.7.1.p6's
> (informative) footnote 121 ("the only operators that can be applied...",
> which appears to be at least morally violated).

I don't follow, I'm afraid.  Which line(s) are you hopeful for undefined 
behaviour?  The assignment line?  If so, the 'struct' 'reg_foo' has a 
value and I don't know why using that value (and not the address) ought 
to be undefined.

Perhaps similarly:

   #include <stdio.h>

   struct s_foo { unsigned char bytes[2]; };
   typedef struct s_foo foo_t[1];
   struct s_foo_wrapper { foo_t foo; };

   struct s_foo_wrapper foo_default(void) {
       const struct s_foo_wrapper val =
         { { { { 42, 42 } } } };
       return val;
     }

   int main(void) {
       struct s_foo_wrapper normal_foo;

       normal_foo = foo_default();
       printf(
           "%d and %d\n",
           normal_foo.foo->bytes[0],
         );
       return 0;
     }

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

#17914 — Re: Array 'typedef's and exclusive use of '->' versus '.'

Shao Miller <sha0.miller@gmail.com> writes:
> On 2/21/2012 20:27, Phil Carmody wrote:
> > Shao Miller<sha0.miller@gmail.com>  writes:
> >> On another note, 'clang -ansi -pedantic' appears to be ok with the
> >> following code, but 'gcc -ansi -pedantic' doesn't (4.3.3):
> >>
> >>     #include<stdio.h>
> >>
> >>     struct s_foo { unsigned char bytes[2]; };
> >>     typedef struct s_foo foo_t[1];
> >>     struct s_foo_wrapper { foo_t foo; };
> >>
> >>     int main(void) {
> >>         register const struct s_foo_wrapper reg_foo =
> >>           { { { { 42, 42 } } } };
> >>         struct s_foo_wrapper normal_foo;
> >>
> >>         normal_foo = reg_foo;
> >>         printf(
> >>             "%d and %d\n",
> >>             normal_foo.foo->bytes[0],
> >
> > I would hope that would be UB, but it seems to sneak past the combination
> > of 4.p2 (giving precise meaning to "shall" and "shall not") and 6.7.1.p6's
> > (informative) footnote 121 ("the only operators that can be applied...",
> > which appears to be at least morally violated).
> 
> I don't follow, I'm afraid.

I'm not surprised. I was gibbering inanely. I had seen a 'register' where 
there was none.

Phil
-- 
> I'd argue that there is much evidence for the existence of a God.
Pics or it didn't happen.
-- Tom (/. uid 822)

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

#17362

"Eric Sosman" <esosman@ieee-dot-org.invalid> wrote in message 
news:jhf24h$kmr$1@dont-email.me...
> On 2/14/2012 2:56 PM, Rob Janecek wrote:

>> In some coding advice I saw on the internet, we are urged to "avoid
>> referring to global or static variables inside the tightest loops".

>     That said, I'd also point out that "avoid" is not absolute;
> perhaps "prefer not" would capture the notion more aptly.  For
> example, it's hard to argue against the global variable in
>
> printf ("Hello, world!\n");

That's not likely to be part of a 'tight' loop though. The advice seems to 
be more encouraging the use of globals than otherwise.

>> I also read (elsewhere) that access time to global/static and
>> automatic variables can be different on different hardware

>     No specific usage X can always be counted on to be faster than
> some other usage Y.

No.  But there might be the need to push an extra parameter for millions of 
function calls, when all they want to do is access the same file-scope (or 
project-scope) variable, which can be done for nothing.

And if they all need write-access to that variable, an extra level of 
indirection is needed; avoiding a global access can well introduce overheads 
that cannot be offset by potential optimisations. And that's just one 
global...

-- 
Bartc 

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

#17364

On 2012-02-15, BartC <bc@freeuk.com> wrote:
>
>
> "Eric Sosman" <esosman@ieee-dot-org.invalid> wrote in message 
> news:jhf24h$kmr$1@dont-email.me...
>> On 2/14/2012 2:56 PM, Rob Janecek wrote:
>
>>> In some coding advice I saw on the internet, we are urged to "avoid
>>> referring to global or static variables inside the tightest loops".
>
>>     That said, I'd also point out that "avoid" is not absolute;
>> perhaps "prefer not" would capture the notion more aptly.  For
>> example, it's hard to argue against the global variable in
>>
>> printf ("Hello, world!\n");
>
> That's not likely to be part of a 'tight' loop though. The advice seems to 
> be more encouraging the use of globals than otherwise.

Machine registers are globals, and they are used in tight loops.

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

#17365

"Kaz Kylheku" <kaz@kylheku.com> wrote in message 
news:20120215033910.920@kylheku.com...
> On 2012-02-15, BartC <bc@freeuk.com> wrote:
>> "Eric Sosman" <esosman@ieee-dot-org.invalid> wrote in message
>> news:jhf24h$kmr$1@dont-email.me...
>>> On 2/14/2012 2:56 PM, Rob Janecek wrote:
>>
>>>> In some coding advice I saw on the internet, we are urged to "avoid
>>>> referring to global or static variables inside the tightest loops".
>>
>>>     That said, I'd also point out that "avoid" is not absolute;
>>> perhaps "prefer not" would capture the notion more aptly.  For
>>> example, it's hard to argue against the global variable in
>>>
>>> printf ("Hello, world!\n");
>>
>> That's not likely to be part of a 'tight' loop though. The advice seems 
>> to
>> be more encouraging the use of globals than otherwise.
>
> Machine registers are globals, and they are used in tight loops.

For those used as accumulators and scratchpad registers, then they don't 
really correspond to the way actual global variables are used.

For those spare registers dedicated to particular uses by an application, 
that just reinforces my point that access to globals can be streamlined 
across different functions; they're always there for instant access. 
(Although I'd imagine that in C, such uses are mainly for local variables 
not globals.)

-- 
Bartc 

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

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

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

csiph-web