Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

So circular references when targetting C and C++ leak memory yes?


Yes, you can make a memory leak when targetting C, C++ and Swift. Same as when you code in C, C++ and Swift directly.


Right, but when you write C, C++ and Swift directly you can also make a program that _doesn't_ leak memory. The question posed was whether that's even possible in Ć?


Yes: Ć has "dynamic references" (`shared_ptr`) denoted as `T#`, "read-only references" (`const T*`) denoted as `T`, "read-write references" (`T*`) denoted as `T!` and "storage" (`T`) denoted as `T()`.

So you can (and probably should) do almost any memory management as you would in C++. Except I don't see any alternative for `weak_ptr` at the moment.


> So you can (and probably should) do almost any memory management as you would in C++

Well that's already out the door because I almost never use shared_ptr in C++ code. The C++ core guidelines recommend using unique_ptr whenever possible. If you're going to use shared_ptr literally everywhere you do dynamic allocation, you'd be better off using a tracing GC to avoid the extra pointer indirection (and cache miss) with every dereference.

It seems to me that Cito should have manual memory management because a manual memory language can be trivially mapped onto a GC language (just turn every free or delete to an nop), while the inverse problem is intractable in the general case.


Please show us real code where std::unique_ptr vs std::shared_ptr makes a considerable difference (with benchmarks). A pointer indirection causes a cache miss?

A shared_ptr can be optimized to unique_ptr if it's not copied.

Not sure what you mean by "a GC language". Most cito targets are garbage-collected.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: