By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,238 Members | 1,859 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,238 IT Pros & Developers. It's quick & easy.

why new dynamic stack allocation in C++?

P: n/a
Tom
What I mean is why can I only allocate const size stuff on the stack in C++? If I want to allocate a variable amount I need to use the OS API (Win32 in my case).

Thanks,
Tom.
Jul 22 '05 #1
Share this Question
Share on Google+
9 Replies


P: n/a
"Tom" <bl**@blah.com> wrote...
What I mean is why can I only allocate const size stuff on the stack in

C++? If I want to allocate a variable amount I need to use the OS API
(Win32 in my case).

What are you talking about? Please read the FAQ 5.8. You can
find FAQ here: http://www.parashift.com/c++-faq-lite/

Victor
Jul 22 '05 #2

P: n/a
Tom wrote:
What I mean is why can I only allocate const size stuff on the stack in C++? If I want to allocate a variable amount I need to use the OS API (Win32 in my case).

Thanks,
Tom.

That is the whole point os having a stack and a heap! If you want to
allocated space, of amounts unknown at compile time, but known at
runtime, then you use the heap.

Java is the same.

Not sure about other langs.

~S

Jul 22 '05 #3

P: n/a
"Shea Martin" <sm*****@arcis.com> wrote in message
news:uZLyb.16132$f7.770588@localhost...
Tom wrote:
What I mean is why can I only allocate const size stuff on the stack in C++? If I want to allocate a variable amount I need to use the OS API
(Win32 in my case).
Thanks,
Tom.

That is the whole point os having a stack and a heap! If you want to
allocated space, of amounts unknown at compile time, but known at
runtime, then you use the heap.

Java is the same.

Not sure about other langs.

~S


I don't agree. There is a good reason to do dynamic allocation on the
stack. When I allocate I do:
(1) automatic (stack) allocation, with objects of fixed (compile time)
sizes.
(2) dynamic (heap) allocation, with the new operator.
(3) dynamic heap allocation using _alloca (win32 only). I only do this with
speed sensitive code. So, instead of writing something like this:

void MyFunc( size_t s )
{
char* p = new char[ s ];
....
delete p;
}

I write something like this:

void MyFunc( size_t s )
{
char* p = (char*) _alloca( nBufSize + 1 );
....
}

So, am I missing something? Is this not faster?

Tom.
Jul 22 '05 #4

P: n/a
Bell wrote:
"Shea Martin" <sm*****@arcis.com> wrote in message
news:uZLyb.16132$f7.770588@localhost...
Tom wrote:
What I mean is why can I only allocate const size stuff on the stack in
C++? If I want to allocate a variable amount I need to use the OS API
(Win32 in my case).
Thanks,
Tom.


That is the whole point os having a stack and a heap! If you want to
allocated space, of amounts unknown at compile time, but known at
runtime, then you use the heap.

Java is the same.

Not sure about other langs.

~S

I don't agree. There is a good reason to do dynamic allocation on the
stack. When I allocate I do:
(1) automatic (stack) allocation, with objects of fixed (compile time)
sizes.
(2) dynamic (heap) allocation, with the new operator.
(3) dynamic heap allocation using _alloca (win32 only). I only do this with
speed sensitive code. So, instead of writing something like this:

void MyFunc( size_t s )
{
char* p = new char[ s ];
....
delete p;
}

I write something like this:

void MyFunc( size_t s )
{
char* p = (char*) _alloca( nBufSize + 1 );
....
}

So, am I missing something? Is this not faster?

Tom.

I have never used the _alloca() funtion. My programming experience with
the win32 api has been minimal. But I have a fairly good guess what it
does:

_alloca is allocating a chunk of memory at startup, and then just giving
it out peice by peice, until it runs out, then grabs another large
chunk. Thus, reducing the actual number of mallocs(). Similar to the
difference b/n read() and fread. Again, the gain is speed, the loss
would be possible wasted memory.

*If* my assumption is correct, you can implement similar behavior to the
_alloca function my defining operator new().

~S

Jul 22 '05 #5

P: n/a
Stack allocations cannot be dynamic. They are determined
by the local variable declarations in your code.

The following article should clarify stack operations (see the section
on function calling):

http://www.eventhelix.com/RealtimeMa...ranslation.htm

Sandeep
--
http://www.EventHelix.com/EventStudio
EventStudio 2.0 - Generate Sequence Diagrams and Use Case Diagrams in PDF
Jul 22 '05 #6

P: n/a
Shea Martin <sm*****@arcis.com> wrote:
Tom wrote:
What I mean is why can I only allocate const size stuff on the stack in
C++? If I want to allocate a variable amount I need to use the OS API
(Win32 in my case).
That is the whole point os having a stack and a heap! If you want to
allocated space, of amounts unknown at compile time, but known at
runtime, then you use the heap.


There is no intrinsic reason for this. On just about any architechure,
you can issue an instruction to "bump the stack pointer", provided
more stack-allocated memory. There is no intrinsic reason the
parameter has to be provided at compile time.
Java is the same.
In Java, all arrays go on the heap anyway, so the issue never comes
up.
Not sure about other langs.


