Instantiated Objects: When destroyed?

Go To Last Post
11 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

As with most things in engineering, the answer is an unabashed, "It depends."

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
it exists until explicitly destroyed with del
You mean delete.

Regards,
Steve A.

The Board helps those that help themselves.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
You mean delete.

True. Obviously I've been spending far too much time around Python lately...

Martin Jay McKee

As with most things in engineering, the answer is an unabashed, "It depends."

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Koshchi wrote:
Quote:
it exists until explicitly destroyed with del
You mean delete.

Or delete[].

Sid

Life... is a state of mind

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Or delete[].

IIRC, The Arduino runtime does not support "delete[]" (or the equivalent "new[]"

(Hmm. Very recently added: http://code.google.com/p/arduino...
See also http://code.google.com/p/arduino... )

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
The flash footprint is ( of course ) a one time cost dependent upon the construction of the program.

Side note: Some of the "one time cost" is on RAM also - see many earlier discussions here on the vtable for a class being in RAM.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Does it help that it is not a huge amount of code

The descision to "go Object Oriented" or not should not be based on the size of the code.

Quote:
or is it just a Bad Idea?

Generally speaking: Absolutely not.

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...)

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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.

Regards,
Steve A.

The Board helps those that help themselves.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

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

As with most things in engineering, the answer is an unabashed, "It depends."