stack vs heap

Started by
30 comments, last by King Mir 11 years, 2 months ago

In java, for example, I do sometimes have objects of this size

You can have. Java uses the heap too.

Your "X" varies from system to system, plus depends on how much stuff you have on the stack already(e.g are you using recursions or not).

Advertisement

You can test it yourself, start by declaring a small vectorarray and keep increasing it's size.

Fixed that for you ;)

[size=2][ I was ninja'd 71 times before I stopped counting a long time ago ] [ f.k.a. MikeTacular ] [ My Blog ] [ SWFer: Gaplessly looped MP3s in your Flash games ]

Even if you use the heap, there is rarely a reason to do so by directly writing `new' and `delete' in your program. For instance, if I need a large array (or if I am not too sure what size it will have) I use std::vector, which will allocate its data on the heap, but it does so using RAII (an acronym that never made sense to me, but it means the destructor takes care of things). If I need polymorphism, I use a smart pointer (unique_ptr, most likely) that also uses RAII.

There are still ways to leak memory when you program this way, but it's hard.

Another pitfall to look out for (one that seems obvious but have seen before) - when passing by reference and also maybe using locals is never return a reference to local data when returning from a function. Of course, the data will be popped off the stack and won't exist any more. Reads will provide "bad" data (i.e. whatever happens to be on that stack location) and writes can really screw things up!!

You can try what Hodgman said by something like this (I just find this a bit more clear!)


class MyClass
{
public:
	MyClass()
	{
		memset( &m_szName, 0, sizeof(m_szName) );
		strcat_s( m_szName, "I'm an object!" );
	}

	~MyClass()
	{
	}

public:
	char m_szName[64];
};

void DoSomethingHere()
{
	printf( "DoSomethingHere()\n" );
}

void DoSomethingElseHere( MyClass var )
{
	printf( var.m_szName );
	printf( "\n" );
}

void DoAnotherThingHere( MyClass var )
{
	memset( var.m_szName, 0, sizeof(var.m_szName) );
	strcat_s( var.m_szName, "Rewriting var.m_szName" );
	printf( var.m_szName );
	printf( "\n" );
}

int _tmain(int argc, _TCHAR* argv[])
{
	DoSomethingHere();

	{
		MyClass obj;
		DoSomethingElseHere( obj );
	}

	DoAnotherThingHere( obj );

	Sleep( 50000 );

	return 0;
}

And yes, there are certain benefits you can abuse by using code blocks like above (eg; a large command table).

Visual Studio gave me an error that obj is undefined when trying to call "DoAnotherThingHere", letting me know that "obj" would no longer exist after it has executed passed that end-codeblock.

Along the way, you'll understand when to allocate on the stack or the heap.

Are you sure about that overflow-by-array problem? I would think the compiler would just make the stack large enough. Isn't required stack length included in the module header?
void hurrrrrrrr() {__asm sub [ebp+4],5;}

There are ten kinds of people in this world: those who understand binary and those who don't.

Isn't required stack length included in the module header?

I am not entirely sure what you mean by that, but no: The stack size is usually determined by the OS. For instance, if you are using the bash shell in Linux, you can set the stack size for new processes using `ulimit -s <number_of_kilobytes>'.

About shared_ptr. I read now that that Bjarne consider this as bad idea and this is considered as bad c++ design pattern. Anyone can put some light on this.

About unique_ptr. I do NOT want to write managed code. Is unique_ptr managed code ???

Some compilers allow segmented stacks, which do not have limits on size and the stack can grow just like heap variables. Some can also convert large stack arrays to heap arrays.

Is unique_ptr managed code ???

No, it's just a different kind of smart pointer. unique_ptr is more or less an upgraded version of auto_ptr.
void hurrrrrrrr() {__asm sub [ebp+4],5;}

There are ten kinds of people in this world: those who understand binary and those who don't.

This topic is closed to new replies.

Advertisement