Why does C++ still not have a stack allocator in the stdlib?

>>105778289 (OP)
Because Bjarne is a nigger and the committee are Jews incapable of delivering.

>>105778289 (OP)
so sorry sir, we add it to spec asap

>>105778289 (OP)
You can do it with the PMR allocator so nobody has bothered

>>105778354
this is the region i hate sepples. i wouldn't give a shit about the titanic complexity if it actually covered all the basics. but the standards committee is too busy yak shaving over new syntax decorations to bother with actually useful shit.

>>105778437
there's no standard way to allocate on the stack at all.
alloca isn't guaranteed to do what you think it does, and it's not blessed by the standard so there are whole classes of compiler optimizations that can't happen because of that.
it's also really buggy.

>>105778354
this is the reason i hate sepples. i wouldn't give a shit about the titanic complexity if it actually covered all the basics. but the standards committee is too busy yak shaving over new syntax decorations to bother with actually useful shit like this.

>>105778437
there's no standard way to allocate on the stack at all.
alloca isn't guaranteed to do what you think it does, and it's not blessed by the standard so there are whole classes of compiler optimizations that can't happen because of that.
it's also really buggy.

>>105778596
>still no networking and process library to this day

>>105778596
yes there is, it's with the monotonic_buffer_resource (https://en.cppreference.com/w/cpp/memory/monotonic_buffer_resource.html).
You mean dynamically? Then yeah, the standard doesn't offer that. You still need to define the size of the array at compile time

>>105778651
>two reflection standards that compilers refuse to implement

>>105778289 (OP)
I don't get why programming languages try so hard to abstract away how computers work to such a degree that it's downright detrimental to the language in every aspect.

>>105778671
>You mean dynamically? Then yeah, the standard doesn't offer that. You still need to define the size of the array at compile time
yes, that is what i mean.
c had dynamic stack allocations in the standard through VLAs since c99. most new systems languages support it to some degree. i don't know why the fuck the standards committee refuses to add this to the language.

>>105778704
To allow "programmers" who don't understand how computers work to produce working* code

Programming is one of those disciplines that suffers from its own success. Every "advancement" made in programming language design makes the end result worse in the long term by making programming more accessible to unskilled and uninterested labourers who just want to get paid, and thus produce lower quality software

>>105778704
a few reasons
>not all computers work the same
>an OS imposes a standard on top of the computer that has to be followed, different OSes have different standards, even OSes in the same "family" can be wildly different
for example if you're on arm, risc-v, or x86s your cpu doesn't really have a sense of stack vs heap, that's a convention imposed by your operating system.
the idea of C and C++ is that the standard can target a vague register machine and the compiler can map that pretty efficiently to any given (normal) architecture and operating system family in a relatively straightforward way.

additionally, the core idea of programming language design is that you abstract lower level details away with "sane defaults" for a given domain. you prioritize the expressability of certain concepts in a certain way, because that ultimately means you're writing simpler code which means working much faster and can debug your software much more easily.

also, at this point it's not just programming languages. machine code and assembly languages are very abstract and don't reflect the hardware at all. there's even undefined behavior at what used to be the "atomic" level of programming. think of what a cacheing, pipelining superscalar cpu is like under the hood, think of how many raw things get hidden from you. did you know your modern x86 cpu has over 500 registers per cpu? did you know when you write something like
mov eax, [ebp+8]

[ebp+9] is not an expression, it's literally translated into a special and specific piece of silicon that's been hardwired into the cpu.

as for why c++ is an utter failure in this particular instance? it's because the standards committee are bad at their job. for serious programmers with mechanical sympathy, the problem with sepples was never the footguns, but the retarded standards committee having no idea what the fuck they're doing.

>>105778915
Modern CPUs don't even execute your code in the expected order.

>>105778915
>for example if you're on arm, risc-v, or x86s your cpu doesn't really have a sense of stack vs heap
On one hand yes but otherwise it's pretty much implied to exist in some form by the language anyways due to the lack of limit on the amount of local variables, and i don't think it's efficient to handwave the existence of all that away in a vauge manner and also to provide 0 safeguards about its actual limits that are not implementation defined.
>additionally, the core idea of programming language design is that you abstract lower level details away with "sane defaults" for a given domain
That's understandable i just don't think they were done as well as they should have been.
>[ebp+8] is not an expression, it's literally translated into a special and specific piece of silicon that's been hardwired into the cpu.
Yeah i know.

>>105779495
They're functionally GPUs with less execution units, higher clocks and a greater emphasis on conditional code, hyperthreading just makes that even more obvious.