why new dynamic stack allocation in C++?

T

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.
 
S

Shea Martin

Tom said:
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
 
B

Bell

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.

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.
 
S

Shea Martin

Bell said:
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.

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
 
D

Dave O'Hearn

Shea Martin said:
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.
 
P

Peter van Merkerk

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.
 
S

stelios xanthakis

Bell said:
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.

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
 
E

E. Robert Tisdale

Tom said:
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.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top