TempleOS features HolyC:
"In other operating systems, I hated learning one language for command line scripts and another for programming. With TempleOS, the command line feeds right into the HolyC compiler, line by line, and it places code into memory it MAlloc()s. The compiler is paused at the command line, waiting for input. Naturally, you #include a program to load it into memory and, usually, start it.
During the boot process, many files get compiled before you have access to the command line. (Don't worry, booting takes only a couple of seconds.) All the header declarations for the operating system are compiled and are available for use in your programs without needing to #include them. Everything is truly compiled to native x86_64 machine code, nothing is interpreted and there is no byte code."
Weak references don't primarily exist to deal with cycles, and cycles generally often involve necessarily strong references even in systems that support weak references. (That is, e.g., cycles where A needs to be reachable if B is reachable and vice versa, such that a weak reference that allowed B to be disposed while A was reachable or vice versa would not be acceptable. A system that can detect cyclic garbage will still be able to collect both A and B -- connected by strong references -- when neither can be reached from the rest of the program.)
The standard use case for weak references in Objective-C is a child-to-parent reference. The parent holds a strong reference to the child and children hold weak references to their parents, avoiding potential cycles.
In fact, part of good memory management in a reference counted system is that you should always have a hierarchy to your data structures so it never makes sense to have an actual strong reference loop.
So then you play pass-the-strong-reference in a destructor - i.e. if A goes out of scope the A->B ref is weakened and the B->A ref is strengthened, then vice versa if required.
We did this for DBIx::Class in perl, thereby keeping full liveness but still getting timely destruction for connection objects. It was a trifle insane to get right, but it works extremely well.
Sort of, CPython has both reference counting and a normal Garbage Collection. You can disable the latter and still avoid memory leaks as long as you don't have cycles
Interesting, that's potentially very good news! To be sure, could you try again with the latest code snippet? I forgot to remove the VM_PROT_EXECUTE flag for non-jailbroken devices.
Where does it crash? Try bumping the argument on line 21 – if you're unlucky library at index 1 contains mach_vm_read_overwrite and is suddenly no longer executable (since we change its second memory page from R-X to RW- due to stock kernels not allowing RWX pages).
That's CoreFoundation, not Foundation. CoreFoundation is plain C and relatively small in feature set. Foundation is Objective-C and much larger.
It's a lot easier to work with the Foundation Objective-C API. They both manipulate the same data structures (or nearly the same with zero-cost bridging) but Foundation is far less verbose and a little more dynamic (no need for manual buffer allocations and configuring callback structures).
