4 ms·

I think the desire for smart pointers comes from having many allocations of various lifetimes. In my opinion smart pointers are a band-aid at too low a level to

by eska 2y ago

I think the desire for smart pointers comes from having many allocations of various lifetimes. In my opinion smart pointers are a band-aid at too low a level to solve this problem. In C++ this seems particularly attractive because it is very common to consider freeing memory and uninitializing memory to be the same thing and handle both with RAII. C becomes much more bearable and even ergonomic when introducing multiple allocators, especially an arena. This reduces the amount of separate allocations and lifetimes dramatically. A big failure of the C standard library in my opinion is that it does not offer such allocators and the APIs don’t make use of them (which is why strings are terrible in C).

indigoabstract 2y ago
The thing I like most about C is its simplicity, its minimalism and it being the interface of choice for other languages to talk to each other. You can completely understand the language since it's so small and doesn't change much and (if you avoid complicated pointer expressions) that also helps with reading the code. That said, I don't enjoy manual memory management, but I'd like a GC even less. Arena allocators are useful, but since reference counting is the preferred general solution in C++, could something similar also work in C without taking away that minimalism? I think it might, but that is just my opinion.
- andrekandre 2y ago
  > could something similar also work in C without taking away that minimalism? maybe automatic reference counting? [1] [1] https://en.wikipedia.org/wiki/Automatic_Reference_Counting https://en.wikipedia.org/wiki/Automatic_Reference_Counting
  - indigoabstract 2y ago
    Yeah, I remember about that. It works well for Objective-C. But since C doesn't have objects or messages, the best equivalent thing I can think of is for the C compiler to emit some type of signal on assignments and variables going out of scope. I don't claim to know what's the best solution for adding automatic memory management to C, but I'm pretty sure a good one exists. And it would need compiler support for it to work.
- MaxBarraclough 2y ago
  > You can completely understand the language since it's so small Not really. There are many dark corners to the language, and many opportunities for subtle misunderstandings. Plenty of C programmers don't even understand the basics of how types work in C, e.g. why you shouldn't use printf's %d format specifier with an argument of type size_t.
- eska 2y ago
  What I wrote about is not GC. The other comments about reference counting also unfortunately completely miss the point I made. The code stays simple as nothing is happening in the background like a GC or macro abuse. For example you clearly see where allocations can happen now in join_path(temp_arena, basedir, filepath). At the same time I‘m not calling free everywhere and can avoid a lot of the „goto cleanup“ dance or the gcc-specific extension. Frankly I feel like understanding this approach to memory management is the best way to snuff out C experts from juniors/wannabes.
  - indigoabstract 2y ago
    > What I wrote about is not GC. The other comments about reference counting also unfortunately completely miss the point I made. I know. I mentioned the GC because of another comment and because reference counting and GCs are the two usual general ways (that I know of) for automating memory management. That's what I had in mind. Unless I'm misunderstanding, arena allocators are most useful for categories of objects with similar lifetimes and are not in the fully automated category. Because if I have multiple arena allocators, I still have to manually assign an allocator when creating an object and also deal with the lifetimes of the allocators themselves. Easier than allocating/deallocating individual objects in main memory with malloc, true, and probably more efficient, but still not fully automated, so in my mind they have different use cases. But it's possible that I haven't really understood them, so if I'm mistaken about their use, please don't leave me in the dark. If that makes me look like a junior wannabe, I think I can take it. Even the people who know their stuff had some point when they didn't..
nektro 2y ago
this is something Zig does and its a great improvement indeed!

by eska 2y ago

indigoabstract 2y ago

The thing I like most about C is its simplicity, its minimalism and it being the interface of choice for other languages to talk to each other. You can completely understand the language since it's so small and doesn't change much and (if you avoid complicated pointer expressions) that also helps with reading the code. That said, I don't enjoy manual memory management, but I'd like a GC even less. Arena allocators are useful, but since reference counting is the preferred general solution in C++, could something similar also work in C without taking away that minimalism? I think it might, but that is just my opinion.

andrekandre 2y ago
> could something similar also work in C without taking away that minimalism? maybe automatic reference counting? [1] [1] https://en.wikipedia.org/wiki/Automatic_Reference_Counting https://en.wikipedia.org/wiki/Automatic_Reference_Counting
- indigoabstract 2y ago
  Yeah, I remember about that. It works well for Objective-C. But since C doesn't have objects or messages, the best equivalent thing I can think of is for the C compiler to emit some type of signal on assignments and variables going out of scope. I don't claim to know what's the best solution for adding automatic memory management to C, but I'm pretty sure a good one exists. And it would need compiler support for it to work.
MaxBarraclough 2y ago
> You can completely understand the language since it's so small Not really. There are many dark corners to the language, and many opportunities for subtle misunderstandings. Plenty of C programmers don't even understand the basics of how types work in C, e.g. why you shouldn't use printf's %d format specifier with an argument of type size_t.
eska 2y ago
What I wrote about is not GC. The other comments about reference counting also unfortunately completely miss the point I made. The code stays simple as nothing is happening in the background like a GC or macro abuse. For example you clearly see where allocations can happen now in join_path(temp_arena, basedir, filepath). At the same time I‘m not calling free everywhere and can avoid a lot of the „goto cleanup“ dance or the gcc-specific extension. Frankly I feel like understanding this approach to memory management is the best way to snuff out C experts from juniors/wannabes.
- indigoabstract 2y ago
  > What I wrote about is not GC. The other comments about reference counting also unfortunately completely miss the point I made. I know. I mentioned the GC because of another comment and because reference counting and GCs are the two usual general ways (that I know of) for automating memory management. That's what I had in mind. Unless I'm misunderstanding, arena allocators are most useful for categories of objects with similar lifetimes and are not in the fully automated category. Because if I have multiple arena allocators, I still have to manually assign an allocator when creating an object and also deal with the lifetimes of the allocators themselves. Easier than allocating/deallocating individual objects in main memory with malloc, true, and probably more efficient, but still not fully automated, so in my mind they have different use cases. But it's possible that I haven't really understood them, so if I'm mistaken about their use, please don't leave me in the dark. If that makes me look like a junior wannabe, I think I can take it. Even the people who know their stuff had some point when they didn't..

nektro 2y ago

this is something Zig does and its a great improvement indeed!