4 ms·

I can agree with that when comparing with plain C code. But reference-counting in C++ and Objective-C leads to exactly the same problem as with managed code. Wh

I can agree with that when comparing with plain C code. But reference-counting in C++ and Objective-C leads to exactly the same problem as with managed code. What saves C is that reference-counting there leads to a lot of boilerplate and bugs. To avoid that one needs very clear ownership model.

Gibbon1 6y ago
I saw an essay by someone discussing going back to C and eschewing leet pointer and decentralized memory allocation for a system of centralized memory allocation and passing handles[1] instead of pointers. Which appeared to make most of the memory safety problems go away. [1] handles could be unboxed to expose a pointer. But unboxing had machinery to detect and trap on bad handles
- fpoling 6y ago
  That reminds me about early Fortran where everything was statically allocated including local variables and function return address. To simulate data structures one used arrays of various dimensions. Effectively array indexes where handles. This was not memory safe as there were no bounds checks. But add those when the compiler cannot eliminate them, and one gets fast and memory safe language. Edit: that static allocation was essentially a centralized store. Everything repeats itself.
- fetbaffe 6y ago
  You probably mean this essay https://floooh.github.io/2018/06/17/handles-vs-pointers.html https://floooh.github.io/2018/06/17/handles-vs-pointers.html
  - Gibbon1 6y ago
    That's the essay. I think it's interesting because he's mimicking the way I've been writing firmware. I've found most of the issues with memory safety disappear when you use static and centralized resource allocation, avoid monkeying with pointer arithmetic, and avoid making temporary copies of pointers 'for later'.
wott 6y ago
> I can agree with that when comparing with plain C code. But reference-counting in C++ and Objective-C leads to exactly the same problem as with managed code. What saves C is that reference-counting there leads to a lot of boilerplate and bugs. You've already been greyed out, but I agree 100% with what you said. That's my main beef with this kind of bi-weekly discussion where people always put C and C++ in the same bag. I rarely, if ever, make memory management errors in C. The model can't be more simple. If you don't explicitly allocate, you don't have to care about it (in the general case, it is on the stack and will disappear when exiting a function, anyway you also don't have to care about those implementation details, just do as if it disappeared with scope). If you allocate something (on the heap), then you free it later. Malloc(), free(), end of story. Okay, don't keep pointers to areas you will free or realloc, of course. Any function which returns pointers tomemory chunks are always to be treated as malloc'ed, those objects can never be on the stack and never have a fancy automatic management of any sort. Now almost each piece of code I wrote in Objective-C contained memory errors/leaks. Be cause 1. I didn't grasp the more complicated, less deterministic (so to speak) models and the jargon well 2. you (well, I) never know right away which type of management was used for the object that some function returned, you have to check the doc and pray it is clearly written 2.b you have to keep that information in mind until the moment when you'd like to release the said object in order to release what should be released and not release what is/will be/has been automatically released now/later/sooner/whoknows. And I don't even talk about the abomination that is Objective-C++, where I drowned in muddy waters.
Too 6y ago
Sure, you can shared_ptr everything and pretend your are writing C#, which as you say circles back into the same problems of spaghetti-ownership. The difference with c++ or rust is that you have options: plain &-reference for non persistent pointers, const &-references for read only non persistent pointers, copy for true copies, move/unique_ptr for transfer of ownership and shared_ptr for shared ownership. All this information is readily accessible to the caller through the function signature.

Gibbon1 6y ago

I saw an essay by someone discussing going back to C and eschewing leet pointer and decentralized memory allocation for a system of centralized memory allocation and passing handles[1] instead of pointers. Which appeared to make most of the memory safety problems go away. [1] handles could be unboxed to expose a pointer. But unboxing had machinery to detect and trap on bad handles

fpoling 6y ago
That reminds me about early Fortran where everything was statically allocated including local variables and function return address. To simulate data structures one used arrays of various dimensions. Effectively array indexes where handles. This was not memory safe as there were no bounds checks. But add those when the compiler cannot eliminate them, and one gets fast and memory safe language. Edit: that static allocation was essentially a centralized store. Everything repeats itself.
fetbaffe 6y ago
You probably mean this essay https://floooh.github.io/2018/06/17/handles-vs-pointers.html https://floooh.github.io/2018/06/17/handles-vs-pointers.html
- Gibbon1 6y ago
  That's the essay. I think it's interesting because he's mimicking the way I've been writing firmware. I've found most of the issues with memory safety disappear when you use static and centralized resource allocation, avoid monkeying with pointer arithmetic, and avoid making temporary copies of pointers 'for later'.

wott 6y ago

> I can agree with that when comparing with plain C code. But reference-counting in C++ and Objective-C leads to exactly the same problem as with managed code. What saves C is that reference-counting there leads to a lot of boilerplate and bugs. You've already been greyed out, but I agree 100% with what you said. That's my main beef with this kind of bi-weekly discussion where people always put C and C++ in the same bag. I rarely, if ever, make memory management errors in C. The model can't be more simple. If you don't explicitly allocate, you don't have to care about it (in the general case, it is on the stack and will disappear when exiting a function, anyway you also don't have to care about those implementation details, just do as if it disappeared with scope). If you allocate something (on the heap), then you free it later. Malloc(), free(), end of story. Okay, don't keep pointers to areas you will free or realloc, of course. Any function which returns pointers tomemory chunks are always to be treated as malloc'ed, those objects can never be on the stack and never have a fancy automatic management of any sort. Now almost each piece of code I wrote in Objective-C contained memory errors/leaks. Be cause 1. I didn't grasp the more complicated, less deterministic (so to speak) models and the jargon well 2. you (well, I) never know right away which type of management was used for the object that some function returned, you have to check the doc and pray it is clearly written 2.b you have to keep that information in mind until the moment when you'd like to release the said object in order to release what should be released and not release what is/will be/has been automatically released now/later/sooner/whoknows. And I don't even talk about the abomination that is Objective-C++, where I drowned in muddy waters.

Too 6y ago

Sure, you can shared_ptr everything and pretend your are writing C#, which as you say circles back into the same problems of spaghetti-ownership. The difference with c++ or rust is that you have options: plain &-reference for non persistent pointers, const &-references for read only non persistent pointers, copy for true copies, move/unique_ptr for transfer of ownership and shared_ptr for shared ownership. All this information is readily accessible to the caller through the function signature.