next topic »

[Reply #45 on:]

A fairly simple fix in fact is to have a naming convention for class variables, eg.

Code:

int m_myVariable;   // m_ = member; or:
int myVariable_;    // using trailing underscore on class variables

[Reply #46 on:]

Yes I prefer namespaces or trailing '_G'

The example is a good point I think as many are avoiding 'this->' to keep their code 'pretty', whereas blatant use will save you without even knowing it was a problem. i_NewVal is fine as its callee scope is non-dependant. Further templated functions would require further qualification.

The important part of my post was showing how the global was the sole cause of problems, the code otherwise would not have compiled.

So rather than receiving an error about 'i' being undefined in the class ( 'this->' is required to make the name dependant ), the previous definition of 'i' is silently used.

[Reply #47 on:]

Interesting and thank for clarifying this.

One question tho

When allocation static memory does that automatically become a global variable ?

Kim

[Reply #48 on:]

I'm not sure I understand your last question... Are you asking if qualifying a variable as "static" makes it global ?

Scope and lifetime are two related but distinct properties of a variable.

[Reply #49 on:]

Interesting and thank for clarifying this.

One question tho

When allocation static memory does that automatically become a global variable ?

Kim

No.  A global (i.e., defined in the "global" scope) variable and static variable are different.

A global can be accessed anywhere.  A static can only be accessed in the function it is defined in.  A static variable retains its value across subsequent calls to the function.

The memory for a static is, as the name suggests, static - it is always at the same location, so theoretically it can be accessed globally through the address:

Code:

int *superGlobal;

void myFunc()
{
  static int localStatic = 4;
  superGlobal = &localStatic; // Assign address of localStatic to superGlobal pointer
  localStatic++;
}

void myOtherFunc()
{
  int myLocal;
  myFunc();
  myLocal = *superGlobal; // "myLocal" now contains whatever localStatic contains.
}

Not something that is done often - it's more common to either return the value from the function, or return a pointer to the static variable.  Such functions, though, are not re-entrant, and are frowned on in today's multithreaded environments.  Perfectly fine on the Arduino though

[Reply #50 on:]

 

I hope you are aware that the code above is fine as an "extreme" didactic example, but it's definitely a coding horror(1). And the reason is, it's the perfect recipe for spaghetti code



(1) As in "Code Complete 2"; see Jeff Atwood's blog icon for an effective visual representation of the concept

[Reply #51 on:]

Re-entrant code can build up the stack really fast if you're not very, very careful. Remember, UNO has only 2k of RAM for stack and heap space.

[Reply #52 on:]

Thanks

Coming from Assembly and a bit of basic, I'm trying to get my head around the GNU C compiler and the way it does things.
Been reading the GNU documentation, but sometimes it is "clear as mud" :-)

K

[Reply #53 on:]

Re-entrant code can build up the stack really fast if you're not very, very careful.

You're thinking of recursive code?

[Reply #54 on:]

Right. Functions that call themselves or call others that call them, etc.

It's been a while since I wrote that kind of stuff.

[Reply #55 on:]

Right. Functions that call themselves or call others that call them, etc.

It's been a while since I wrote that kind of stuff.

Re-entrant is entirely different.

Re-entrant code can be safely called by two different threads at the same time without trashing any global / static variables.  They often involve passing of pointers to work areas to the function, so each thread has its own bit of memory.

[Reply #56 on:]

Something else I wouldn't try with a 328P chip.

Long live the state machine!

[Reply #57 on:]

Something else I wouldn't try with a 328P chip.

Long live the state machine!

Hell yeah

I had fun a bit back trying to move a few non-re-entrant library routines (from the printf family) into kernel space on RetroBSD so as to reduce user-process size (kind of a pre-cursor to shared libraries) a bit back... Not nice trying to convert them to re-entrant

[Reply #58 on:]

The String class is kind of like training wheels on a bicycle.  Babies need them in order to learn how to ride (or code), but as soon as you want to do anything remotely useful you have to take them off and throw them away. 

So many of the "Why don't they fix this bug?" complaints could easily be rewritten as:

"Wah!  I want to be able to do BMX tricks but I'm scared to let go of my training wheels."

[Reply #59 on:]

The String class is kind of like training wheels on a bicycle.  Babies need them in order to learn how to ride (or code), but as soon as you want to do anything remotely useful you have to take them off and throw them away. 

So many of the "Why don't they fix this bug?" complaints could easily be rewritten as:

"Wah!  I want to be able to do BMX tricks but I'm scared to let go of my training wheels."

Wow, another String class whiner!  Sad that the String class whiners almost never correct/adjust the usually simple they constantly whine about. Sad