«

Group,
This might be a very obvious question but a simple google search did
not reveal much. I am designing a software where different functions
make local copies of vectors, map and hash map containing big size
structures. I was concerned about following

if the vector is of big size, making a local variable will occupy lot
of stack space and may result in stack overflow.

With map, it seems problem may not be likely since map is a binary
search tree so only head pointer will be pushed to the stack.

I am not able to visualize the local hash map variable with respect to
stack frame.

Please let me know your thoughts on it.

thanks
ittium

On 04.08.2011 12:13, itt ium wrote:
> Group,
> This might be a very obvious question but a simple google search did
> not reveal much. I am designing a software where different functions
> make local copies of vectors, map and hash map containing big size
> structures. I was concerned about following
>
> if the vector is of big size, making a local variable will occupy lot
> of stack space and may result in stack overflow.

No.

But you are still into using lots of memory.


> With map, it seems problem may not be likely since map is a binary
> search tree so only head pointer will be pushed to the stack.

It's the same with vector etc.



> I am not able to visualize the local hash map variable with respect to
> stack frame.
>
> Please let me know your thoughts on it.


Cheers & hth.,

- Alf

itt ium <> wrote:
> if the vector is of big size, making a local variable will occupy lot
> of stack space and may result in stack overflow.

Nope. There's a very simple way of seeing how much stack space an
object takes, namely:

void foo()
{
std::vector<int> v(10000);
std::cout << "v is taking " << sizeof(v) << " bytes of stack space.\n";
}

Here it says "v is taking 12 bytes of stack space."

The rest is allocated on the heap.

On 04-08-2011 PM 07:51, Juha Nieminen wrote:
> itt ium<> wrote:
>> if the vector is of big size, making a local variable will occupy lot
>> of stack space and may result in stack overflow.
>
> Nope. There's a very simple way of seeing how much stack space an
> object takes, namely:
>
> void foo()
> {
> std::vector<int> v(10000);
> std::cout<< "v is taking "<< sizeof(v)<< " bytes of stack space.\n";
> }
>
> Here it says "v is taking 12 bytes of stack space."
>
> The rest is allocated on the heap.

This means, we really do not have any situation, where we should define
STL containers with pointers. Container with normal variables are
sufficient for most of the cases.

Ittium

On 08/ 9/11 04:42 PM, ittium wrote:
> On 04-08-2011 PM 07:51, Juha Nieminen wrote:
>> itt ium<> wrote:
>>> if the vector is of big size, making a local variable will occupy lot
>>> of stack space and may result in stack overflow.
>>
>> Nope. There's a very simple way of seeing how much stack space an
>> object takes, namely:
>>
>> void foo()
>> {
>> std::vector<int> v(10000);
>> std::cout<< "v is taking"<< sizeof(v)<< " bytes of stack space.\n";
>> }
>>
>> Here it says "v is taking 12 bytes of stack space."
>>
>> The rest is allocated on the heap.
>
> This means, we really do not have any situation, where we should define
> STL containers with pointers. Container with normal variables are
> sufficient for most of the cases.

Except where the object is "large", dynamically allocated, isn't
copyable or you don't want to copy it...

--
Ian Collins

Hi ittium

On the: 09. of august-2011 At: 06:42 ittium wrote:

>> Here it says "v is taking 12 bytes of stack space."
>>
>> The rest is allocated on the heap.
>
> This means, we really do not have any situation, where we should define
> STL containers with pointers.

Ooh, there is plenty of situations, for instance if do a lot of:
sorting, inserting or deleting in the middle. And You still need
the by Index acces of the vector.

std::vector is quite slow though, for pinter only, having a pointer
only vector template works a lot faster.


Best regards
Asger-P