[phaedrus]

I think "no bare pointers, ever" is overly dogmatic. Raw pointers still have a place, especially in game programming. The standard smart pointer types cover many common situations, but do not cover all situations (nor do I think were intended to).

[h0l0cube]

> The standard smart pointer types cover many common situations, but do not cover all situations (nor do I think were intended to).

They also add a level of indirection, which can manifest as cache misses. If you're iterating through large numbers of objects, memory locality can be a huge gain.

[gpderetta]

> They also add a level of indirection,

neither shared_ptr nor unique_ptr add any additional indirection compared to raw pointers.

Of course if you can you should use inline value types, but that's a different thing. The parent was talking about replacing raw pointers with smart pointers (personally I have no particular issue with non-owning raw pointers).

[uluyol]

This isn't a question of smart vs raw pointers, it's a question of pointer vs value. A std::vector<T> is considered good code in modern C++ and should often be preferred over a std::vector<std::unique_ptr<T>>.

[h0l0cube]

> it's a question of pointer vs value

Yeah, the indirection I was referring to generalises to this.

Edit:

You might be saying that STL data structures could have been used by the author to alleviate the memory locality issue, but as noted in another thread, it's common to use custom STL implementations or use entirely custom memory management in performance critical applications, to reduce on memory allocation frequency, memory usage and/or fragmentation. Or maybe the author is just more 133t than thou.

[jonnypotty]

Yeah but I read a thing somewhere that it's bad so I'm gonna tell everyone not to do it cos I'm clever.