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 /g/ 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.
Shared pointers are an anti-pattern. If you're using them you probably fucked 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.
>>100166720>Shared pointers are an anti-patternhow is that?
>>100166524Did this guy ever finish that video game thing he was coding on Twitch?
>>100166862No, but he will fire you if you dare to use a virtual function.
>smart pointers>arena allocators>chained multiplexers>over-under arrays>method combinators
>>100166853I 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.
>>100166853basically, 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.
>>100166853They solve the most general case of lifetime/ownership management, very few things truly require that flexibility, to say nothing of the performance penalty.
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.
>>100167110huh?
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.
>>100167110C++'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.
>>100170341also 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.
>>100166524Smart 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.
>>100170502You can use std::unique_ptr with arena, not a problem.
>>100170563I'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.
>>100170634Arena 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?
>>100166853Programs 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.
>>100172389There's only one shared pointer and it manages the lifetime, how is this complicated?
>>100166524smart pointers are bad mmmkay?
>>100172418>how is this complicatedthis would be obvious if you ever worked on a non trivial codebaseit's because the intent (exclusive ownership) does not match the semantics (shared ownership)when intent and semantics do not match complexity is introducedin industry this is referred to as spaghetti code, or more commonly, shitcodeeach shitty design choice like this contributes to the overall complexity of the codebaseeventually you end up with an unreadable unmaintainable mess
>>100172903the 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.
>>100172921there's a big performance penalty here, you probably should use another pattern
>>100173044>integer increment/decrement is killing my performancewhat is that even supposed to mean?
>>100173072std::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.
>>100173126thank you chatgpt, now answer my question.
>>100166524oh look its the homosexual almond milk enjoyer and video game ma... no wait he made no games, just sucked blows rage boners
>>100173184he's currently crying about installing linux
>>100166524I love that wasian bara daddy like you wouldn't fucking believe
>>100175091>installing gaybian>expects shit to workOH NO NO NO NOcan't wait for him to realize that there are no closed source firmware blobs in the installer
>>100170650it'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.
>>100166524For 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.
>>100166720>anti-patternsI hate what this line of thinking has done to the coding world
>>100180163your post is an antipattern
>>100166524C++ 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 retarded coworkers not knowing how to manage their memory (or even being susceptible to human error).>picPov: you’re about to hear the dumbest yet most smug take that isn’t from that Blows guy
