0

I'd like to know if there is a standard way to allocate a variable number of objects on the stack that all today's C++ compilers support. Supposing I have a class Foo with a non-trivial public constructor that takes 0 arguments and I want to allocate 10 instances of this class on the heap, then I could use the operator new[] in C++ like this:

function doSomething() {
    Foo * foos = new Foo[10];
    ...
}

If the number of objects to allocate is not known at compile time, I could still use the operator new[] in a similar fashion:

function doSomething(size_t count) {
    Foo * foos = new Foo[count];
    ...
}

So, if I decide to allocate 10 instances of my class on the stack rather than on the heap, I'd use a regular array definition:

function doSomething() {
    Foo array[10];
    Foo * foos = array;
    ...
}

or probably just Foo foos[10]; in case I don't need to reassign foos later, ok.

Now, if the number of objects I want to allocate on the stack is only known at runtime, I use... what? The only way I can think of to dynamically allocate contiguous memory on the stack is calling the non-standard intrinsic function alloca, but I don't know what to do with objects that need initialization.

GOTO 0
  • 42,323
  • 22
  • 125
  • 158
  • 1
    _' I use... what?'_ At least GCC supports using `Foo array[n];`, where `n` is a local variable, parameter, class member, what ever ... – πάντα ῥεῖ Nov 23 '13 at 04:01
  • If I can share this... http://stackoverflow.com/q/1887097/2809095 – Iwillnotexist Idonotexist Nov 23 '13 at 04:02
  • Did you mean to say "stack" in the early part of your last paragraph instead of "heap"? – Brian Kelly Nov 23 '13 at 04:03
  • 1
    @g-makulik thanks, I think that's a non standard feature though, probably not supported by all compilers. – GOTO 0 Nov 23 '13 at 04:15
  • @GOTO0 Yes, this isn't a standard feature but will be supported by the majority of C/C++ compilers. There might be exotic ones, you'll need to use with very special MCUs. But in general you can consider this will work correctly. – πάντα ῥεῖ Nov 23 '13 at 04:23
  • 1
    The short answer to the only real question asked in this entire thing is: No, there isn't. What you want is a VLA in C++. VLA's and their inherent dangers were so well-loved by the C community they're likely being banned from future C's, so don't expect them anytime soon in C++. [A related question you might find interesting](http://stackoverflow.com/questions/1887097/variable-length-arrays-in-c) – WhozCraig Nov 23 '13 at 06:36

2 Answers2

0

What about:

std::vector<MyObject> myObjects;

int runtimeCalculatedSize = sophisticatedRuntimeSizeCalculationMethod();

myObjects.resize(runtimeCalculatedSize,MyObject());
πάντα ῥεῖ
  • 1
  • 13
  • 116
  • 190
  • Vector elements are allocated on the heap, not on the stack. – GOTO 0 Nov 23 '13 at 04:23
  • @GOTO0 Yup! You're right. Sorry I didn't take that aspect of your question in account primarily. What are your particular reasons, you don't wan to allocate objects on the heap? Lacking a suitable `new`/`delete` implementation for your environment? – πάντα ῥεῖ Nov 23 '13 at 04:28
  • Just curiosity actually. `new` and `delete` should be supported on all platforms. – GOTO 0 Nov 23 '13 at 04:36
  • @GOTO0 _'new and delete should be supported on all platforms.'_ No! Way off NO! I'm developing embedded firmware that won't be able to use heap allocation (`new`/`delete`) at all. I'm using `std::array` for known or compile time calculatable sizes, but _ehhm_, 'non portable' dynamic stack allocation as well. I'm not sure if this isn't even guaranteed by [tag:c++] standards, but not in general for usage with [tag:c]. – πάντα ῥεῖ Nov 23 '13 at 04:44
  • @GOTO0 So BTW, what are your (real) portability requirements then? Elaborate in your question ... – πάντα ῥεῖ Nov 23 '13 at 04:49
  • Ok, what I'm actually looking for is a standard compliant solution. I updated my question to put it clear. – GOTO 0 Nov 23 '13 at 05:07
  • @GOTO0 So OK! You're claiming restictions but don't elaborate why these should be really needed. Whenever you can rely on an environment supporting heap based allocation, what exactly restricts you not to use it? – πάντα ῥεῖ Nov 23 '13 at 05:10
  • Addition: If your standards' claim to have 'new/delete' guaranteed, what's your point about restricting memory association to the stackk?? – πάντα ῥεῖ Nov 23 '13 at 05:17
  • The point of the question is not to solve a real or hypothetical design problem but to get a better understanding of the C++ features. As for the `new` and delete `operators`, they are well defined in the current specification (paragraph 5.3.4 and 5.3.5), so any compliant compiler should support them. – GOTO 0 Nov 23 '13 at 05:28
  • @GOTO0 Fine! So what makes you bothering about the `std::vector` approach then?? Really, thoroughly! Feed with arguments and stuff!! (BTW: It's not about the compiler that supports `new`/`delete` by means of keywords accepted, but what the actual C++ runtime supports). – πάντα ῥεῖ Nov 23 '13 at 05:36
0

Well, if lazy, and not worried about portability, I use: Foo array[n]; This is standard C code, but has been removed from the C++ standard. But since most compilers do both, most compilers have it. The canonical way is to declare a std::vector of your type of the desired length. 

std::vector<Foo> foos(count);

But, doing that won't strictly put the data on the stack, is there any reason why using the stack is important to you?

RichardPlunkett
  • 2,998
  • 14
  • 14