So, I'm trying out Google's C++ test library...

Quote:

---

Originally Posted by MutantJohn

This isn't what Yarin meant. He meant stack-based allocations. Unless you have a fancy stack allocator implementation, you shouldn't do VLAs in C++. If C supports them, awesome.

---

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?

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.

Quote:

---

Originally Posted by Elysia

...So you're going to go into stuff that don't match 1:1 between the languages, the area I decided to skip. It's true that some stuff don't match 1:1, but that doesn't mean C++ can't do it.

---

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.

Quote:

---

Originally Posted by MutantJohn

This isn't what Yarin meant. He meant stack-based allocations. Unless you have a fancy stack allocator implementation, you shouldn't do VLAs in C++. If C supports them, awesome.

---

I was actually just referring to the construct. Anyway, you can still dynamically allocate on the stack in pure C++ with alloca().

Quote:

---

Originally Posted by MutantJohn

Also, isn't __restrict__ an actual thing in C but is optionally implemented by most compiler vendors in C++?

---

It's just "restrict" in C, but yes. This is even functionality you can't match in C++.

Quote:

---

Originally Posted by Yarin

Anyway, you can still dynamically allocate on the stack in pure C++ with alloca().

---

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

Quote:

---

Originally Posted by Epy

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

Quote:

---

Originally Posted by Elysia

You can allocate a fixed block of heap memory at the start of your program and use that as a stack. Problem solved.

---

Quote:

---

Originally Posted by Elysia

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.

---

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.

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.

Quote:

---

Originally Posted by MutantJohn

Yeah, alloca has more of a code smell than a dead fish hidden somewhere in your codebase.

---

Maybe, but no more than non-tailcall, untrampolined recursion, which is very commonplace.

Quote:

---

Originally Posted by MutantJohn

Or you're developing specifically just for one platform and have no plans to ever, ever migrate the code away from that.

---

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.

Quote:

---

Originally Posted by MutantJohn

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.

Quote:

---

Originally Posted by MutantJohn

And then I read the wiki and apparently C11 made it no longer a requirement. So maybe alloca does have a place again?

---

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.

Quote:

---

The only really controversial feature of the C11 standard is Annex K, concerning bounds checking interfaces.

---

Why do you consider it "controversial"?

Jim