9 hours ago, Bregma said:No recent C++ compiler supports VLAs in C++.
Are you sure about that? I just tried it with GCC 7.3.0 and Clang 6.0.0 and both compiled a test program without complaints.
MSVC in comparison reports an error.
9 hours ago, Bregma said:No recent C++ compiler supports VLAs in C++.
Are you sure about that? I just tried it with GCC 7.3.0 and Clang 6.0.0 and both compiled a test program without complaints.
MSVC in comparison reports an error.
They don't support VLAs. They support something similar to C's VLAs, but with several differences.
GCC, Clang, and Intel compilers support this proposal as an extension, which was considered and denied by the working group around 2012. It has some known flaws, like trying to make pointers to VLA types or taking their size or address, that probably will never be universally resolved. It also has some hidden costs for creating and managing them that the committee members don't like, which are worse in C++ than the similar penalties that come from VLA's in C.
This is C++. Dynamic arrays are part of the language, the term is std::vector.
8 minutes ago, frob said:This is C++. Dynamic arrays are part of the language, the term is std::vector.
Correct me if I'm wrong, but doesn't str:: vector allocate memory from the heap? Seems like it's not really the same thing. I'm also wondering how many compilers don't support alloca.
12 minutes ago, Gnollrunner said:Correct me if I'm wrong, but doesn't str:: vector allocate memory from the heap? Seems like it's not really the same thing. I'm also wondering how many compilers don't support alloca.
From what I know if you don't create the vector using new, the vector object itself is on the stack, but the contents within are on the heap by default. If you use new, then the object along with the contents are on the heap by default. It defaults to the heap as it uses the default allocator.
Please correct me if I'm wrong.
http://www.cplusplus.com/reference/vector/vector/
http://www.cplusplus.com/reference/memory/allocator/
http://www.cplusplus.com/reference/memory/allocator/allocate/
12 minutes ago, Rutin said:From what I know if you don't create the vector using new, the vector object itself is on the stack, but the contents within are on the heap by default. If you use new, then the object along with the contents are on the heap by default. It defaults to the heap as it uses the default allocator.
Yes, I should have been more explicit. What I meant was the array portion itself is on the heap. I suppose you can change allocator but if there is no way to allocate variable data on the stack, I'm not sure where else it would go but on a heap. I guess you could use a different implementation for compilers that support variable stack allocation, but I don't see a way to do a single C++ complaint stack allocator.
But that gets back to the original problem of the thread, a crash after running out of stack space.
The stack is a limited commodity. Running out of stack space is a fatal error.
You don't need to pay the relatively heavy cost of a heap allocation from the operating system. Custom memory pools are the norm in games, and you can use a custom allocator quite easily.
If you really want to explore keeping it on the space-limited stack, or not doing an extra allocation for a collection's contents there are small object optimizations available. The std::string class is designed for an optimization so they don't allocate heap space for small strings, depending on the library you can allocate from 15 to 23 bytes in a std::string before it requires heap space. That optimization required slight modifications for equality (because data is stored in potentially different places) and to iterators (because they iterate over different locations) so you won't see the same for std::vector. There are vector implementations out there with a similar small buffer optimization, using what would have been the information about the pointer on the heap to store data when it is quite small. It can be worth it if you have many thousand items with only a few bytes each and you want to avoid the indirection, but that's the exception rather than the rule.
But since the original question was about dynamic allocation of arrays rather than the limited optimization of avoiding heap allocations, the answer is still to use std::vector unless there is a specific reason not to in a specific instance.
1 hour ago, frob said:But that gets back to the original problem of the thread, a crash after running out of stack space.
The stack is a limited commodity. Running out of stack space is a fatal error.
It's easy to increase. I personally don't see it as so limited and running out of stack space is not a problem limited to this particular usage.
1 hour ago, frob said:You don't need to pay the relatively heavy cost of a heap allocation from the operating system. Custom memory pools are the norm in games, and you can use a custom allocator quite easily.
In my experience you gain much more from custom memory pools if objects are small and of fixed size or of some limited rage of sizes. If you are doing general allocation you end up trying to beat the guys who earn their living making this stuff fast, which is a much harder task.
IMO it's mostly better to go with the stack allocation where you can just because 1) it's faster and 2) it doesn't add to heap fragmentation. The OP apparently doesn't really need to grow or shrink the data after their array is created. They just need to allocate it at a given size at run-time. Another option is to use std::vector and then use an alloca based allocator where available and a normal heap based allocator where it's not. Perhaps the difference is small between the two but I try not to second guess someone's specific use case if they haven't fully detailed it.
What is this fixation with allocating from the stack? Better solutions that use standard, portable C++ have been provided. The dangers and pitfalls of dynamic stack allocation have been amply explained and demonstrated. No extenuating circumstances have been presented, and even if they had it's highly doubtful stack allocation would be the appropriate solution. It's clear from contextual clues that the OP is struggling with the basics and just needs something that works so they can move on. I don't see how this could be more cut and dried.
12 hours ago, Gnollrunner said:It's easy to increase. I personally don't see it as so limited and running out of stack space is not a problem limited to this particular usage.
That's besides the point. You can't detect how much stack space is remaining, nor can you even attempt an allocation without overflowing should there be insufficient space. Essentially, your application may or may not crash depending on conditions you can't detect, and there's nothing you can do about it. This is the type of code that should be rooted out, not endorsed.
13 hours ago, Makusik Fedakusik said:You have only 1Mb of stack. Use std::vector or std::array
std::array is just a wrapper for c-style arrays, so in that context is going to use the stack.