3

I am helping program a game in c++ for the Nintendo DS (It has about 3MB of RAM). For all the menus in the interface, a "button" used to be created by calling void function that sets the background tiles to a button. There are at least 30 buttons throughout the interface. Now I've created a button class that stored its position, label, along with other data values. Now my question is:

Will all these new button objects affect the RAM usage (Or other performance aspects) after the program leaves the object's scope?

Or will the object automatically be discarded once the program leaves the function it was created in?

Here is some code:

#include "Button.h"

void titlescreen() //Called to create main menu
{
    Button singlePlayer = Button(4, 5, "Single Player");
    //Creates button at coord (4,5)

    Button multiPlayer = Button(4, 8, "Multi Player");
    bool chosen = false; //Whether an option has been clicked

    while(!chosen)
    {
        //Menu stuff here
    }
}

Button.h:

#include <stdio.h>
#ifndef BUTTON_H
#define BUTTON_H

class Button
{
public:
    int length;
    int x, y;
    bool isColored;
    void setColored(bool);
    void setDefault();
    button(int, int, const char * const); //Constructor
    button(int, int, const char * const, int); //Constructor
};


#endif  /* BUTTON_H */
T.C.
  • 133,968
  • 17
  • 288
  • 421
Matthew D. Scholefield
  • 2,977
  • 3
  • 31
  • 42
  • 2
    The `Button`s in the code presented are created with automatic storage and will therefore be freed when `titlescreen()` returns. – dlf Jun 26 '14 at 20:05
  • 1
    But should that be `class Button` (with a capital "B")? – dlf Jun 26 '14 at 20:07
  • Once a value object( no new operator used ) goes out of scope, it is destroyed. The object is placed on the stack. If the new operator is used to get a pointer to an object, it must be explicitly deleted with the delete keyword at some point to be removed from memory. Use the former WHENEVER you can. It's generally faster and much safer. It can also be even safer than conventional garbage collection because you know EXACTLY when things are happening. – Ben Jun 26 '14 at 20:08
  • @dlf fixed that; I accidentally had a typo in the simplified code when retyping it :). – Matthew D. Scholefield Jun 26 '14 at 20:35

2 Answers2

6

Yes, objects are destroyed when they go out of scope (i.e. the destructor of the Buttons are called). So singlePlayer and multiPlayer will be destroyed when program returns from the function titlescreen.

So, as long as the destructor of Button cleans up everything, the buttons won't affect the RAM usage after the function returns.

Also, you should include the C++ header file cstdio instead of the c-header stdio.h.

Sedenion
  • 5,421
  • 2
  • 14
  • 42
6

Though your terminology is lacking, the code you wrote allocates the objects "on the stack", and so only last as long as your scope.

In fact, you can write it even more concisely:

//Button singlePlayer = Button(4, 5, "Single Player");  // bad, uses the copy constructor
Button singlePlayer(4, 5, "Single Player");             // uses just a constructor call

Anyway an important thing you should be aware of is that since you're using the "stack" to hold your objects, whether or not you're "allocating" or "freeing" them your "RAM usage" will not change. The "stack" in most implementations is a pre-allocated chunk of memory that never expands, it just throws stack overflow exceptions (or your framework equivalent, I think C has a signal for it?) when it fills up. So generally using your "stack" up on objects is a bad idea.

Blindy
  • 65,249
  • 10
  • 91
  • 131
  • Many implementations have the stack grow towards the heap memory. There is a possibility to overflow the stack. Large amount of variable allocationm, recursive function calls or deep function calls are contributors to stack overflowing. – Thomas Matthews Jun 26 '14 at 20:28
  • So are you saying that due to the limited stack size, I just should ensure not to use too many objects at the same time, but if they are not all in the same scope it should not be a problem? – Matthew D. Scholefield Jun 26 '14 at 20:40
  • I would say generally to avoid the stack for anything that you don't need a stack for. Its purpose is to allow parameter passing, and in particular recursion. If you're not inside a recursive function, you probably shouldn't put the thing on the stack unless it's like an integer or something. – Blindy Jun 27 '14 at 04:21