Developing/compiling software
in [Embedded]
|
From: David Brown on 29 Sep 2009 15:11 Grant Edwards wrote: > On 2009-09-28, Jon Kirwan <jonk(a)infinitefactors.org> wrote: > >> [First off, I want to make sure no one reading this is conflating the >> idea of 'global' with 'static'. A global definition (in c) is always >> a static definition. But not all static definitions are global.] > > The overloading of the 'static' keyword in the C language to > modify lexical scope in one case and lifetime in another was a > huge mistake IMO. > I like to think of "static" as making the object in question (function or data) a fixed global object for the lifetime of the program, with a name derived from its closest scope. Thus "static int x" local to function "foo" in file "bar.c" acts exactly as though it were a file-scope global variable called "bar_foo_x". Of course, that's a little simplification - "static" lets the compiler optimise much better, and you can get yourself in a real muddle trying to figure out the meaning of a static local variable in a "static inline" function included in a header. The big issue with "static" and C is that file-scope objects should be static by default, and only made public with an explicit keyword (at the very least, an "extern" declaration).
From: Grant Edwards on 29 Sep 2009 15:39 On 2009-09-29, David Brown <david.brown(a)hesbynett.removethisbit.no> wrote: > The big issue with "static" and C is that file-scope objects > should be static by default, and only made public with an > explicit keyword (at the very least, an "extern" declaration). I agree. Making file-scope things global by default was a mistake. The odd thing is that all of the assemblers I've used did things the "right" way and required a "global" declaration and by default things were file-scope. -- Grant
From: John Devereux on 29 Sep 2009 16:06 Dombo <dombo(a)disposable.invalid> writes: > John Devereux schreef: >> Vladimir Vassilevsky <nospam(a)nowhere.com> writes: >> [...] >>> I do require all access to such variables via member functions. I like >>> an overloaded function UART.Timeout() instead of separate Set.. and >>> Get.. functions. >> >> How does that work, like: >> >> timeout = UART.Timeout(GET,UART1); >> >> ... >> >> UART.Timeout(SET,10000); > > > Since Vladimir mentioned overloaded member functions I expect he means > something like: > > class UART > { > public: > void Timeout(int amount); // Set UART timeout > int Timeout(); // Get UART timeout > > > }; OK, of course, that makes more sense. I was thinking he might have some neat C way. -- John Devereux
From: ChrisQ on 29 Sep 2009 16:24 John Devereux wrote: > > OK, of course, that makes more sense. I was thinking he might have some > neat C way. > > Well, there is, in that you can put function pointers into a structure and dereference through a pointer to the structure. From what I remember, that's one of the methods used by early c++ to c translators... Regards, Chris
From: David Brown on 29 Sep 2009 16:44
Grant Edwards wrote: > On 2009-09-29, David Brown <david.brown(a)hesbynett.removethisbit.no> wrote: > >> The big issue with "static" and C is that file-scope objects >> should be static by default, and only made public with an >> explicit keyword (at the very least, an "extern" declaration). > > I agree. Making file-scope things global by default was a > mistake. The odd thing is that all of the assemblers I've used > did things the "right" way and required a "global" declaration > and by default things were file-scope. > I think the same thing applies to most languages. I guess we can blame this idiosyncrasy (or rather, idiocy) of C on the slow Dec Writer keyboards - K&R were more concerned about avoiding keystrokes than on making a good structured modular programming language. The default "int" is in the same category. |