3 ms·

> You don't spend "complexity budget" on manual memory management. Of course you do, especially in applications where there is no benefit to be gained versus u

> You don't spend "complexity budget" on manual memory management. Of course you do, especially in applications where there is no benefit to be gained versus using a GC. This is why Java was such a huge success, despite offering very little else over C++ other than GC (I think OCaml is a much better example of a GC language). Consider that an entire book has been written on such details as move semantics. For most GUI apps, a GC or other automatic memory management has proved fine. > Gnome programs are largely still written in C, but it isn't actually C. It's still C whatever libraries are used. It's still manual memory management with footguns. This is why they created "Vala".

memefrog 3y ago
>Of course you do, especially in applications where there is no benefit to be gained versus using a GC. I am afraid you misunderstood my comment. Of course C isn't good for writing code that calls 'malloc' millions of times per second. That's just bad code, which you can write in any language. You should not be dynamically allocating memory all over the place. If you have sane allocation strategies, then having to 'manually' manage them is completely fine. >This is why Java was such a huge success, despite offering very little else over C++ other than GC (I think OCaml is a much better example of a GC language). Java is the quintessential example of a language that was made popular through marketing and hype. Getting reasonable performance out of the JVM requires far greater expertise than doing the same in C. The JVM's GC is insanely complicated and has a million different knobs which can drastically affect performance. Or they can apparently do nothing. Until you turn other knobs... >Consider that an entire book has been written on such details as move semantics. There are no 'move semantics' in C. Yet another way in which it is superior to C++. C++, which is a horrible language designed by nerds who enjoy standardese more than they love their own children, has 'move semantics' bolted on with an arcane 'rvalue references' mechanism that gets more complicated in every version of the standard. >For most GUI apps, a GC or other automatic memory management has proved fine. Retained-mode UI is something that is only reasonable with automatic memory management. The way that lifetimes of objects works in those APIs really does require a garbage collector because it's all so dynamic. The immediate-mode UI approach, which has many other benefits as well, works perfectly fine with manual memory management. >It's still C whatever libraries are used. It's still manual memory management with footguns. This is why they created "Vala". Objective-C is more like C than "glib" C is. As the suckless guys said: "glib - implements C++ STL on top of C (because C++ sucks so much, let's reinvent it!), adding lots of useless data types for "portability" and "readability" reasons. even worse, it is not possible to write robust applications using glib, since it aborts in out-of-memory situations. glib usage is required to write gtk+ and gnome applications, but is also used when common functionality is needed (e.g. hashlists, base64 decoder, etc). it is not suited at all for static linking due to its huge size and the authors explicitly state that "static linking is not supported"."
- mcguire 3y ago
  Immediate mode UI? Not having to allocate every where? Memory allocation that tells you when you run out of memory? Static linking? What systems are you thinking about?

memefrog 3y ago

>Of course you do, especially in applications where there is no benefit to be gained versus using a GC. I am afraid you misunderstood my comment. Of course C isn't good for writing code that calls 'malloc' millions of times per second. That's just bad code, which you can write in any language. You should not be dynamically allocating memory all over the place. If you have sane allocation strategies, then having to 'manually' manage them is completely fine. >This is why Java was such a huge success, despite offering very little else over C++ other than GC (I think OCaml is a much better example of a GC language). Java is the quintessential example of a language that was made popular through marketing and hype. Getting reasonable performance out of the JVM requires far greater expertise than doing the same in C. The JVM's GC is insanely complicated and has a million different knobs which can drastically affect performance. Or they can apparently do nothing. Until you turn other knobs... >Consider that an entire book has been written on such details as move semantics. There are no 'move semantics' in C. Yet another way in which it is superior to C++. C++, which is a horrible language designed by nerds who enjoy standardese more than they love their own children, has 'move semantics' bolted on with an arcane 'rvalue references' mechanism that gets more complicated in every version of the standard. >For most GUI apps, a GC or other automatic memory management has proved fine. Retained-mode UI is something that is only reasonable with automatic memory management. The way that lifetimes of objects works in those APIs really does require a garbage collector because it's all so dynamic. The immediate-mode UI approach, which has many other benefits as well, works perfectly fine with manual memory management. >It's still C whatever libraries are used. It's still manual memory management with footguns. This is why they created "Vala". Objective-C is more like C than "glib" C is. As the suckless guys said: "glib - implements C++ STL on top of C (because C++ sucks so much, let's reinvent it!), adding lots of useless data types for "portability" and "readability" reasons. even worse, it is not possible to write robust applications using glib, since it aborts in out-of-memory situations. glib usage is required to write gtk+ and gnome applications, but is also used when common functionality is needed (e.g. hashlists, base64 decoder, etc). it is not suited at all for static linking due to its huge size and the authors explicitly state that "static linking is not supported"."

mcguire 3y ago
Immediate mode UI? Not having to allocate every where? Memory allocation that tells you when you run out of memory? Static linking? What systems are you thinking about?