Or you know, maybe they have different view on these things. There are good programmers out there who don't use RAII or smart pointers and think that most of this modern stuff is just added cruft for little gain. Standard containers are nice but if performance is your problem you often need to re-implement them anyway and if it is not then maybe you could have done it in the higher level language in the first place.

Whatever float your boat (and your particular niche).

I don't see many valid reasons why you wouldn't want to use RAII patterns for any sort of resource management. I would go as far as saying that if you aren't doing so, you're probably doing it wrong. Having said that, I'd be genuinely interested to hear some resource managment sceanrios where you're better off not using RAII.

You can end up needing a lot of different RAII types, which can get a bit annoying. If you're trying to interface with anything that wasn't written with RAII in mind - e.g., any library that tries to be C-compatible - this is pretty much inevitable.

In theory, doing without is a huge problem, because you're running the risk of resource leaks and stale identifiers - but in practice, neither is a huge problem. Picking these sorts of bugs out has been pretty simple in every project I've worked on. I've had far more heartache from the bugs stemming from RAII-type mechanisms holding on to resources longer than they should, than I've had from fixing bugs caused by resource leaks or stale resource identifiers.

With std::unique_ptr (you can set the deleter) and ScopeGuard you don't need to create new types for every type of resource.

I respectfully disagree with leaks not being a problem.

RAII requires you to use exceptions or equally-ugly hacks to detect constructor failure. Some people (myself included) have a problem with that.

I've been programming in a variety of environments in exchange for money for well over a decade now, and I think I can safely say that people who learn one thing and stick to it are what is known as 'wrong.'

In the embedded world, this is the rule not the exception.

Because, in the embedded world, you better have a good fucking explanation of why you are using dynamically allocated memory.

Bring a formal proof that you won't go out of memory. Attach additional information on how you wrote an allocator that runs in constant time and does not risk taking it's sweet time to scan a huge area of memory. Sure, it's all O(n), but who cares if determining when you are going to hit the huge n case is equivalent to solving the halting problem.

Of course, at this point, the hassle simply means you don't use dynamic memory.

I agree with you regarding dynamic allocation. RAII is an orthogonal concept to dynamic allocation though, and it's actually beneficial because it forces you to declare all your resources up front or die.

Even in the case that you're using an STL container, it's probably a hash table or tree data structure, and you're probably populating it at initialization time with a defined quantity of items. In that case, even if it's doing heap allocation it's effectively static allocation.

In my experience in the embedded world it is at least recognized that RAII should be used. It is fast becoming the exception not to use RAII and now that smart pointers are in the standard, the same goes for them.

I'm suspicious of anyone who uses smart pointers without being able to discuss the trade-offs. Likewise the STL and Boost('s smart pointers and containers).

RAII on the other hand, totally.

I'm suspicious of anyone who isn't able to discuss the trade-offs of RAII.

We are all here to learn, not bicker. So, what are the tradeoffs?

I'm still learning c++11, but the framework I am using is not using smart pointers. It uses a single auto release pool with reference counting. Coming from Obj-C, I kinda like it but not sure what the downsides are so far into c++.

Jonathan Blow has a good point about smart pointers being a poor solution tacked on the language. As it wraps your class in another class and becomes kinda ugly.

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

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.