Jump to content
  • Advertisement
Sign in to follow this  
noodleBowl

MyClass myClass VS myClass = new MyClass()

This topic is 958 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I was wondering if someone could tell me the difference between:

MyClass class;

And
 

MyClass *myClass;
myClass = new MyClass();

Other than the second block of code is making a dynamic memory allocation and that I must delete it when I'm done with it otherwise I'll suffer memory leaks.

 

But what I mean is which one should I be using the most? Does it matter even?

Would it be bad to have all of my custom classes created using the dynamic memory way?

 

Share this post


Link to post
Share on other sites
Advertisement
In addition to what Juliean said, I see no reason to write code like that anymore. Why not start like this:
std::unique_ptr<MyClass> myClass;
// ...
myClass.reset(new MyClass());

Share this post


Link to post
Share on other sites
I always try to favor the first method whenever I can. Especially for temporary values on the stack. I use a pointer whenever I need polymorphism, the value is optional, or the value cannot be initialized right away.

Share this post


Link to post
Share on other sites
I am with HappyCoder: Unless I have a reason not to, I generally use the stack as much as possible. You won't normally run out of stack space because the large memory gobblers are typically standard containers, which use dynamically-allocated memory anyway.

I think using pointers and new for everything is a sign that you should have stayed in Java. smile.png

Share this post


Link to post
Share on other sites

I think using pointers and new for everything is a sign that you should have stayed in Java. smile.png

 
This is what I'm trying to avoid. Making all of my C++ very Java esque
 
What is the general consensus on creating objects on the stack and then having to call an init function?
MyClass myClass;
myClass.Init();
But I kind of feel like this is counter productive to the constructor of the class
 
The reason I ask all of this is, well, long story short. I'm currently working in Android and struggling with class creation when they use OpenGL calls in their constructors.
As they need a valid OpenGL context in order for them to work/not crash the application. I would like to have my classes created on the stack, but because my constructors have OpenGL calls in them I need a valid OpenGL context created first. This is where I'm not sure how to handle them as things like:
 
void MainLoop()
{
	bool run = true;
	while(run)
	{
		PollForEvents();
		if(TeminateSignaled)
			run = false;
			
		if(window->OpenGLContext->Inited() == false)
			continue;
		
		//Would like to create objects on the stack. This object uses OpenGL calls in its constructor.
		//Not sure how to do this without either: Keep on creating it (super bad) or having it stuck in local scope
		/*
		
			if(window->OpenGLContext->Inited() == false)
				continue;
				
			if(firstRun)
			{
				SpriteBatcher batcher; //not sure how to use out of local scope
                                firstRun = false;
			}
		
		*/
		
		SpriteBatcher batcher; 
		
		window->OpenGLContext->ClearBufferBits();
		window->OpenGLContext->SwapBuffers();
	}
}
Hope my issue above makes sense, never really had to wait for a window callback (Android triggers onNativeWindowCreated when the window is ready to display / used)in order to tie a OpenGL context to it. Always had something along of the lines of create the window right now and then use it

Share this post


Link to post
Share on other sites

The stack requires that the lifetime of your object be known and fixed at compile-time. Indeed, the compiler depends on it to generate the proper stack framing code. The code you have now can't satisfy those conditions because it must wait some indeterminable amount of time before the window is created, thus requiring late-binding and heap allocation.

 

However let's say you re-arrange your code like this:

void MainLoop()
{
    while(!window->OpenGLContext->Inited()) { /* handle exit */ }

    // Guaranteed OpenGL context is initialize
    SpriteBatcher batcher(window->OpenGLContext);
    
    bool run = true;
    while(run)
    {
        /* main loop stuff */
    }
}

Your code waits until the OpenGL context is initialized before creating the sprite batcher, which can be created on the stack because it's lifetime can be entirely code-driven.

Share this post


Link to post
Share on other sites


I've never overflowed the stack outside of bugs and intentional tomfoolery. In fact, I find the default stack length on Win7/VS2015 to be uncomfortably large as it takes too long to overflow when I screw up a recursion or something. (Looking it up, apparently it's only 1MB, lol)

 

In hindsight, I wonder why I wrote "you are going to run out very, very soon", formulating it that way really makes no sense. I quess I had situations back in mind where you had large static arrays of thousands of elements:

int array[150000]; // theres half your stack for you

But its right, realistically you won't run out of stack space anytime soon.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!