[pron]

`smart pointers + destructors => no memory leaks` does not entail `no memory leaks => smart pointers + destructors`.

"My solution offers X, therefore, if you want X, you should use my solution" is just a logical fallacy; the conclusion doesn't follow from the premise.

Also, I'm not so sure smart pointers and destructors actually prevent memory leaks. E.g. cycles. You can deal with cycles, but memory leaks due to them are not "prevented" just by the use of smart pointers and destructors.

Java does prevent leaks due to cycles, but it still doesn't prevent leaks due to "forgotten objects", so you get memory leaks in Java, too, even though it has fewer leaks than C++/Rust with GC pointers. So given that you can have fewer leaks than with smart pointers and still not have them completely gone, I wouldn't say that smart pointers "prevent" leaks. But yes, they're one of the ways to reduce them.

[CyberDildonics]

Also, I'm not so sure smart pointers and destructors actually prevent memory leaks

Well, they do, that's why people use them. I'm not sure why you would make the case against using another language that makes management manual.

Also reference counting cycles are only even possible if you use reference counting in the first place, which isn't necessary for single threaded scope based memory management.

Java does prevent leaks due to cycles

Fantastic but you said zig is safe than C++, what does java have to do with it?

[pron]

> Well, they do, that's why people use them.

They're one of the ways of reducing, not preventing memory leaks. And they're pretty ok at that, but I find other approaches to work better for me.

[CyberDildonics]

You can do whatever you want, but systemically it is a lot better than doing it manually and anyone experienced with modern C++ will tell you it essentially stops being a problem.

Also you say not preventing memory leaks but your only example is cycles, which is only happens with reference counting, which is only even necessary with multi-threading. Also it implies a data structure that contains a bunch of shared pointers internally that end up referencing each other, which implies a linked list or tree made out of shared pointers, which is essentially a wild mistake huge mistake in the first place. In practice this doesn't really happen.

[pron]

> You can do whatever you want, but systemically it is a lot better than doing it manually and anyone experienced with modern C++ will tell you it essentially stops being a problem.

Yeah, it's fine, but I think that systematically the Zig approach is a lot better for my needs and preferences.

> In practice this doesn't really happen.

I've only been programming low-level code for 25 years or so, including hard realtime safety-critical software, where a missed deadline or a stack overflow means dead people, so I have some grasp on what can really happen.

There's a clear tradeoff between forgetting to write some code and not noticing when code runs when you may not expect it to. Saying that one is universally better than the other is, at the very least, unsubstantiated.

[CyberDildonics]

You know when destructors run, they run at the end of a scope. It's very clear. Have you used modern C++?

[pron]

Destructors are not modern C++. When I learnt C++, circa 1993, we had destructors. Saying, you should just remember to always look up which destructors run sounds as convincing to me as how I must sound to you when I say you should just remember to put a defer statement when you need to free a resource.

In my low-level code I don't want any calls that I can't see as explicit calls in the code (BTW, it's not that I don't use destructors at all - I'm not a fanatic - it's that I try to avoid relying on RAII).