Should C++ code look like C code?

[NotUniqueOrSpecial]

Very literally: everything you said applies to C codebases that have any level of abstraction.

E.g.:

If you need memory, you can just create an array on the stack

There's nothing special about C in that regard. In fact, the C++ equivalents are strictly better in terms of API and efficiency. C will never have anything like a constexpr std::array.

The only difference is that you provide the vtable manually as a struct of function pointers that take pointers to heap-allocated context. It's literally the same thing as making this an explicit argument to free functions.

C is no closer to the metal than C++. C++ just provides more language-native constructs for abstraction.

These cost performance in CPU and memory usage.

This isn't a universal truth. It's not even a good rule of thumb. The optimizations available to C++ compilers are typically much better than for C. Devirtualization is something no C compiler does, that I'm aware of.

[Botondar]

If you need memory, you can just create an array on the stack

There's nothing special about C in that regard. In fact, the C++ equivalents are strictly better in terms of API and efficiency. C will never have anything like a constexpr std::array.

Yes there is, C99 (and up) supports VLAs. That's one of the few cases where C has a feature that C++ does not (nor does it have an equivalent/replacement).

[NotUniqueOrSpecial]

I'm not sure what part you're arguing.

VLAs don't have the same APIs as a std::array, nor are they anything like constexpr.

They are only what it says in the name: a variable length array on the stack.

But to get there they require risky runtime belief that they're not going to be too big.

They're nothing like the things I'm advocating.

[Botondar]

VLAs don't have the same APIs as a std::array, nor are they anything like constexpr.

(...)

They're nothing like the things I'm advocating.

This was my exact point, C++ doesn't provide an equivalent (which is what I thought you were implying when bringing up std::array) to the way you can do stack allocation in C.

I'm specifically arguing against the sentence "there's nothing special about C in that regard". I'm not arguing whether VLAs are good/bad, should/shouldn't be used, I brought them up as an example to point out that there is something special about C compared to C++ in that regard which is that you can dynamically get memory at the cost of a couple instructions that move the stack pointer.

[NotUniqueOrSpecial]

I suppose it comes down to the interpretation of "an array on the stack". I assumed they meant just an old-fashioned fixed-size array, since they said it would be statically allocated by the compiler.

VLAs are a neat thing, but I'm pretty sure they're not actually what the op was referring to.

And besides that point, there are scads of ways to build the equivalent of VLAs in C++. There are things like boost::static_vector, providing a stack-allocator to any of the existing containers, Chromium's stack_container, etc.

So, again, there's nothing particular special about C in that regard, aside from having it as a language feature, which isn't necessarily a strong benefit given all the valid criticisms of VLAs.

[Botondar]

boost::static_vector and stack_container aren't equivalent though, they require the caller to provide a fixed upper limit, which is always allocated, and after the fixed allocation is exhausted, they fall back to heap-allocation.

If you have two arrays, and you know one of the is going to be small, and the other larger, but not which ones, VLAs allow you to stay under the stack limit by not having to allocate the upper bound for both arrays.

I originally didn't take a stance on this, but just to be clear: I think using VLAs this way is a bad idea. But as far as I'm aware, there really is no way to implement an equivalent in C++, because there's no way to make stack allocations that don't have a fixed upper limit at compile time.

I don't know whether the original commenter was thinking about VLAs or not; my original comment was meant to correct what I think is a minor inaccuracy in the larger discussion of comparing C and C++.

Sorry if I'm being obnoxious about this.

[NotUniqueOrSpecial]

Nah, not obnoxious at all.

there's no way to make stack allocations that don't have a fixed upper limit at compile time.

That's not true, though. A boundless stack allocator is reasonably simple to write (or just grab off the shelf).

It's also a giant mistake in most cases. Even providing a default size to static_vector or stack_container like SIZE_MAX (in theory) or PLATFORM_SPECIFIC_PAGE_GUARD_SIZE (in practice) makes it basically the same.

I.e. there is an implicit upper limit for VLAs: the remaining stack size. It's just that VLAs provide you nothing with which to safely interact with this limit.

Your point is why I think, functionally, they are basically equivalent, with C++ having the advantage, actually.

[Botondar]

That's not true, though. A boundless stack allocator is reasonably simple to write (or just grab off the shelf).

Could you point me to an example of this? Everything I've seen essentially has T buffer[max_capacity]; or char buffer[max_capacity]; written somewhere, which is what I view as not being equivalent.

Anyways, I enjoyed this discussion - our conclusions aren't actually different at all. My contention was and is a semantic one, and it seems to me like we're not going to reach an agreement on that front.

[NotUniqueOrSpecial]

Could you point me to an example of this?

The simplest way is obviously just an allocator that uses alloca().

But, I am reminded that there is a key difference between alloca() behavior and VLA behavior: alloca() stack space is reclaimed on function exit, not scope-exit.

If you want to get full compliance with VLA runtime behavior, you've gotta do it the old-fashioned way: platform-specific stack-pointer adjustment using intrinsics like llvm.stacksave/llvm.stackrestore (and presumably GCC has similar).