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).
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).
You can test it yourself, start by declaring a small vectorarray and keep increasing it's size.
Fixed that for you ;)
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.
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>'.Isn't required stack length included in the module header?
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.
No, it's just a different kind of smart pointer. unique_ptr is more or less an upgraded version of auto_ptr.Is unique_ptr managed code ???