Every once in a while online I'll come across people raging about smart pointers being a code smell in C++, usually while also going on about arena allocators, but not really describing why they are bad. What does IQfy think about them in the context of non-trivial C++ programs? The main cases I've heard against them are usage in dynamically linked libraries and issues across language boundaries.
 Thalidomide Vintage Ad Shirt $22.14 |
 UFOs Are A Psyop Shirt $21.68 |
Thalidomide Vintage Ad Shirt $22.14 |
Shared pointers are an anti-pattern. If you're using them you probably fricked up and need to re-think your design. Unique pointers are fine, but RAII ends up being a detriment when you care about when and how things are loaded and unloaded from memory.
>Shared pointers are an anti-pattern
how is that?
I mean, really shared STATE is an anti-pattern. There are places where sharing state is better / necessary, but a lot of times there are better ways of managing access to state.
basically, shared pointers - and pointers in general - are not a sufficient reference abstraction. the intertwines too many things into one fragile representation. for any object that will last longer than a frame, you're better off using a manually-wrought identity index along with an abstract creation and destruction API. do not use smart pointers for anything beyond temporary values. they're too complex, expensive, and fragile. And where you just a temp object, you can often just alloc it on the stack anyways.
They solve the most general case of lifetime/ownership management, very few things truly require that flexibility, to say nothing of the performance penalty.
Programs are much simpler when each object has one owner responsible for allocation and release. Shared pointers makes it difficult to reason about object lifetimes. In many cases where shared pointers are used, a non-owning raw pointer would have been a better choice.
There's only one shared pointer and it manages the lifetime, how is this complicated?
>how is this complicated
this would be obvious if you ever worked on a non trivial codebase
it's because the intent (exclusive ownership) does not match the semantics (shared ownership)
when intent and semantics do not match complexity is introduced
in industry this is referred to as spaghetti code, or more commonly, shitcode
each shitty design choice like this contributes to the overall complexity of the codebase
eventually you end up with an unreadable unmaintainable mess
the pointer owns data and it is released when it is released, you don't have to worry about any of this, not sure what's so hard to understand.
there's a big performance penalty here, you probably should use another pattern
>integer increment/decrement is killing my performance
what is that even supposed to mean?
std::shared_ptr has time overhead in constructor (to create the reference counter), in destructor (to decrement the reference counter and possibly destroy the object) and in assignment operator (to increment the reference counter). Due to thread-safety guarantees of std::shared_ptr, these increments/decrements are atomic, thus adding some more overhead.
thank you chatgpt, now answer my question.
>anti-patterns
I hate what this line of thinking has done to the coding world
your post is an antipattern
Did this guy ever finish that video game thing he was coding on Twitch?
No, but he will fire you if you dare to use a virtual function.
>smart pointers
>arena allocators
>chained multiplexers
>over-under arrays
>method combinators
Well if there is any way that you can substitute a vector of objects it's going to be faster. But if for some reason you have to use inheritance and polymorphism with an array of objects then unique_ptr is really what you need, you don't have much of a choice. You use the right tool for the job.
huh?
C++'s features allow you to sort polymorphic objects by type.
With a bit of extra work you can remove the need for sorting just by using multiple vectors for each object type and then implement iterator that iterates over all vectors, since iterator returns polymorphic type it will be transparent and performance will be as high as possible because your icache pressure cannot go lower than that.
also I forgot to add that every self respecting company and devs in them already should be doing this anyway, because OOP lovers already implement object factories and if you don't even create objects manually but use factories, what's stopping you from having a memory arena for each object hidden away? It's a lot of complexity but it pays off when your code runs x10 faster than Java.
Every time you hear complaints about something involving dynamic libraries and ABI, you should ignore everything they say because they're proprietards who write software that does not respect you as a human being.
Smart pointers are fine, what people really should take issue with is having too many small allocations. Arenas can help with this specific problem, but to get the most out of them you have to use trivial types so you don't need to run destructors.
You can use std::unique_ptr with arena, not a problem.
I'm not sure why you would want to do this since typically the arena is the owner of all objects allocated within the arena. I.e. it already takes on the role of unique_ptr but for many objects.
Arena is just reddit term for allocator, allocators always own the object no matter what and unique_ptr exists purely for semantics of "ownership" of a pointer before it is returned to its one true owner via unique_ptr's destructor, can you tell me what problem is there in using pointer returned by arena and having unique_ptr release it?
it's brain damage. the main point of an arena is that objects are managed in group instead of each object having it's own alloc/free pair. if you're allocating on an arena you can free multiple objects in a truly O(1) method, wrapping each allocations into a reddit pointer turns it into O(n) for no reason other than to make sepples tards feel at home.
smart pointers are bad mmmkay?
oh look its the homosexual almond milk enjoyer and video game ma... no wait he made no games, just sucked blows rage boners
he's currently crying about installing linux
>installing gaybian
>expects shit to work
OH NO NO NO NO
can't wait for him to realize that there are no closed source firmware blobs in the installer
I love that wasian bara daddy like you wouldn't fricking believe
For small projects I find building a simple garbage collector and using raw pointers to be much faster and easier in the long run than fiddling with smart pointers.
C++ autists just hate smart pointers because it’s an admission that they aren’t coding gods. Realistically the performance to safe code ratio is in favour to it, the performance isn’t the best but really good, and then you don’t have to worry about your moronic coworkers not knowing how to manage their memory (or even being susceptible to human error).
>pic
Pov: you’re about to hear the dumbest yet most smug take that isn’t from that Blows guy