Hacker News Reader

Comment by mikaraento | Hacker News Reader

Perl, Visual Basic 6 and to some extent Python are examples of languages using the moral equivalent of ARC.

Python has been garbage collected since 2.0.

(Edit: Perl is garbage collected since version 6, and Visual Basic is garbage collected since version 7. I am not aware of any language besides Objective C moving in the opposite direction.)

CPython is actually hybrid reference counted and garbage collected. This is really an implementation detail for historical reasons, no other Python implementation I'm aware of uses reference counting.

There is no Visual Basic 7. Visual Basic .NET is garbage collected as it runs on the CLR, but is quite a different language to VB6.

One could argue that Perl 6 isn't what most people think of as "Perl", and probably should have been called something else.

Similarly, VB vs VB.NET.

C++ and Rust both provide reference counting pointer-like-things (shared_ptr and Rc respectively). C++ has been around for quite a while, of course, but Rust is pretty new, and deliberately eschewed garbage collection.

C++ RC requires good behavior from whole developers in the team and third party libraries.

It is hard to get right with existing code bases.

Additionally C++11 got a GC API, but requires explicit programmer control.

http://www.stroustrup.com/C++11FAQ.html#gc-abi

C++'s memory model is tainted by C's compatibility, as such it is quite limited in the GC algorithms that can be implemented.

In C++, reference counting is in a per object basis. There is no need of cooperation at all from other libraries or code bases.

Really?!?

How can you guarantee that the component library that your company just bought, available only in binary form isn't doing something like this?

    void cool_stuff_with_widget(const std::shared_ptr<UI> ptr)
    {
       UI* evilPtr = const_cast<UI*>(ptr->get());
       // now store evilPtr somewhere else and try to use it any time the library feels like it
    }

No one is going through disassembly to check such behaviors.

C++ RC is a very welcoming addition to the language, but it only works if everyone plays by the rules, 100% of the time.

It's not really an issue, if the library is buggy and leaks or keeps reference to things it's not supposed to, it will be the same whether it's RC or just plain memory management.

It's just better documented and easier to spot the bugs if you're doing RC.

It not about bugs, rather C++'s lack of support to enforce that RC is not misused and programmers cannot grab RC internals and corrupt the data structures.

C++ is a language that allows any kind of memory manipulation, if you really want (or need) to do it. So your example doesn't prove anything about the adequacy of shared_ptr in particular.

My point was that if a language does RC via library types that exposure the pointer that they own, there is no safety guarantee about memory safety.

It is impossible to prove that all memory access to a given address are done via the RC wrapper object, specially in the presence of third party libraries in binary form.

Sadly due to its C compatibility, there is no way around this in C++.

This is mostly a problem in large projects with various skill levels across team members, having high attrition levels.

As I mentioned above, the goal of C++ is not to provide memory safety guarantees. What it provides is a mechanism for RC implementation. You're free to use or misuse it if you want. It will work only for those objects that you think should be managed with RC, nothing more or less.

Reply on news.ycombinator.com