malloc/free are for heap based allocations. The grand parent explicitly mentioned he was referring to stack based allocations, which are kind of automatic (implicit).
The stack is fully automatic arbitrary memory and has nothing to do with registers. You can allocate as much as you want (including e.g. bytearrays), until you run into the allocated stack limit. That limit can be arbitrary, and some languages even dynamically scale the stack.
That you also have access to manual memory on the heap doesn’t matter. You can also do manual memory management in Rust if you want, as one has to do at times.
Ok. Then manual memory applies to just heap memory management.
It's not rocket science. If you are calling malloc/free to maintain your memory you're doing manual memory management.
> You can also do manual memory management in Rust
You can do Garbage Collection in C, it doesn't make it Garbage Collected language.
You're confusing default memory management with what's possible.
By your logic, Arena allocators can be used in many different languages, including GC ones like Java. So that means GC languages like Java are manually memory managed. Which is defeats the definition of it.
> It's not rocket science. If you are calling malloc/free to maintain your memory you're doing manual memory management.
Sure, and when I do the same in Rust I'm also doing manual memory management. So by your definition, both Rust and C are manual memory languages.
> You're confusing default memory management with what's possible.
Ah, so we care about the default, which I pressume is what the language semantics themselves provide, rather than focusing on what the standard libraries can provide you?
In that case C is an automatic memory language, because the language semantics only provide you stack memory. malloc/free are just random functions in the standard library after all, just like Rust's `Box::new` and `std::alloc`.
See, the point is that you're opting into manual memory management in C from an automatic model. We are so used to the stack that we forget that it's the OG fully automatic zero-cost memory management system, and in case of C++, can be used to implement fully automatic heap memory as well - in which case you never need to call malloc/free/new/delete.
(And no, it doesn't count that your smart pointer calls new/delete, because then you also need to count Box::new calling std::alloc)
> By your logic, Arena allocators can be used in many different languages, including GC ones like Java.
Uh, even in bog standard Java without any shenanigans you are using an "arena allocator". A GC doesn't change how allocators work, it just responsible for calling free.
(Caveat about moving vs. non-moving garbage collectors and ones that have multiple arenas, but that's not relevant here and an entire topic of its own.)
> You're being very thick on purpose. In Rust you need to reach for foreign functions to implement malloc/free.
I think you're mistakenly thinking of calling out to the (rust-lang maintained) libc crate's malloc/free functions. That's not the case - the standard library provides `std::alloc`, which is the allocator also backing Box and Vec.
> No. By my definition what is the default semantics determines if it's manual or automatic. It's CS 101.
Your definition of default semantics - "in C it's not what the language does but what happens when you call random library functions, while in Rust it's the opposite" - makes no sense at all.
C isn't considered a manual language because of default semantics, but because people have chosen to mainly rely on such paradigm.
> No, no you aren't. At least not explicitly. I assume you mean GC, if it has or doesn't have arenas is implementation detail.
Yes, whether any allocator has an arena is an implementation detail.
Whether you call `malloc` or `new`, or you have Go or Java do a heap allocation for you (which, to nitpick, is not actually the job of the garbage collector), the use of an arena is an implementation detail. In case of GC, the availability of optimizations also depend heavily on whether it's a moving GC.
allocates a byte on the stack, binds it to a variable named x, sets it to 1, then deallocates it from the stack. There is no explicit allocation or deallocation.
As an optimization it can be put into a register instead of the stack, again without explicit allocation and deallocation (this is done by the compiler playing musical chairs with registers).
I would not consider this manual. Manual would instead be something like in embedded programming
int8_t* y = (int8_t*)0xB4DC0FF3;
*y = 1;
because one needs to keep track of used memory locations (do allocation management)
Stack based allocation are essentially registers, right?