Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #8458 > unrolled thread

STL container and stack frame size

Back to article view | Back to comp.lang.c++

Contents

  STL container and stack frame size itt ium <ittium@gmail.com> - 2011-08-04 03:13 -0700
    Re: STL container and stack frame size "Alf P. Steinbach" <alf.p.steinbach:usenet@gmail.com> - 2011-08-04 12:19 +0200
    Re: STL container and stack frame size "Paul" <pchristor@yahoo.co.uk> - 2011-08-04 13:14 +0100
      Re: STL container and stack frame size "Paul" <pchristor@yahoo.co.uk> - 2011-08-05 21:34 +0100
    Re: STL container and stack frame size Juha Nieminen <nospam@thanks.invalid> - 2011-08-04 14:21 +0000
      Re: STL container and stack frame size ittium <ittium@gmail.com> - 2011-08-09 10:12 +0530
        Re: STL container and stack frame size Ian Collins <ian-news@hotmail.com> - 2011-08-09 16:49 +1200
        Re: STL container and stack frame size Asger-P <junk@asger-p.dk> - 2011-08-09 09:25 +0200

#8458 — STL container and stack frame size

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

[toc] | [next] | [standalone]

#8459

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

[toc] | [prev] | [next] | [standalone]

#8462

"itt ium" <ittium@gmail.com> wrote in message 
news:6ebc4e08-8383-4284-982c-d84d1045266a@a2g2000prf.googlegroups.com...
> 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.
The size of the structure won't affect the size of a STL container. STL 
containers, by default, allocate on the heap.
The number of elements will increase the size of a vector but this is not 
multiplied by the sizeof(structure), it is multiplied by sizeof (pointer to 
structrue).

HTH
Paul.


--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

[toc] | [prev] | [next] | [standalone]

#8495

"Paul" <pchristor@yahoo.co.uk> wrote in message 
news:j1e2f8$2e1t$1@adenine.netfront.net...
>
> "itt ium" <ittium@gmail.com> wrote in message 
> news:6ebc4e08-8383-4284-982c-d84d1045266a@a2g2000prf.googlegroups.com...
>> 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.
> The size of the structure won't affect the size of a STL container. STL 
> containers, by default, allocate on the heap.
> The number of elements will increase the size of a vector but this is not 
> multiplied by the sizeof(structure), it is multiplied by sizeof (pointer 
> to structrue).
>
Actually the size of a vector is not necessarily a multiple of the number of 
elements as it could easily allocate a mass lump of memory and just index 
that memory in chunks of sizeof(pointer to structure).
But nevertheless the size of the structure will still not affect the size of 
the vector as its still dynamic allocation.
GL
Paul. 


--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

[toc] | [prev] | [next] | [standalone]

#8468

itt ium <ittium@gmail.com> 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.

[toc] | [prev] | [next] | [standalone]

#8573

On 04-08-2011 PM 07:51, Juha Nieminen wrote:
> itt ium<ittium@gmail.com>  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

[toc] | [prev] | [next] | [standalone]

#8574

On 08/ 9/11 04:42 PM, ittium wrote:
> On 04-08-2011 PM 07:51, Juha Nieminen wrote:
>> itt ium<ittium@gmail.com>   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

[toc] | [prev] | [next] | [standalone]

#8580

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

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c++

csiph-web