I know, but variable-length stack arrays in C99 has been criticized, so the C++ committee still haven't figured out how to do it "right" yet. vector is best we're going to get, but if you've got a fast allocator, does it matter if it's stack or heap?Originally Posted by MutantJohn
Yeah, it means a crap ton! A formal dynamic allocation is significantly slower than using the stack. Some of the best results I've gotten are because I took phantom's advice when he said that stack allocations are basically free. They really are! If you treat your stack well, it'll treat you well.
You can allocate a fixed block of heap memory at the start of your program and use that as a stack. Problem solved.
(Hence "fast" allocator.)
But that also requires a kernel to handle that request. I know that's not always a guarantee in the case of the embedded world.
In the embedded world, you can just point a pointer to some usable memory to use as a stack in your allocator. And there are usually API calls that you can use to get dynamically allocated memory on all but the simplest of embedded systems.
Move the goalposts much? Who was talking about nonemulatable features? You said C++ was a strict superset of C, and so I gave an incomplete list of some examples demonstrating the contrary.
I was actually just referring to the construct. Anyway, you can still dynamically allocate on the stack in pure C++ with alloca().
It's just "restrict" in C, but yes. This is even functionality you can't match in C++.
(Not jumping back into the argument, just never heard of alloca()) Isn't this nonstandard? Googled it and didn't see that it was standard C or C++, and not even POSIX. One of the GNU one-offs.
It's an extension, but pretty much ubiquitous across all systems. It wouldn't be part of POSIX though, since this standard doesn't deal with memory allocation of any sort.
Yes, and I can make a stack of pizza boxes. It's still not a memory stack.
Anyways, more to the point: If your purpose all along was to name functional alternatives to non-existing language features, then you already lost. Because there is too nothing that C++ does that can't be done in C.
Originally Posted by brewbuck:
Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.
Question 7.32
no bueno
Yeah, alloca has more of a code smell than a dead fish hidden somewhere in your codebase. Or you're developing specifically just for one platform and have no plans to ever, ever migrate the code away from that.
Maybe, but no more than non-tailcall, untrampolined recursion, which is very commonplace.
Why? I've never seen a general non-embedded platform that doesn't support it.
Well, the advantage of non-trampolined recursion is that it's much more portable :P
Regardless of platform support for alloca, it is a relatively moot point to argue because of VLA support which you should be using anyway. And then I read the wiki and apparently C11 made it no longer a requirement. So maybe alloca does have a place again? Maybe their reasoning is the same as yours, Yarin. That the implementation is already common enough that there's no point in making VLAs a hard requirement anymore.
Point should be that in the C vs. C++ argument, alloca means nothing because it's non-standard. If it's not part of the standard library or POSIX, then poo on it.
It could on those platforms not supporting VLAs.
It's important to keep in mind though that the C11 introduction of conditional (optional) language features is not a statement of undesired features. It merely indicates that implementations are free to not implement that language feature and set its defining macro accordingly. VLAs, along with other optional features, carry a certain burden that may not be desirable on embedded systems, but highly desirable on other systems. Hence the need to make them optional. VLAs are implemented in all major compilers for the major platforms though.
The only really controversial feature of the C11 standard is Annex K, concerning bounds checking interfaces.
Originally Posted by brewbuck:
Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.
Why do you consider it "controversial"?The only really controversial feature of the C11 standard is Annex K, concerning bounds checking interfaces.
Jim
