Harrzack 
I'm working on my first Library for Arduino, and will be creating a Class that can be instantiated in a sketch - several times if needed. Working with Arduino 1.03
Just wondering when the created objects 'go away' - IE get destroyed? Or do they live forever in the Flash memory of the Atmel 328?
Be easy on me - I'm new to this environment!
=Alan R.
mckeemj 
Arduino is just C++. In C++ objects are destroyed when they go out of scope. So, if an object is instantiated at global scope ( or, equivelently, as a static object at function scope ), it lives forever. This is for static allocation. If an object is instantiated dynamically using new ( not recommended in such a constrained environment ) it exists until explicitly destroyed with del. The final option is is local scope objects. These are created on the stack and are destroyed with the cleanup of that particular stack frame -- as stated before, when they go out of scope.
Martin Jay McKee
Edit:
Just to clarify, the above is talking about only the RAM usage. The flash footprint is ( of course ) a one time cost dependent upon the construction of the program. In short, local instances are "reclaimed" automatically, globals are always there and dynamics can create a memory leak if the pointer to them goes out of scope without them being explicitly released.
Koshchi it exists until explicitly destroyed with del
mckeemj You mean delete.
True. Obviously I've been spending far too much time around Python lately...
Martin Jay McKee
ChaunceyGardiner Quote:You mean delete.it exists until explicitly destroyed with del
Or delete[].
(Hmm. Very recently added: http://code.google.com/p/arduino...
See also http://code.google.com/p/arduino... )
JohanEkdahl 
The flash footprint is ( of course ) a one time cost dependent upon the construction of the program.
Harrzack Thanks to all for the various comments. Obviously I need to bone up a bit more on classes.
I was thinking of a class that would simplify the math of setting up timers such that the end user would just instantiate an object (max 3) for each interval needed (not for PWM).
Then just enter a period and interval... there would be some functions to restart, get stats, etc. There really wouldn't be a ton of code in this - just the math and timer setups.
Does it help that it is not a huge amount of code or is it just a Bad Idea?
JohanEkdahl Does it help that it is not a huge amount of code
or is it just a Bad Idea?
You want to isolate some specific closer-to-hardware stuff and hide it behind a somewhat-less-close-to-hardware facade. You are already (to a certain degree) "thinking in objects".
(I don't get the details of your "period and interval" talk though - sure sounds like PWM to me...)
Koshchi For the three situations outlined by Martin, only the new/delete method might get you into trouble. But that also applies to using malloc/free in C.
mckeemj Agreed. I was talking about what could happen with objects. Not must happen. I very often do the very thing you are discussing by wrapping a hardware resource with a C++ class. Indeed, I've done it even in cases such as I/O pins. There is, as a general rule, no overhead. The places that this can prove not to be the case are if there are virtual methods in a class( the one-time RAM cost that Johan mentioned ), or if dynamic construction is used. Virtual methods are, typically, easy to avoid and dynamic construction must, explicitly, be used. So these are usually non-issues.
Something to keep in mind. GCC is, generally, a good optimizing compiler. If there is a way for the compiler to throw out useless work, it almost always will. Wrapping it in a class to make programming easier for the user rarely gets in the way of that. Even when the class is more expensive, the cost is typically "affordable" given the ease of use gained and, potentially, the ability to use well tested modules. This is one of the main advantages of the Arduino libraries in fact.
Martin Jay McKee
