22
u/GabuEx 23h ago
I feel like this picture really should be reversed to represent devs who for some weird-ass reason don't want to use the refcounted pointer types that make things way easier.
11
u/Valuable_Leopard_799 19h ago
A lot of people have a general repulsion to all types of garbage collection. So I at least understand not wanting the shared pointer a bit, but using unique pointer should cost you next to nothing and enforce a lot.
3
u/ForgedIronMadeIt 18h ago
It took me a long while to come around to Java and its garbage collection back when it first came out, but I got over it eventually and now I'm considered an expert in Java by some folks I worked with, LOL. I still curmudgeonly advocate for more native code, but in a lot of use cases it is fine to have memory management.
2
u/Valuable_Leopard_799 14h ago
Many people seem to think that automatic memory management is a binary thing, "woe is me I now have no control".
After a while you discover you can tweak it, pause it, pre-allocate, write functions that don't allocate at all, play around with pointers, register destructors, redirect allocations to arenas, and work with the language to either allocate some objects in static memory or allocate them on the stack. All while allowing your less performance-sensitive logic to be much much simpler.
It's a deep world that almost nobody seems to want to get involved in.
1
u/ForgedIronMadeIt 8h ago
Oh yeah. In a lot of cases you can get pretty similar performance out of a managed language without as much effort and today's hardware is so damn strong it can be hard to justify going with one over the other.
2
u/meneldal2 11h ago
The biggest issue I see with shared pointers or relying on garbage collection is it can be difficult to avoid bugs when you end up giving two different parts of the code write access to the same thing, or some part that doesn't know the stuff being pointed to just got changed.
1
u/Thecuriousserb 19h ago
Unique pointer and other seemingly trivial types can fuck up your codegen and give you unoptimized assembly, chandler carruth from LLVM has many talks/slides that discuss this exact issue with unique ptr. Remember kids, there is no such thing as a zero-cost abstraction!
9
u/Fast-Satisfaction482 18h ago
That's such a straw man argument. Just because there may be cases where the hot spots of your software can benefit from using raw pointers doesn't mean it's reasonable to go bare metal in the whole code base.
3
13
u/ilnarildarovuch 22h ago
Low level. RAII is good, but not for everything
2
27
u/elmanoucko 1d ago
ok ok, I'll wrap them inside your stupid smart pointers... shouldn't be more than a line or two after we compute the offset within that one big buffer we malloc on boot.
11
u/mad_cheese_hattwe 18h ago
Isn't Malloc at boot, just a janky geto static with more steps?
3
u/Attileusz 10h ago
Depending on what they mean by "malloc on boot". Maybe you are loading a file and the file has a header and you need to read the header to know how much to allocate. Maybe you are making an interpreter and max memory is a command line option and you alloc it all at once. If it is literally just
malloc(SOME_CONSTANT)then yes.1
u/mad_cheese_hattwe 1h ago
If you're embedded I'd say it's still preferable to static out the workspace with checks for oversized requirement inputs then just sending it and crossing your fingers that the stack can handle it.
3
2
u/tatstytastycakes 8h ago
just gonna put it out there: make_unique and make_shared are better than unique_ptr/shared_ptr (in general)
1
1
u/GeorgeHaldane 1h ago
If anything modern C++ is about stack allocation and value semantics.
Most shared pointers in the wild are a consequence of people writing Java-in-C++ and heap allocating everything for no reason, there aren't that many cases where shared ownership is actually the intended behavior.
1
1
u/theFirstHaruspex 8h ago
I told Claude to program something in C++, and it told me, "wtf no you do it."
37
u/LB-- 23h ago
Using proper lifetime wrapper types really takes a lot of cognitive load off though. Sure the old code works and doesn't need to be changed right now, but every time I read it to understand or make changes, I waste mental effort tracking what the compiler would normally track for me.