Hacker News Reader

Comment by GFK_of_xmaspast | Hacker News Reader

If you're still learning c++, how do you know they're a poor solution?

> how do you know they're a poor solution

After using Java, Python, C# and other languages. Smart pointers aren't really that smart. I'm not saying garbage collection is the solution - but smart pointers aren't a silver bullet.

Garbage collection isn't a very good solution. They're often implemented poorly (the only good one being Go's) and they're slow. Garbage collection also necessitates a runtime environment to keep track of the data.

What is not smart about smart pointers? std::shared_pointer implements reference counting just as OP describes.

> Garbage collection isn't a very good solution.

I clearly didn't say it was.

> They're often implemented poorly (the only good one being Go's) and they're slow.

Do you have any evidence to support that? From my experiences and tests C# has been on par with C++ [1]. Of course it might be slightly slower but not enough for me to dismiss it. Java I think is a little bit slower - but my problem with Java is its memory requirements.

> Garbage collection also necessitates a runtime environment to keep track of the data.

Assuming they do this in a separate thread and you have an OS that schedules threads/processes in a sane way and the GC doesn't need to interact with the main thread - you should never notice a performance hit in your application.

> What is not smart about smart pointers?

They don't track the actual memory usage. John Carmack implemented his own version of memory management for both Doom 3 [2] and Doom 3 BFG [3] presumably so he could get debugging information that isn't available with the C++11 smart pointers. I've implemented something similar to Doom 3's heap where I track the line and file of where the heap memory was allocated.

The one thing I've noticed about developers today is that they have become lazy. Yeah - smart pointers will work correctly in simple cases and 90-99% of the time but it was written by humans so it may have bugs in it. Most C++ developers today refuse to run valgrind because they just assume their program doesn't leak memory when using shared_ptr/unique_ptr. I have personally found memory leaks in pretty popular open source projects. I would have told them about it - but I've found most C++ communities to not welcome new people and their ideas.

[1] http://www.codeproject.com/Articles/212856/Head-to-head-benc...

[2] https://github.com/TTimo/doom3.gpl/blob/8047099afdfc5c973faa...

[3] https://github.com/id-Software/DOOM-3-BFG/blob/9c37079c16015...

> John Carmack implemented his own version of memory management for both Doom 3 [2] and Doom 3 BFG [3] presumably so he could get debugging information that isn't available with the C++11 smart pointers.

Is this the same "Doom 3" that came out in 2004, a full seven-ish years before c++11.

I don't know how old that source is - but what does it matter? Any ameuter C++ developer can easily replicate unique_ptr and shared_ptr [1]. If he wanted to use those I'm sure he could have easily implemented it.

[1] https://isocpp.org/wiki/faq/freestore-mgmt#ref-count-simple

Doesn't go's GC work as well as it does because it's a 'stop the world' single-threaded implementation?

You're right, I'll rephrase: I agree with Blows point on it so far.

But I am pretty biased, I loved reference counting, and ARC just made it more awesome. I want ownership, I point strongly. I don't care about ownership, I'll have a weak ref and that's it.

You just described std::shared_ptr and std::weak_ptr. I recommend doing some more reading on the subject.

Thanks, I will! But it doesn't change what Blow said, and what I agreed with. It becomes ugly and takes more space than I need to. My class becomes weak_ptr and what I want to use becomes the template. You should also look into his talk about c++ and its weaknesses.

Reply on news.ycombinator.com