c: *bloats memory allocation with size information, cause stupid ass programmer can't keep track of a number*
stupid ass programmer: *still has to keep track of the size to be able to use the memory in any meaningful way*
🇳🇱
@namark the ineffiencies in raw C are a legitimate problem and why, particularly when it comes to memory management, things like Java can be 40x faster or more out of the box.
Slated memory allocation in C is ultimately the way to go but since its not built-in a lot of programmers dont do it.
That said nothing stopping someone from coding up C properly and making sure they do exactly that. I just wish more coders did.
@freemo there is no one true way to manage memory, java maybe faster at untangling the kind of spaghetti code java fanboys write, but that's not my point, I'm talking about inflexibility of malloc/free in context of optimization of whatever memory management one would want to design for particular purpose, and since it's at the interface level, if you want to do anything more clever you'll have wave goodby to any library code that allocates.
@namark no we arent talking spagehti code, nothing to do with that. We are literally talking about a single operation, memory allocation.. Java's new vs C's malloc, and java's new is substantially faster out of the box compared to C's malloc.
@freemo you are comparing apples to oranges, malloc would be long done by the time java's vm boots and gets to do whatever new even means in that language. You only care about that single new vs single malloc, if you plan on spreading allocations all over the place without thinking of any kind of overall memory management strategy. Not my point at all.
@namark thats exactly what i said, java slates its memory, thus faster than calling malloc on a per-oobject basis in C (which is often how its done, despite not being the proper approach).
As I already stated early to get the performance of java's new operation one would have to pre-slate memory in C. Certainly doable but often not done due to the extra effort when you get that out of the box for free.
My point is, memory handling in C is more tedious to make performant for many often leading to the effort not being made at all.
@freemo yes I'm saying that exact thing you said, has nothing to do with what I originally meant.
At the same time you try to present Java's memory management as something good, while I'm dunking on it, but that's kind of tangential.
@namark I never claimed it was relevant directly to what you original meant. Its relevance is that both are "things people complain about in C's memory management", that is all.
I am also not presenting Java's memory system as good anymore than I am saying C's memory management system is good. Both are different tools for different purposes and if you think either is the "end all and be all" of what represents a good language, then you are wrong in either case.
Java's memory management means really good performance out of the box. C's memory management is much slower out of the box but with significantly more upfront effort its performance can match or even exceed that of Java's. Therefore both server a purpose depending on your needs.
@freemo Don't think my OP is a "thing people complain about in C's memory management". I believe most everyone are perfectly happy with not having to specify the size in free(), and that is philosophically in line with wanting increasingly more clever allocators and GCs.
Other than that the only difference is what you call "out of the box" I call "for the purposes of writing spaghetti code".
@namark Yea I understand your (incorrect) opinion. It is perfectly possible to write good clean code that isnt spaghetti code in Java as it is possible in most languages. Simply saying a thing doesnt make it so. That said its also possible to write spaghetti code in any language, including C.
Like I said anyone who thinks their language is the only one possible to write good code in no matter the scenario is already behind the 8 ball.
@freemo I mean shagetti in terms of memory management specifically not anything else. That's the whole point of garbage collected languages, the whole philosophy, you want to forget a memory management is a thing and have some magic that takes care of it for you. How can you both forget the problem exists and also design a good solution for your specific application?
Can you sometimes get away with forgetting memory management is a thing? Sure. Other times you end up in a predicament, where you have to study the internals of the garbage collector and somehow someway get it to do some trivial thing you want, that it just won't do properly.
So yeah, with C you won't go very far writing code like that, with java you could, and you might get far enough for whatever purpose, but further you go, harder it'll be to untangle the mess.
@namark A good example of this at play is actually the Aparapi app I wrote. It started as relatively pure Java, then the parts that made more sense as C were replace with JNI (basically C code integrated into Java). In the end the app uses C when memory management or low level control has an advantage, and Java where it serves no advantage.
Since it was written well there was no issue of "untangling", the boundaries were always clearly defined. Doing the whole thing in C from the get go would have been the wrong move just as doing it all in Java was the wrong move...
right tool for the job.
@freemo more like wrong tools for the wrong job if you ask me