Roast me

[Albatross]

@highwayman
Sorry, the post was more aimed at @Niccolo. He actually did a pretty good job of explaining what I was talking about, better than I think I did before deleting my explanation.

The point you are making is that in std::shared_ptr there can be circular references which cause memory leaks (creating such a cycle means nothing ends up releasing).

For the students here, that means A refers to B, while B refers to A through smart pointers. When that can happen, user code might release both A and B, but since they "hold" references to each other, nothing will be deleted.

The std::shared_ptr relies upon std::weak_ptr to break this cyclic reference (Scott Meyers has other important recommendations), but that only occurs if the user happens to create the situation (for all languages). Fortunately it isn't all that typical. Unfortunately, naive developers hardly ever realize when it has happened.

Speaking of whom...

@Niccolo

Niccolo wrote:

std::is_fundamental<std::unique_ptr<int>>::value evaluates to true [in C++20]

That's news to me. I'm curious if you could show me where they added that, because a) it doesn't make sense that std::unique_ptr would be made fundamental in what's almost certainly a breaking change, and b) cppreference doesn't seem to indicate any changes to std::is_fundamental or std::unique_ptr that would make that result possible. I also can't reproduce your result using the latest release versions of g++ and clang++ using -std=c++2a, but... well, that's not all that meaningful at the moment.

Niccolo wrote:

C# and Java references are reference counted storage in C# and Java [...] C# and Java track this to break these cycles, but fundamentally the references ARE counted.

They really, really aren't. The reachability flag(s) for each object in a GC environment are not reference counts. There's no need to "break" cycles for the GC to free up unreachable objects that are in one. Maybe there are reference counting GC implementations for the JVM and/or CLR, but that's not what the modern defaults are.

EDIT 2:

Niccolo wrote:

The only way there can be any realization that an instance has been released is for the reference count to reach zero, which is where garbage collection finally comes into play for release of memory.

No, that's not the case. Take the most basic form of tracing garbage collection, naïve mark and sweep, as an example. It determines reachability by traversing the entire object graph from its root objects, and then freeing up any objects it did not traverse. This isn't optimal (read: it's REALLY bad), and there are far more optimized strategies for tracing garbage collection, but that's an example of one that doesn't rely on reference counts.

I'll agree with you that this debate is a bit out of scope, though, and that

The automatic release of resources (memory in this case) is key to modern C++

-Albatross

EDIT: Formatting, added more of the explanation quote.

[Niccolo]

With all the material we try to keep current with, someone writes a book or a blog with errors or partial information, and we have to re-check THEIR stuff along the way. Some of that impacted me on unique_ptr, where it remains a class in the standard.

[Albatross]

Fair enough. It happens to the best of us.

-Albatross

[highwayman]

Oh, awesome! :)