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