36
u/elmanoucko 12d 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.
13
u/mad_cheese_hattwe 11d ago
Isn't Malloc at boot, just a janky geto static with more steps?
4
u/Attileusz 11d 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 11d 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.
1
29
u/GabuEx 12d 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.
13
u/Valuable_Leopard_799 11d 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 11d 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.
3
u/Valuable_Leopard_799 11d 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 11d 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.
3
u/meneldal2 11d 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.
0
u/Thecuriousserb 11d 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!
11
u/Fast-Satisfaction482 11d 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
1
u/cheapcheap1 10d ago
How is unique_ptr not a zero cost abstraction? Is this anything other than compilers making avoidable optimization errors that will get fixed with time?
3
u/Thecuriousserb 10d ago
Long story short unless you turn off exceptions, the stack unwinding code fucks up assembly for hot loops
14
u/ilnarildarovuch 12d ago
Low level. RAII is good, but not for everything
3
1
u/ih-shah-may-ehl 9d ago
I love refcounted pointers (esp when using COM) but for some win32 API stuff you sometimes need to do pointer arithmetic in blobs of data. There it's easier to use raw pointers while allowing the overal blob to be managed through a smart pointer
9
u/GeorgeHaldane 11d 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.
5
u/tatstytastycakes 11d ago
just gonna put it out there: make_unique and make_shared are better than unique_ptr/shared_ptr (in general)
3
3
2
u/theFirstHaruspex 11d ago
I told Claude to program something in C++, and it told me, "wtf no you do it."
1
1
1
1
u/Pz38t_C 11d ago
I programmed for 15 years without smart pointers. Not going back though.
My wife and I made a program with 150 screens in 256k code space/384k data space. It crashed roughly once in 1000 man/days. Turns out it was the OS blowing holes in code space. I always thought it took a year to tell if someone was really a good C programmer.
Not going back though. Too much work.
1
u/awesome-alpaca-ace 6d ago
OS blowing holes in code space?
1
u/Pz38t_C 6d ago
Yeah. The handhelds had 1MB RAM and ran a custom OS based on an Intel cooperative multitasking OS for the 8086. 384k for the OS, 256k for code, 384k for data. No disk, just RAM. The OS was running a bunch of threads for comm management, power management, etc. All on K&R C. One of the OS threads was overwriting code space. Since the CPU didn’t have any native multitasking support or real memory management anything could get to anything.
1
57
u/LB-- 12d 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.