5 ms·

Interesting, but I still see `std::shared_ptr` and careful ownership as the C++ way. GC feels like adding another runtime dependency.

by d_finch 13d ago

whizzter 13d ago
V8 has a C++ GC because if you have shared C++ <-> JS object graphs you either need extra machinery to find cycles in individual code-paths (very error prone) or let C++ data live in JS objects anyhow (initial V8 interop way). Writing extensions for a GC'd language is painful or you let your interop code live in a GC world, I'm pretty sure you more or less always end up with the latter unless you add a way for the hosted language to support some way to control the host language (like JS code "understanding" std::shared_ptr's but that probably adds other securiy risks in terms of low-level exposure). It's an engineering tradeoff, if you're 100% C++ you don't need that.
stingraycharles 13d ago
Yeah but that doesn’t work when you’re using C++ to implement another language where people can do anything they want, including circular references.
bluGill 13d ago
The C++ way is unique_ptr, which covers about 80% of the needs and in cases where it works it is probably better than a GC. Shared_ptr covers about 15% of the cases, but that still leaves 5% where you need a full better GC. GC is another runtime dependency (or a really complex intrusive addition to your code), so if you don't absolutely need it I would avoid it in C++. A lot of C++ programs can avoid it with careful design. If you need a better GC anyway, in the real world modern GC algorithms are likely more performant for your use case than shared_ptr. Thus shared_ptr should be thought of as the C++ answer only because a "real" GC is hard to implement, but if you implement a real GC anywhere just use it to replace shared_ptr as well. (I lean to use unique_ptr even when GC is available, but I reserve the right to change my mind if someone presents evidence)

Interesting, but I still see `std::shared_ptr` and careful ownership as the C++ way. GC feels like adding another runtime dependency.

by d_finch 13d ago

Interesting, but I still see `std::shared_ptr` and careful ownership as the C++ way. GC feels like adding another runtime dependency.

whizzter 13d ago

V8 has a C++ GC because if you have shared C++ <-> JS object graphs you either need extra machinery to find cycles in individual code-paths (very error prone) or let C++ data live in JS objects anyhow (initial V8 interop way). Writing extensions for a GC'd language is painful or you let your interop code live in a GC world, I'm pretty sure you more or less always end up with the latter unless you add a way for the hosted language to support some way to control the host language (like JS code "understanding" std::shared_ptr's but that probably adds other securiy risks in terms of low-level exposure). It's an engineering tradeoff, if you're 100% C++ you don't need that.

stingraycharles 13d ago

Yeah but that doesn’t work when you’re using C++ to implement another language where people can do anything they want, including circular references.

bluGill 13d ago

The C++ way is unique_ptr, which covers about 80% of the needs and in cases where it works it is probably better than a GC. Shared_ptr covers about 15% of the cases, but that still leaves 5% where you need a full better GC. GC is another runtime dependency (or a really complex intrusive addition to your code), so if you don't absolutely need it I would avoid it in C++. A lot of C++ programs can avoid it with careful design. If you need a better GC anyway, in the real world modern GC algorithms are likely more performant for your use case than shared_ptr. Thus shared_ptr should be thought of as the C++ answer only because a "real" GC is hard to implement, but if you implement a real GC anywhere just use it to replace shared_ptr as well. (I lean to use unique_ptr even when GC is available, but I reserve the right to change my mind if someone presents evidence)