C99 has a primitive called a "variable length array". You can do this
in C99,

void f(const char *s)
{
char new_string[strlen(s) + 1];
strcpy(new_string, s);
}

I don't believe C99 mandates that vararrays always produce stack
memory, but the intent is that an implementation will do that for
nonpathological cases. Whether or not some equivalent will get into
C++0x, no one really knows. The main argument against it (that I know
of) is that it would discourage people from using vectors. The
argument for is that everyone does it already, with nonstandard
'alloca' macros, but those macros have annoying differences on some
platforms, especially in the presense of exceptions.

--
Dave O'Hearn
Jul 22 '05 #7

P: n/a
> > I don't agree. There is a good reason to do dynamic allocation on
the
stack. When I allocate I do:
(1) automatic (stack) allocation, with objects of fixed (compile time) sizes.
(2) dynamic (heap) allocation, with the new operator.
(3) dynamic heap allocation using _alloca (win32 only). I only do this with speed sensitive code. So, instead of writing something like this:

void MyFunc( size_t s )
{
char* p = new char[ s ];
....
delete p;
}

I write something like this:

void MyFunc( size_t s )
{
char* p = (char*) _alloca( nBufSize + 1 );
....
}

So, am I missing something? Is this not faster?

Tom.

I have never used the _alloca() funtion. My programming experience

with the win32 api has been minimal.
Equivalents of alloca() can be found on other platforms too.
But I have a fairly good guess what it
does:

_alloca is allocating a chunk of memory at startup, and then just giving it out peice by peice, until it runs out, then grabs another large
chunk.


That is not the way alloca() works. The reason it is fast is that it
just decrements the stack pointer by a specified amount of bytes. The
memory "allocated" by alloca() is on the stack. As a result this
function may result in a stack overflow when trying allocate too much
memory.

Though it may be very fast, I would use this function only as a last
resort.

--
Peter van Merkerk
peter.van.merkerk(at)dse.nl


Jul 22 '05 #8

P: n/a
"Bell" <bl**@neesus.com> wrote in message news:<aR******************@news20.bellglobal.com>. ..
"Shea Martin" <sm*****@arcis.com> wrote in message
news:uZLyb.16132$f7.770588@localhost...
Tom wrote:
What I mean is why can I only allocate const size stuff on the stack in C++? If I want to allocate a variable amount I need to use the OS API
(Win32 in my case).
Thanks,
Tom.

That is the whole point os having a stack and a heap! If you want to
allocated space, of amounts unknown at compile time, but known at
runtime, then you use the heap.

Java is the same.

Not sure about other langs.

~S


I don't agree. There is a good reason to do dynamic allocation on the
stack. When I allocate I do:
(1) automatic (stack) allocation, with objects of fixed (compile time)
sizes.
(2) dynamic (heap) allocation, with the new operator.
(3) dynamic heap allocation using _alloca (win32 only). I only do this with
speed sensitive code. So, instead of writing something like this:

void MyFunc( size_t s )
{
char* p = new char[ s ];
....
delete p;
}

I write something like this:

void MyFunc( size_t s )
{
char* p = (char*) _alloca( nBufSize + 1 );
....
}

So, am I missing something? Is this not faster?

Tom.


It is faster and it also exists on linux (actually it's a matter of
compiler. alloca is implemented by decreasing the stack pointer.
alloca() is a builtin of the compiler (for gcc at least)).
So alloca is pretty safe. The problem is: what about objects
with virtual tables?

A dirty hack is:

class A { ... }; /* virtuals in there! */
A vtblpy;

int f ()
{
A *p = alloca (sizeof (A));
*p = vtblcpy;
// or
memcpy (p, &vtblcpy, sizeof *p);

p->initialization (...); // instead of ctor
}

This worked once, but you'll get an 'F' in programming from the
professors:)

Anyway, I think C# has something like that called stackalloc.
So it is useful.

stelios
Jul 22 '05 #9

P: n/a
Tom wrote:
What I mean is,
"Why can I only allocate const size stuff on the stack in C++?"
If I want to allocate a variable amount,
I need to use the OS API (Win32 in my case).
The Gnu C++ compiler will allocate variable-arrays on the stack
cat main.cc #include<iostream>

int main(int argc, char* argv[]) {
int n = atoi(argv[1]);
double a[n];
for (int j = 0; j < n; ++j)
a[j] = j;
return 0;
}
g++ -Wall -o main main.cc
g++ -Wall -ansi -pedantic -o main main.cc

main.cc: In function `int main(int, char**)':
main.cc:5: warning: ISO C++ forbids variable-size array `a'

Variable-arrays are supported by the ANSI/ISO C99 standard and
we expect that future ANSI/ISO C++ standards will adopt them as well.
Just be patient.

Jul 22 '05 #10

This discussion thread is closed

Replies have been disabled for this discussion.