Very smart pointers
-
Reference counting enable automated releasing memory if no cycles. Users who use smartpointers in C++ or Swift language must be carefully and proper use weak pointers.
I think about extend smartpointers to manage cycles and start new language which can use this algorithm.
I don’t know if algorithm is correct for all possible graphs and graph forest (set) and all possible adding, removing edges in runtime.
Preview this algorithm
Block must have:- standard ref count (use count)
- weak count
- outgoing count
- link_number
In other hand pointers have standard with unlike fat(double) smartpointers in C++.
For further info, current version biggest method
https://github.com/parstools/smart/blob/86ca62e9bc6c4dc2e5a2de2408594bedb430140e/testCpp/dyncycles.cpp#L53
Is possible proof correctness this algorithm or find leaks?
-
Reference counting enable automated releasing memory if no cycles. Users who use smartpointers in C++ or Swift language must be carefully and proper use weak pointers.
I think about extend smartpointers to manage cycles and start new language which can use this algorithm.
I don’t know if algorithm is correct for all possible graphs and graph forest (set) and all possible adding, removing edges in runtime.
Preview this algorithm
Block must have:- standard ref count (use count)
- weak count
- outgoing count
- link_number
In other hand pointers have standard with unlike fat(double) smartpointers in C++.
For further info, current version biggest method
https://github.com/parstools/smart/blob/86ca62e9bc6c4dc2e5a2de2408594bedb430140e/testCpp/dyncycles.cpp#L53
Is possible proof correctness this algorithm or find leaks?
If you want to try this, I would suggest implementing it in C++ instead of designing a new language around it, which is a much bigger undertaking. My view is that I don't want to rely on a garbage collector. They tend to periodically monopolize the CPU time in a system with a lot of objects. But because memory leaks do occur, I favor object pools with a background garbage collector that recovers the memory for an object that was not properly deleted. You can read about it in this article[^].
Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing. -
Reference counting enable automated releasing memory if no cycles. Users who use smartpointers in C++ or Swift language must be carefully and proper use weak pointers.
I think about extend smartpointers to manage cycles and start new language which can use this algorithm.
I don’t know if algorithm is correct for all possible graphs and graph forest (set) and all possible adding, removing edges in runtime.
Preview this algorithm
Block must have:- standard ref count (use count)
- weak count
- outgoing count
- link_number
In other hand pointers have standard with unlike fat(double) smartpointers in C++.
For further info, current version biggest method
https://github.com/parstools/smart/blob/86ca62e9bc6c4dc2e5a2de2408594bedb430140e/testCpp/dyncycles.cpp#L53
Is possible proof correctness this algorithm or find leaks?
You can do a test with a circular reference. A => B => C => A So, if I have an initial pointer to A object, because of the construct, it is going to have a count of 2 (because of C). The need for the Garbage Collector is that if you remove the initial pointer to A (either in the Stack or Heap), A's reference count only decreases to 1, and because of C it never goes to 0. Is your code prepared to deal with that? The problem here with reference counting is that one above; it doesn't count how many "access paths" you have to an object, just the number of references you have to it.
-
You can do a test with a circular reference. A => B => C => A So, if I have an initial pointer to A object, because of the construct, it is going to have a count of 2 (because of C). The need for the Garbage Collector is that if you remove the initial pointer to A (either in the Stack or Heap), A's reference count only decreases to 1, and because of C it never goes to 0. Is your code prepared to deal with that? The problem here with reference counting is that one above; it doesn't count how many "access paths" you have to an object, just the number of references you have to it.
Yes,even more complicated but no proof that all.
