C enjoyer here, what's a smart pointer?
Update: Wow thanks everyone for the information! It seems like no matter how much I learn about programming, there is always something new to learn
Basically just a pointer with a reference counter. A little more overhead - though not as much as a garbage collector - once the counter hits zero, the memory is freed.
How are you meant to shoot yourself in the foot without shotgun shells? And what would C++ be without the right to shoot yourself in the foot, head, and both hands simultaneously?
Hey, a HEAT rocket launcher is technically a single use high powered drill. It really quickly drills a hole into the toughest materials. It also can kill you in 99% of the cases, but just pay attention.
A double edged sword is more efficient than single edged swords. If you hurt yourself with it it is just a skill issue.
but I mean you gotta throw in the the ASIO mining drill and then there's the coroutine electrical substation.
at least from there it's all easier and simpler error messages.
except if you use things just slightly... NO NOT LIKE THAT!
Yeah, there's also weak (non-owning) pointers that still allow the data to be freed in the background if all their actual owners release their shared_ptrs. And there's also atomic versions of all of those.
Generally, even if you hit the very unlikely case that something isn't in the C++ stdlib, it probably still can be found in a boost.cpp library.
Yes and no. The control block of shared ptrs is always atomic. I was talking about the wrapper std::atomic that also makes access to the data itself atomic.
https://en.cppreference.com/w/cpp/memory/shared_ptr/atomic2
Most of the time, absolutely!
But sometimes... you dump the whole box out looking for the right piece, organize the contents by size only to realize you should've sorted it by material, and get tetanus from all the rusty nails that you should have tossed away ages ago.
Then you just end up using duct tape because it never fails.
I remember once that even with rust I made a program so bad that it caused Windows to basically crash the file explorer and the task bar and everything wasn't working. couldn't even open task manager. restarted the computer everything was fine ran the program again everything was fine. idk
to be fair probably yeah. my program was using a good few unsafe stuff however I never had anything on the stack I don't believe.
edit: however I did have a Vec that I added probably close to 20m floats and another one that I added u64s into (both 20m)
For memory leaks, the stack usually isn't the problem, since the size of the stack is determined at compile time. Vecs are all dynamic allocation. 20m floats and 20m u64s is definitely not nothing, but probably not enough to grind your system to a halt... that is, unless you're inadvertently creating copies of those vecs
honestly the vecs could've been even larger and I was creating a thread for each of those 20m.
the program was attempting to brute force constants to use for fast inverse square root. however the fast inverse square was done by multiplying two fourth roots together (would look like constant - (float >> 2)) it actually gets within 2% accuracy with the optimized constants.
I found the actual constants by using equations instead (as you just want to solve for mew within the equation for the bits of the constant. the two mews that seemed to work well together was 0.07 and 0.045).
if you want to try and understand these two videos are where I got everything from:
https://youtu.be/p8u_k2LIZyo?si=gLUtDBC0rYDng3FK
https://youtu.be/tmb6bLbxd08?si=_vEKrOliYDL0FaNP
Rust doesn't technically care about memory leaks, they're not counted as unsafe, although they are typically very explicit like `mem::forget`or `Box::leak` (an interesting exception to explicit memory leaking is unwinding a panic in the middle of something using `MaybeUninit` because that doesn't run destructors, so things like standard library types often have guard structs to make sure you destruct what you can, because while it's not unsafe, it's just good manners)
And when you have a screwdriver that works totally fine for the job you need, someone has to come and snark that you're not using the newer super deluxe hyper driver
Doesn’t it have an overhead of checking it hasn’t been assigned twice. Or by overhead do you mean during destructor call it just has to free itself without checking if it still has references to it
It doesn't have a copy constructor, (only a move one) and in its destructor it frees the pointer. So the compiler enforces the assignment, and at run time it is (really close to) free. The only reason it's not completely free is that if the unique pointer is passed to a function and that function is not inlined, because of the abi the unique pointer is always passed on the stack whereas a raw pointer could be in a register. but in a modern machine where you have way more registers than are actually shown anyways this shouldn't make any measurable difference.
Shared and unique pointers are so good that the are better than anything in any other language IMO, at the engineering level.
The problem is the garbage syntax of a 50 year old language that's backwards compatible to day 1. Just a pain to work with mixed raw and smart pointers.
> better than anything in any other language
Take a look at Rust. Unique pointers are checked in compile time (and have no overhead, even no move constructor type of overhead).
And shared pointers are there (see `Arc`).
I assume most people don’t understand how Java’s various garbage collectors work, and the few that have looked into it will pick and choose which stats to point out (eg the length of each pause versus the total pause time while an app is running).
Basically, under the hood, a variable is just a group of bits. You can interpret these bits as a number in base 2, or you can interpret them as more complex data types, but ultimately, it’s all kind of the same to the computer. Now, because the computer doesn’t see a difference - and because memory is indexed - you can use the value stored in a variable to look up some other spot in memory. This is a pointer - just a variable that stores the address of some arbitrary block of memory.
Programmers dynamically allocate these arbitrary blocks of memory for various uses - for example, say you need a list of numbers, but you don’t know how many numbers there will be when you’re writing the program. The way you’d solve this is by allocating a chunk of memory during runtime, using it, then deallocating it when you’re done with it. This is the basis of manual memory management.
Now, the problem with this approach is that you have to be VERY careful about deallocation - free the memory too early, your program crashes because some part is trying to access forbidden data, free it too late or not at all, you get a memory leak, where your program becomes, at minimum, memory-inefficient. Because there’s such a delicate balance to be struck, this approach can be difficult to work with and hard to maintain - instead, most other languages just run a process called a garbage collector in a separate thread, and this garbage collector looks for allocated memory that isn’t being referenced anywhere, and automatically deallocates when it finds it. However, this does consume a bit more resources, so it can be a bit slow. It might work for a LOT of use cases, but when speed is of the essence - like with low-level systems work - you need another solution.
Enter smart pointers. There’s two types of smart pointers - unique pointers and shared pointers. Unique pointers work by a simple principle - a given block of data is allowed to have ONE pointer pointing at it. If said block is assigned to another pointer, the first pointer is invalidated, and once the pointer goes out of-scope without being invalidated, the memory is automatically freed. Shared pointers are a bit more flexible - they hold a counter, and every time a new shared pointer is created that references the block, that counter is incremented by one. Every time a pointer to that block goes out of scope, that reference counter is decremented by one, until it hits zero, and once it hits zero, it’s automatically freed.
TL;DR - bad cooking metaphor: manual memory management is like putting knives in the sink, but everyone is lazy and leaves them on the counter, garbage collection is like having someone yell at everyone in the kitchen to put the knives in the sink after they’re done with it, unique pointers are like only having one knife and the last person to use it puts it in the sink, and shared pointers are like counting the knives as the come out of the box and adjusting the count as they go into the sink.
There are two parts to this.
C++ has the hilariously badly named Resource Acquisition is Initialization (RAII). You have some piece of data with an attached destructor. While you have a reference, the data is always valid. Once the reference won't be used anymore it is automatically freed. Useful for manual memory management, but also other resources, connections, error handling, etc. But the automatic 'won't be used anymore' is very restrictive, you basically must hold the data in your hand and cannot store it.
Smart pointers let you be more flexible about what 'won't be used anymore' means. You may have a unique pointer, the value goes out of scope when the pointer does. You may have a shared pointer, when the pointer goes out of scope you decrease a counter and when that hits 0 the value goes out of scope.
It's similar to rust ownership and borrowing semantics, but less safe. E.g. pointing into existing data remains awkward because other code could move the data around without your knowledge.
I’ll try, although I won’t talk specifically about the C++ shared pointer as I don’t know exactly how it’s implemented, but about the general idea of reference counting, based on a language with reference counting I‘ve written myself.
In case you don’t know: a pointer is a memory address. In C/C++ and many other languages, you can get the address of a variable by using the & operator, and read the value stored at the address something is pointing to with the * operator. Example:
int a = 25;
int *b = &a; // type of b is int* or int pointer
int *c = b;
int d = *a; // d == 25
Maybe that explained it, maybe not, feel free to ask for a better explanation.
When you heap-allocate an object (meaning you create it somewhere in ram and you would have to manually delete it afterwards with normal pointers), it gets stored alongside with a reference counter which is just an integer starting at 0.
Now, every time you copy the smart pointer to the object, the reference counter of the object is incremented by 1. Every time a smart pointer to the object gets deleted, the reference counter is decremented by 1. Once it hits 0 again, the object is deleted.
You computer has a place where it can store and retrieve stuff quickly which is the RAM memory. In C++, when you assign the memory from your computer manually, and you unassign it manually. This is sounds simple, since you just need to remember the memory address. But your address for your the memory of your friend may be inside a pocket of a trouser, and the address of the trouser was inside my wallet and the address of the wallet was written on potato. You cooked the potato? Darn, now you can't find the wallet or the trousers or your friend! The are completely lost. Since computer programs execute the same code again and again, you may accumulate "lost memory" over time, which is locked waiting for you and can't be used by other programs. This is called a memory leak, and is the reason you need to close Chrome or some other programs when they slow down, and open them again to get your computer to come back to life (in the past, you had to reset your computer as a whole). A smart pointer keeps a list of in how many places the address of said pointer is kept. If no one has the adress anymore, it knows the pointer can't be used anymore, and deletes it, freeing the memory automatically. Of course this makes the program slower, but a working program > fast program.
What’s the advantage of using a garbage collector over shared pointers in languages? Do garbage collectors save memory? I can’t think of any other thing that might be the reason for people to use garbage collectors
Edit: I meant reference counting, not directly shared pointers
Not having to deal with memory management at all is a big reason. Garbage-collected languages - really not having to distinguish between heap and stack, just making variables as needed - are way faster to write in than systems languages, even if said systems languages have smart pointers
I should’ve written reference counting, not shared pointers. I wrote a language myself that uses reference counting. There’s 0 memory management for the user
Technically garbage collection can refer to any automatic memory management strategy, including reference counting. But you're probably asking about mark-and-sweep garbage collection, which is how Java and C# work, and what people usually mean by "garbage collection".
Mark-and-sweep has two advantages over reference counting: First, it easily handles cyclical references, which are a problem for reference counting. Second, it actually has *lower* overall overhead than reference counting most cases, because it doesn't have to constantly update references. Those updates can be especially expensive in multithreaded environments, because they must be done atomically.
The downside of mark-and-sweep is that it must periodically pause the entire application in order to execute. So while it is lower overhead overall, it periodically has relatively long periods where nothing else is being done. This has historically made it poor for real time applications like games.
Modern mark-and-sweep algorithms have sophisticated strategies for mitigating this problem, which is why you can see games made in Java (Minecraft) and C# (Unity) these days and probably never notice the GC pauses.
It is incorrect to say that using shared pointers has less overhead than a garbage collector. It depends on the scenario. For instance, allocations can be much faster when using a garbage collector, as you'd typically just have a bump allocator vs. individual allocations (of course, yes, one could also use a custom allocator). Additionally, using shared pointers will add overhead during use, whereas using managed objects directly will be faster. The overhead of the GC comes from collections, but you can avoid them if you don't allocate. That is, if you allocate some objects and then just do a whole bunch of work for however long you need, without further allocations, the GC will literally never run at all.
Not saying one is better than the other, just saying neither is definitely better or faster than the other either, it depends on what you're doing and how well written your code is 🙂
I’d suggest anyone reading the replies to the main comment immediately forget what they read and google “C++ smart pointers RAII” to start with, before reading some actual cpp resources to learn more about the additional mechanisms of the STD smart pointer types.
A wrapper type around a raw ptr which helps with memory safety. There is a reference counted ptr which is only freed after all references are gone. There is a unique ptr which cannot be shared etc etc
In essence: reference counting.
The goal is generally to make heap allocations safer, resulting in a slight performance overhead for the general safety of not shooting your leg off.
More or less (very simplified):
```
struct rptr { size_t* counter; void* data};
struct rptr = create_rptr_xyz(...); // counter = 1; allocate data
...
struct rptr2 = borrow(rptr); // counter = 2
...
// on scope leave
release(rptr2); // counter = 1
...
// yet again, on scope leave
release(rptr); // counter = 0; call free for data```
But using RAII for that automagically and special derivatives, for weak references and unique (as in: one owner) allocations.
It can be considered to be best practice nowadays for non performance critical code.
You're correct (ownership is what matters and the existence of non-owning references makes it different from reference countings), but considering the amount of false C++ knowledge here, I will pass.
Smart pointers are, in it's very most basic formulation, reference counting.
There is no magic involved or a random ghost of a gc appearing in cpp, it is just reference counting when stripping it down to its essential parts
There are roughly two definitions. An owning pointer type with kind of RAII semantics (C++ example: `std::unique_ptr`) or any type that generalizes or narrows the concept of a raw pointer.
Commenting on other replies, reference counters can be smart pointers, like `std::shared_ptr` in C++, but they can very well not be, being instead a whole separate automatic memory management model of a language, separate from tracing (tracing is usually called garbage collection).
A smart ass word for a struct that wraps a raw pointer and when the struct is removed from stack the raw pointer memory is cleared. It comes in few flawours like
shared_ptr which is the most primitive version of GC - you count how many shared pointers to object exist if number gets to 0 you remove the memory,
unique_ptr - heap object is bound to stack object, when stack object die heap object also die,
there is also
weak_ptr - a view to value of shared_ptr ( not counted as reference ) and
observer_ptr - a wrapper around normal pointer with implicit cast from other smart pointers
There are a lot of resources in programming where you need to do something to acquire them, and then later something to release them. Pointers have new/delete, files have open/close, mutexes have lock/unlock, and so on.
No one forgets to acquire a resource, because you can't do anything without that, but it's easy to forget to release it, which causes memory leaks, deadlocks, locked files... It would be really nice if the compiler could detect that and ensure all resources are released once you don't need them.
C++'s solution is that you can tie custom behaviour to both constructing an instance of a type, but also to dropping that instance when it goes out of scope. As soon as no one is keeping track of a file handle, there's no way for the program to access that file, so you can safely tell the OS to close the file once the handle variable goes out of scope.
Smart pointers are just the "handle" types for memory allocation. You've got unique_ptr for when you only need one "owner" of the memory, and shared_ptr for when you need multiple "owners". As part of creating/setting the smart pointer, you call new (ideally implicitly), and then when unique_ptr goes out of scope it calls delete. shared_ptr keeps a reference counter, and the last shared_ptr to drop from scope calls delete.
Some C enjoyers dislike automatic resource management like this, because it's one of the several ways that C++ "hides" operations that might have a performance impact (same as operator overloading), but I like it because it entirely removes whole classes of bugs that plague software.
It's a way to use pointers such that you don't have any floating unused heap space. They're honestly relatively simple to implement if you spend less than an hour trying to implement it.
C++'s smart pointers encapsulate raw pointers into different owner models: unique and shared.
Unique is 'unique' to the scope it was constructed in (unless you 'move' the resource) and will destroy the pointer once its lifetime is over.
So it's meant that only one pointer can point to the resource.
Shared pointers can point to the same resource across different scopes; the resource will be destroyed and freed after every shared pointer goes out of scope, I.e the reference counter equals 0.
So basically their point is to prevent memory leaks.
No macros are involved in smart pointers. And more specifically they can completely eliminate memory leaks, double frees, dangling pointers, etc where used.
I just added that because you can still go out of your way to break memory safety. For example.
auto ptr = std::make_unique(10);
delete ptr.get();
But it's really not that hard to properly use smart pointers and maintain memory safety.
In reality both sp are good until the first change request or new feature to software. Later it is heavy weight which significantly slows down development and natural software evolution. It forces you to create tens or hundreds of unnecessary code entities just to handle language features, and has no extra business value.... And the funny thing is - the memory is still leaking, all the time...
For an assignment in C we needed to make sure to free all memory we allocated before shutting down, so I made a wrapper for malloc that added the pointer to a linked list, then at the end I just ran free on every pointer and link in the chain.
Dirty as hell but hey, it worked and I never had a double free or a leak
"I even combined third party shared pointers with a wrapper shared pointer that managed the reference counters on its own. Oh, I also had to use multiple inheritance due to the design of those libs."
The C++ they taught us in college in 2001-2003 looked nothing like what I see posted here now. I dont remember smart pointers, only regular and then the double splat, etc. Moved onto higher level stuff after college so I forgot nearly everything I knew.
Pretty dumb meme tbh. Smart Pointers were introduced in what, c++ 11? Ever worked with hardware specific compilers from the early days? Sometimes companies are locked to those things for decades.
Terrible take of someone that doesn't know unique pointer. C++ without them is just C with classes. Heap is slow and vulnerable. Smart pointers are how you do memory management in C++. That and using the stack as much as possible.
People these days have language with 10000 different syntaxes but think that:
class.method(
and
method(&class,
are two completely different things.
Not only that, but if you really want your class.method syntax, you can actually do it using function pointers.
At some point people need to understand that OOP (Object Oriented Programming) is a conceptual approach and is not tied to a language. And that OOL (Object Oriented Languages) are designed to force you to use OOP.
Yes some languages make it harder to apply the OOP paradigm. C is not one of them. C just allows you to do something else if you desire.
Yeah, that function pointer syntax is nice, but it’s +sizeof(void*) bytes for every function you add, plus an indirection whenever you call it (or does that get optimized if you don’t change it?)
> plus an indirection whenever you call it (or does that get optimized if you don’t change it?)
If the compiler can determine which implementation will be called, it will devirtualize the call, meaning there is no indirection. There are a few ways the compiler could determine this:
* The class is `final`, which prevents subclassing.
* The method on the class is `final`, which prevents overriding the method..
* The class only exists in one translation unit (anonymous namespace) and there are no subclasses in that translation unit.
* The pointer refers to an object that was constructed in the same function (accounting for inlining) and could not have been reassigned.
I’m curious, do they ever make their own data structures which they need to have highly optimized? (For example, tree-like structures such as Suffix Trees.) I feel like using smart pointers are great for most things, but I still prefer to use raw pointers for something of this nature, personally.
Unique pointers have no overhead. In situations where you want the tree to have shared ownership, rather than copy shared pointer overhead is minimal. When highly optimized low latency code is necessary, which is rare, then yeah maybe something besides shared pointer is necessary. But I expect most people writing their optimized data structures using raw pointers for speed are doing some premature optimization. Start with smart pointers always, if through profiling one finds the overhead to be significant, then maybe consider a different solution.
That's fair, but when it comes to something like competitive programming, raw pointers *can* be desirable (for performance, size constraints, and how fast you can type it up compared to the smart pointer counterparts). Ultimately, it comes down to use cases. (For example, the coding style of competitive programming tends to differ quite a bit from "good"/readable/reusable code.)
Generally, I try to avoid pointers entirely (raw or smart), where possible (in favor of references); of course, this isn't always possible.
I’ve never done competitive programming so I’ll take your word on that! It makes sense though.
Avoiding pointers is definitely best, and in most cases are likely unnecessary since we should all be using battle tested libraries as much as possible that do the pointer work for us.
For those of us that do lower level or library work(for certain domains that is), then pointers will likely be plentiful.
I’m currently working on an abstraction layer over SYCL that distributes problems over multiple devices, but from a user perspective is treated as a single “device” to simplify distributed parallel programming and my oh my, shared pointers everywhere. Fortunately the added latency and memory footprint introduced by smart pointers is but a mere blip for HPC workloads haha.
I mean as much as people rag on C++, it’s my language of choice and I’d be bummed to use anything else. Don’t get me wrong, the language is massive and having learning what not to use because most of the features are antiquated af is definitely a huge con for the language. But if limited to modern features, especially C++17 and up, the language is quite nice. Understanding exactly what is happening on a machine level with your code, more or less, rather than relying on a runtime to do garbage collection makes, while still having things be cleaned up “automatically” is my favorite part about it.
ETA: I fucking hate the build ecosystem, however. Want to use multiple compilers? Good fucking luck. Got to use external project add. But now, suddenly CLion has no code insight of the external project. So, some compilation database cmake flags and a custom command using jq to merge the databases later, I now have code insights once again. A fucking mess. Just spent my entire work day figuring this out hence the sudden shift in tone lol
I'm not a C/C++ programmer, but shouldn't it be the other way around?
If you can write good code with "raw" pointers then then that makes you better than someone relying on a "smart" crutch. Doesn't it?
tbh so far using smart pointers caused me more memory leaks than not using them.
people like to just throw them around without care, but they dont always free themselves. i had a very annoying days worth of debugging when a new senior arrived, got angry at us not using smart pointers, rewrote our code to use them. he missed the fact that there were some very cleverly disguised directed loops of pointers in the data structure. he just removed all destruction related to pointers, so the loops couldnt resolve smartly, as they were locking each others reference numbers. ofc the solution is easy, just need to use at least one weak pointer in every cycle, but i basically had to rewrite the parallelised constructor to explicitly detect loops, yada yada yada
and this wasnt the only case when i got punished for using them when working with complex custom data structures. if id give up an idea after the first mental breakdown, i wouldnt code in cpp, lol
to be clear: i can see the point of them, but thinking strictly about destruction seems a safer approach to me so far. i may be wrong, but i have the same doubt about using them as about using rust:
>!^("isnt this just for people who are a bit shit at cpp?")!<
i mean yeah, but the tradeoff seems to turn negative at a non-zero shittiness. these restrictive crutches seem to be optimised for a subpassable ammount of shittiness
edit: i.e. "either you die a rust user or cpp long enough to git gud"
> but thinking strictly about destruction seems a safer approach to me so far
No, the correct way is to think about ownership. If you're coworker came in and just replaced everything with `std::shared_ptr`, then they weren't thinking about ownership at all.
Sounds like a skill issue tbh. Shared pointers are bad most of the time, not because they don't work because but needing them is code smell and more often than not just unnecessary
Come on, most developers do not really care about memory leaks. Only if they run into memory overflows. Also you can run in any language into memory leaks. A ref counter won't save you.
Buffer overflows most likely happen because you are using the wrong functions (not reading documentation) or make inproper allocations. Can both still happen with smart pointers.
i would rewrite the whole story (bad ending also):
~ im a good c++ programmer
- be honest
~ yeah im being honest
- ever used smart pointers?
~ yeah; for example QScopedPointer, QSharedPointer with several macros prevent overflow or all sorta errors
- ……
- okay ur recruited go develop the animator for Disney Co Ltd
~ okay
Three months later
<… TechSolutions-Animator has stopped working. Reason: exit code no. 11 (SIGSEGV) Call stack QtCore.dylib
…………>
- u really know smart pointers?!!!!!
~ sir, no… I mean yeah, of course i do yeah, but you know, uh, in this case…
- shut up. ur fired.
~ f**k. but fair enough.
Programming isn't about what über special functions and quirks of your language you use but about getting the job done. Change my mind while I use Micropython for Microcontrollers because C is annoying 
You shouldn't need smart pointers if you are handling things properly.
When something is to be free'd, null all of your pointers to it.
It's not hard.
They do occasionally make lazy access easier though, so have at it i guess.
Way better to learn without those modern features first, than with, to truly understand why modern features are useful. Especially when you consider that you’d be absolutely fucked if you had to jump in to a code base that does not use modern features, and you’ve only learned to rely on them.
Man, imagine the first carpenter who came across a chisel. "Fuck, this would be so handy, shame that nobody back home uses this, no reason to learn this amazing tool" - you should NEVER stop learning and mastering all aspects of the language you're using even if you dont get to use it on whatever you're working on now.
No, C++ should be learned with those features so you understand them. This is why people struggle to use C++, because they are only taught C with classes and the second they need to use actual C++ features they want to do it the C way and fail
A)There’s a reason I used the word “first”.
B) u/belabacsijolvan gave a pretty good example of smart pointers being used, and the use of them fucking everything up.
C) As I mentioned above, good luck to those who’ve only learned to use modern features, when they don’t have the option of using them.
I'm not misinterpreting what you are saying. What I am saying is that C++ is a higher level than C language compatible with C.
I understand learning C and the value of learning to create classes around it. But teaching C++ as if It was C leads to bad C++ practices
I agree with most of what you are saying, except I believe that having an understanding of what is being taken care of for you with smart pointers, will lead to a greater understanding of when to use them and not. if, by chance, the use of them is causing a bug, such as in the example provided by u/belabacsijolvan above, then it’s going to be much easier to debug and fix if you already understand how to do it the hard way. In no way am I saying to not learn the very useful features of modern c++
I do think a deeper understanding is better. I haven't written Assembly in my life, but I like reading it and understanding it, cause it is what the machine uses. I like knowing and understanding C because it's simple and powerful. And I like using C++ because it makes it safer to use an "unsafe" language. But I learned all these separately, I wasn't taught C with classes because I already was taught C, precisely to avoid writing dangerously inadequate C++ code
I did the same in terms of C first and then C++, but was forced to use raw pointers all through school, with the exception of upper year networking courses. It wasn’t c with classes, as smart pointers were the only modern c++ feature we were not allowed to use. Smart pointers are a god send, but not being allowed to use them was beneficial in the long run, despite the many lost hours of sleep it caused.
I never get to use pointers in C++. However, I use pointers a lot when programming in C, mainly because I want to use dynamically allocated strings (rather than static ones).
Genuine question, as someone who learned C++ using kind of outdated information (University...), which smart pointers should I use when programming in C++? Which ones are the most useful?
Smart pointers is for kids.
Is it so hard to delete things you allocate? Do you have memory of golden fish and forget about things you create?
Do you know how class destructor works?
I'll be honest - fuck smart pointers.
Raw pointers are fine if the object's lifetime is well controlled. And also, knowing smart pointers exist isn't gonna save you on older projects that aren't using newer C++ versions, and it certainly won't help you when you somehow end up with a bad ref count.
std::shared_ptr is awesome
The best parts of C++ are the stuff that isn't C with classes imo. Screw classes. Give me a struct with almost everything public and const
Give it to us raw and wriggling. -Gollum
raw and dangling?
And girthy
Raw and stale
C enjoyer here, what's a smart pointer? Update: Wow thanks everyone for the information! It seems like no matter how much I learn about programming, there is always something new to learn
Basically just a pointer with a reference counter. A little more overhead - though not as much as a garbage collector - once the counter hits zero, the memory is freed.
That's only shared pointer. Unique pointer is another smart pointer that allows only one reference. It has no overhead.
C++ feels like that box of screws, nuts, and bolts that has exactly what you need somewhere inside of it
Screws, nuts, bolts, hand grenades, land mines, knives, double edged swords. Absolutely *all* the tools
Don't forget the shotgun and shells! Get two shells, load them into the gun, and aim vertically downwards.
At the same time, it has a Stuka and a modern F16 and we don't tell beginners the difference between them.
eclipse9
You can also use a hammer and hit the shells
How are you meant to shoot yourself in the foot without shotgun shells? And what would C++ be without the right to shoot yourself in the foot, head, and both hands simultaneously?
I think knives and doubled edged swords are what we accidentally create using those said tools...
yeah we use the swiss multitool(boost) to make a knive that cuts gras, but only gras!
I like the flame thrower myself.
Hey, a HEAT rocket launcher is technically a single use high powered drill. It really quickly drills a hole into the toughest materials. It also can kill you in 99% of the cases, but just pay attention. A double edged sword is more efficient than single edged swords. If you hurt yourself with it it is just a skill issue.
but I mean you gotta throw in the the ASIO mining drill and then there's the coroutine electrical substation. at least from there it's all easier and simpler error messages. except if you use things just slightly... NO NOT LIKE THAT!
Yeah, there's also weak (non-owning) pointers that still allow the data to be freed in the background if all their actual owners release their shared_ptrs. And there's also atomic versions of all of those. Generally, even if you hit the very unlikely case that something isn't in the C++ stdlib, it probably still can be found in a boost.cpp library.
The C++ shared pointer is atomic. There is no non atomic one in stdlib.
Yes and no. The control block of shared ptrs is always atomic. I was talking about the wrapper std::atomic that also makes access to the data itself atomic.
https://en.cppreference.com/w/cpp/memory/shared_ptr/atomic2
Most of the time, absolutely! But sometimes... you dump the whole box out looking for the right piece, organize the contents by size only to realize you should've sorted it by material, and get tetanus from all the rusty nails that you should have tossed away ages ago. Then you just end up using duct tape because it never fails.
C is like that but you only get a hammer, a nail and a bazooka.
I remember once that even with rust I made a program so bad that it caused Windows to basically crash the file explorer and the task bar and everything wasn't working. couldn't even open task manager. restarted the computer everything was fine ran the program again everything was fine. idk
Sounds like a memory leak to me
to be fair probably yeah. my program was using a good few unsafe stuff however I never had anything on the stack I don't believe. edit: however I did have a Vec that I added probably close to 20m floats and another one that I added u64s into (both 20m)
For memory leaks, the stack usually isn't the problem, since the size of the stack is determined at compile time. Vecs are all dynamic allocation. 20m floats and 20m u64s is definitely not nothing, but probably not enough to grind your system to a halt... that is, unless you're inadvertently creating copies of those vecs
honestly the vecs could've been even larger and I was creating a thread for each of those 20m. the program was attempting to brute force constants to use for fast inverse square root. however the fast inverse square was done by multiplying two fourth roots together (would look like constant - (float >> 2)) it actually gets within 2% accuracy with the optimized constants. I found the actual constants by using equations instead (as you just want to solve for mew within the equation for the bits of the constant. the two mews that seemed to work well together was 0.07 and 0.045). if you want to try and understand these two videos are where I got everything from: https://youtu.be/p8u_k2LIZyo?si=gLUtDBC0rYDng3FK https://youtu.be/tmb6bLbxd08?si=_vEKrOliYDL0FaNP
20m threads is _definitely_ gonna cause some issues
In Rust? Heresy!
Rust doesn't technically care about memory leaks, they're not counted as unsafe, although they are typically very explicit like `mem::forget`or `Box::leak` (an interesting exception to explicit memory leaking is unwinding a panic in the middle of something using `MaybeUninit` because that doesn't run destructors, so things like standard library types often have guard structs to make sure you destruct what you can, because while it's not unsafe, it's just good manners)
No language can stop you from allocating more memory than you can deallocate, unfortunately
There are safe languages that prevent leaks, like Wuffs
It really does make you _think_ that. Later it has you going, "you know, I actually LIKE shooting myself in the foot. This is nice!"
And when you have a screwdriver that works totally fine for the job you need, someone has to come and snark that you're not using the newer super deluxe hyper driver
Sounds my kind of language! Gonna give it a go on summer break
Let me boost that for you
Doesn’t it have an overhead of checking it hasn’t been assigned twice. Or by overhead do you mean during destructor call it just has to free itself without checking if it still has references to it
It doesn't have a copy constructor, (only a move one) and in its destructor it frees the pointer. So the compiler enforces the assignment, and at run time it is (really close to) free. The only reason it's not completely free is that if the unique pointer is passed to a function and that function is not inlined, because of the abi the unique pointer is always passed on the stack whereas a raw pointer could be in a register. but in a modern machine where you have way more registers than are actually shown anyways this shouldn't make any measurable difference.
I think it's done at compile time, like the borrow checker from rust
Shared and unique pointers are so good that the are better than anything in any other language IMO, at the engineering level. The problem is the garbage syntax of a 50 year old language that's backwards compatible to day 1. Just a pain to work with mixed raw and smart pointers.
> better than anything in any other language Take a look at Rust. Unique pointers are checked in compile time (and have no overhead, even no move constructor type of overhead). And shared pointers are there (see `Arc`).
Not to be pedantic but isn't reference counting a method of garbage collection? Do you mean not as much overhead as tracing garbage collection?
I assume most people don’t understand how Java’s various garbage collectors work, and the few that have looked into it will pick and choose which stats to point out (eg the length of each pause versus the total pause time while an app is running).
Or implementation overhead I have implemented my own reference counting. I could not figure out how to implement my own garbage collection
Can you ELI5 this for a non-programmer?
Basically, under the hood, a variable is just a group of bits. You can interpret these bits as a number in base 2, or you can interpret them as more complex data types, but ultimately, it’s all kind of the same to the computer. Now, because the computer doesn’t see a difference - and because memory is indexed - you can use the value stored in a variable to look up some other spot in memory. This is a pointer - just a variable that stores the address of some arbitrary block of memory. Programmers dynamically allocate these arbitrary blocks of memory for various uses - for example, say you need a list of numbers, but you don’t know how many numbers there will be when you’re writing the program. The way you’d solve this is by allocating a chunk of memory during runtime, using it, then deallocating it when you’re done with it. This is the basis of manual memory management. Now, the problem with this approach is that you have to be VERY careful about deallocation - free the memory too early, your program crashes because some part is trying to access forbidden data, free it too late or not at all, you get a memory leak, where your program becomes, at minimum, memory-inefficient. Because there’s such a delicate balance to be struck, this approach can be difficult to work with and hard to maintain - instead, most other languages just run a process called a garbage collector in a separate thread, and this garbage collector looks for allocated memory that isn’t being referenced anywhere, and automatically deallocates when it finds it. However, this does consume a bit more resources, so it can be a bit slow. It might work for a LOT of use cases, but when speed is of the essence - like with low-level systems work - you need another solution. Enter smart pointers. There’s two types of smart pointers - unique pointers and shared pointers. Unique pointers work by a simple principle - a given block of data is allowed to have ONE pointer pointing at it. If said block is assigned to another pointer, the first pointer is invalidated, and once the pointer goes out of-scope without being invalidated, the memory is automatically freed. Shared pointers are a bit more flexible - they hold a counter, and every time a new shared pointer is created that references the block, that counter is incremented by one. Every time a pointer to that block goes out of scope, that reference counter is decremented by one, until it hits zero, and once it hits zero, it’s automatically freed. TL;DR - bad cooking metaphor: manual memory management is like putting knives in the sink, but everyone is lazy and leaves them on the counter, garbage collection is like having someone yell at everyone in the kitchen to put the knives in the sink after they’re done with it, unique pointers are like only having one knife and the last person to use it puts it in the sink, and shared pointers are like counting the knives as the come out of the box and adjusting the count as they go into the sink.
There are two parts to this. C++ has the hilariously badly named Resource Acquisition is Initialization (RAII). You have some piece of data with an attached destructor. While you have a reference, the data is always valid. Once the reference won't be used anymore it is automatically freed. Useful for manual memory management, but also other resources, connections, error handling, etc. But the automatic 'won't be used anymore' is very restrictive, you basically must hold the data in your hand and cannot store it. Smart pointers let you be more flexible about what 'won't be used anymore' means. You may have a unique pointer, the value goes out of scope when the pointer does. You may have a shared pointer, when the pointer goes out of scope you decrease a counter and when that hits 0 the value goes out of scope. It's similar to rust ownership and borrowing semantics, but less safe. E.g. pointing into existing data remains awkward because other code could move the data around without your knowledge.
I’ll try, although I won’t talk specifically about the C++ shared pointer as I don’t know exactly how it’s implemented, but about the general idea of reference counting, based on a language with reference counting I‘ve written myself. In case you don’t know: a pointer is a memory address. In C/C++ and many other languages, you can get the address of a variable by using the & operator, and read the value stored at the address something is pointing to with the * operator. Example: int a = 25; int *b = &a; // type of b is int* or int pointer int *c = b; int d = *a; // d == 25 Maybe that explained it, maybe not, feel free to ask for a better explanation. When you heap-allocate an object (meaning you create it somewhere in ram and you would have to manually delete it afterwards with normal pointers), it gets stored alongside with a reference counter which is just an integer starting at 0. Now, every time you copy the smart pointer to the object, the reference counter of the object is incremented by 1. Every time a smart pointer to the object gets deleted, the reference counter is decremented by 1. Once it hits 0 again, the object is deleted.
You computer has a place where it can store and retrieve stuff quickly which is the RAM memory. In C++, when you assign the memory from your computer manually, and you unassign it manually. This is sounds simple, since you just need to remember the memory address. But your address for your the memory of your friend may be inside a pocket of a trouser, and the address of the trouser was inside my wallet and the address of the wallet was written on potato. You cooked the potato? Darn, now you can't find the wallet or the trousers or your friend! The are completely lost. Since computer programs execute the same code again and again, you may accumulate "lost memory" over time, which is locked waiting for you and can't be used by other programs. This is called a memory leak, and is the reason you need to close Chrome or some other programs when they slow down, and open them again to get your computer to come back to life (in the past, you had to reset your computer as a whole). A smart pointer keeps a list of in how many places the address of said pointer is kept. If no one has the adress anymore, it knows the pointer can't be used anymore, and deletes it, freeing the memory automatically. Of course this makes the program slower, but a working program > fast program.
Is this how ARC works for swift?
Yes. ARC = Atomic Reference Counted.
What’s the advantage of using a garbage collector over shared pointers in languages? Do garbage collectors save memory? I can’t think of any other thing that might be the reason for people to use garbage collectors Edit: I meant reference counting, not directly shared pointers
Not having to deal with memory management at all is a big reason. Garbage-collected languages - really not having to distinguish between heap and stack, just making variables as needed - are way faster to write in than systems languages, even if said systems languages have smart pointers
I should’ve written reference counting, not shared pointers. I wrote a language myself that uses reference counting. There’s 0 memory management for the user
Technically garbage collection can refer to any automatic memory management strategy, including reference counting. But you're probably asking about mark-and-sweep garbage collection, which is how Java and C# work, and what people usually mean by "garbage collection". Mark-and-sweep has two advantages over reference counting: First, it easily handles cyclical references, which are a problem for reference counting. Second, it actually has *lower* overall overhead than reference counting most cases, because it doesn't have to constantly update references. Those updates can be especially expensive in multithreaded environments, because they must be done atomically. The downside of mark-and-sweep is that it must periodically pause the entire application in order to execute. So while it is lower overhead overall, it periodically has relatively long periods where nothing else is being done. This has historically made it poor for real time applications like games. Modern mark-and-sweep algorithms have sophisticated strategies for mitigating this problem, which is why you can see games made in Java (Minecraft) and C# (Unity) these days and probably never notice the GC pauses.
It is incorrect to say that using shared pointers has less overhead than a garbage collector. It depends on the scenario. For instance, allocations can be much faster when using a garbage collector, as you'd typically just have a bump allocator vs. individual allocations (of course, yes, one could also use a custom allocator). Additionally, using shared pointers will add overhead during use, whereas using managed objects directly will be faster. The overhead of the GC comes from collections, but you can avoid them if you don't allocate. That is, if you allocate some objects and then just do a whole bunch of work for however long you need, without further allocations, the GC will literally never run at all. Not saying one is better than the other, just saying neither is definitely better or faster than the other either, it depends on what you're doing and how well written your code is 🙂
Basically not.
it's a guard pattern on a raw pointer if you are more familiar with that. (the destructor automagically deletes your allocation.)
I’d suggest anyone reading the replies to the main comment immediately forget what they read and google “C++ smart pointers RAII” to start with, before reading some actual cpp resources to learn more about the additional mechanisms of the STD smart pointer types.
A wrapper type around a raw ptr which helps with memory safety. There is a reference counted ptr which is only freed after all references are gone. There is a unique ptr which cannot be shared etc etc
In essence: reference counting. The goal is generally to make heap allocations safer, resulting in a slight performance overhead for the general safety of not shooting your leg off. More or less (very simplified): ``` struct rptr { size_t* counter; void* data}; struct rptr = create_rptr_xyz(...); // counter = 1; allocate data ... struct rptr2 = borrow(rptr); // counter = 2 ... // on scope leave release(rptr2); // counter = 1 ... // yet again, on scope leave release(rptr); // counter = 0; call free for data``` But using RAII for that automagically and special derivatives, for weak references and unique (as in: one owner) allocations. It can be considered to be best practice nowadays for non performance critical code.
No.
You're correct (ownership is what matters and the existence of non-owning references makes it different from reference countings), but considering the amount of false C++ knowledge here, I will pass.
“In essence: reference counting” is not just false C++ knowledge, it’s false programming knowledge
Smart pointers are, in it's very most basic formulation, reference counting. There is no magic involved or a random ghost of a gc appearing in cpp, it is just reference counting when stripping it down to its essential parts
Again, no. Smart pointers are not reference counting, it’s just that reference counters _can be_ smart pointers.
There are roughly two definitions. An owning pointer type with kind of RAII semantics (C++ example: `std::unique_ptr`) or any type that generalizes or narrows the concept of a raw pointer. Commenting on other replies, reference counters can be smart pointers, like `std::shared_ptr` in C++, but they can very well not be, being instead a whole separate automatic memory management model of a language, separate from tracing (tracing is usually called garbage collection).
A smart ass word for a struct that wraps a raw pointer and when the struct is removed from stack the raw pointer memory is cleared. It comes in few flawours like shared_ptr which is the most primitive version of GC - you count how many shared pointers to object exist if number gets to 0 you remove the memory, unique_ptr - heap object is bound to stack object, when stack object die heap object also die, there is also weak_ptr - a view to value of shared_ptr ( not counted as reference ) and observer_ptr - a wrapper around normal pointer with implicit cast from other smart pointers
It's a pointer ... with extra steps. ;)
There are a lot of resources in programming where you need to do something to acquire them, and then later something to release them. Pointers have new/delete, files have open/close, mutexes have lock/unlock, and so on. No one forgets to acquire a resource, because you can't do anything without that, but it's easy to forget to release it, which causes memory leaks, deadlocks, locked files... It would be really nice if the compiler could detect that and ensure all resources are released once you don't need them. C++'s solution is that you can tie custom behaviour to both constructing an instance of a type, but also to dropping that instance when it goes out of scope. As soon as no one is keeping track of a file handle, there's no way for the program to access that file, so you can safely tell the OS to close the file once the handle variable goes out of scope. Smart pointers are just the "handle" types for memory allocation. You've got unique_ptr for when you only need one "owner" of the memory, and shared_ptr for when you need multiple "owners". As part of creating/setting the smart pointer, you call new (ideally implicitly), and then when unique_ptr goes out of scope it calls delete. shared_ptr keeps a reference counter, and the last shared_ptr to drop from scope calls delete. Some C enjoyers dislike automatic resource management like this, because it's one of the several ways that C++ "hides" operations that might have a performance impact (same as operator overloading), but I like it because it entirely removes whole classes of bugs that plague software.
It's a way to use pointers such that you don't have any floating unused heap space. They're honestly relatively simple to implement if you spend less than an hour trying to implement it.
C++'s smart pointers encapsulate raw pointers into different owner models: unique and shared. Unique is 'unique' to the scope it was constructed in (unless you 'move' the resource) and will destroy the pointer once its lifetime is over. So it's meant that only one pointer can point to the resource. Shared pointers can point to the same resource across different scopes; the resource will be destroyed and freed after every shared pointer goes out of scope, I.e the reference counter equals 0. So basically their point is to prevent memory leaks.
Look up c++ template metaprogramming. You can do a lot of compile time error checking with that if you know what you're doing.
You can do std::unique_pointer or std::shared_pointer to have some macro magic make your unsafe code a bit safer.
No macros are involved in smart pointers. And more specifically they can completely eliminate memory leaks, double frees, dangling pointers, etc where used.
I think you can still shoot yourself in the foor if you have a cycle of smart pointers, but it should not be too hard to avoid that happening.
That's why weak smart pointers exist.
that "can" carries that sentence like a "can" in a health supplement ad
I just added that because you can still go out of your way to break memory safety. For example. auto ptr = std::make_unique(10);
delete ptr.get();
But it's really not that hard to properly use smart pointers and maintain memory safety.
Thanks, I'd like my pointers medium rare
"Ever used smart pointers? \- Sure, I even coded my owns!"
There was stuff like that we had to do back in the day.
Hehe. Yeah. It had to start somewhere. But people keep doing it despite having good standard libs now and it becomes a bigger liability :(
In reality both sp are good until the first change request or new feature to software. Later it is heavy weight which significantly slows down development and natural software evolution. It forces you to create tens or hundreds of unnecessary code entities just to handle language features, and has no extra business value.... And the funny thing is - the memory is still leaking, all the time...
If you actually did use smart pointers properly, memory won't leak. It will leak tho when just always using shared_ptr and ignoring cyclic references
Where there's a 2nd thread, there's a way.
For an assignment in C we needed to make sure to free all memory we allocated before shutting down, so I made a wrapper for malloc that added the pointer to a linked list, then at the end I just ran free on every pointer and link in the chain. Dirty as hell but hey, it worked and I never had a double free or a leak
I hope you also used your malloc function when appending to the linked list to make sure its pointers are all freed in the end /j
"I even combined third party shared pointers with a wrapper shared pointer that managed the reference counters on its own. Oh, I also had to use multiple inheritance due to the design of those libs."
Yeah we used to have to make our own back when I went to school, because the STL was such shit
Been there, Godspeed my friends. I’m glad there’s a few of us crustations still around
It's not actually that hard to code `std::unique_ptr`.
Smart pointer are for plain programmers. I'm a smart programmer so I only use plain pointers.
Plainly smart.
Ever used smart pointers? Yeah, I used them to build a directed graph!
Some of us used C++ before it had smart pointers
The C++ they taught us in college in 2001-2003 looked nothing like what I see posted here now. I dont remember smart pointers, only regular and then the double splat, etc. Moved onto higher level stuff after college so I forgot nearly everything I knew.
The other comment is wrong, C++98 has `std::auto_ptr`. Syntax hasn't changed much since then, but lambdas and views can look scary at first glance.
I mean, standard library ARC is pretty new but auto_ptr has been around since at least 1998 (It's hard to find information on C++ before that)
I have c++ reference books on the shelf next to me from 1992
There’s nothing smart about auto_ptr :)
ah yes, sYnTAx `std::auto_ptr a=b;`
`assert(a.get()==b.get());`
\*fucking dies\*
Pretty dumb meme tbh. Smart Pointers were introduced in what, c++ 11? Ever worked with hardware specific compilers from the early days? Sometimes companies are locked to those things for decades.
Yeah, I completely agree. Sometimes, I feel like junior just stumbles on another keyword while learning and makes edgy memes like this one.
C++98 had `auto_ptr`.
if you dont use raw pointers you're literally not even a c++ programmer, you're a java programmer that is afraid of memory management
Kind of agree. Especially in the context of something like a memory pool written for an application.
BMW owner logic
honestly no idea what you're trying to say
Being afraid is not always the reason for not doing x instead of y
yea that's why only siths deal with absolutes
The circle of fifths on my flute, you say?
/s ?
absolutely not
What if I don’t even use heap
Nah, you are not a C++ programmer unless you use a template in every line
see you're trying to meme, im being dead serious
I am also serious C programmers use raw pointers. C++ got templates
Terrible take of someone that doesn't know unique pointer. C++ without them is just C with classes. Heap is slow and vulnerable. Smart pointers are how you do memory management in C++. That and using the stack as much as possible.
C has classes. They are called struct. You are welcome.
kid named method
People these days have language with 10000 different syntaxes but think that: class.method( and method(&class, are two completely different things. Not only that, but if you really want your class.method syntax, you can actually do it using function pointers. At some point people need to understand that OOP (Object Oriented Programming) is a conceptual approach and is not tied to a language. And that OOL (Object Oriented Languages) are designed to force you to use OOP. Yes some languages make it harder to apply the OOP paradigm. C is not one of them. C just allows you to do something else if you desire.
Yeah, that function pointer syntax is nice, but it’s +sizeof(void*) bytes for every function you add, plus an indirection whenever you call it (or does that get optimized if you don’t change it?)
> plus an indirection whenever you call it (or does that get optimized if you don’t change it?) If the compiler can determine which implementation will be called, it will devirtualize the call, meaning there is no indirection. There are a few ways the compiler could determine this: * The class is `final`, which prevents subclassing. * The method on the class is `final`, which prevents overriding the method.. * The class only exists in one translation unit (anonymous namespace) and there are no subclasses in that translation unit. * The pointer refers to an object that was constructed in the same function (accounting for inlining) and could not have been reassigned.
Definitely different. Im not sure id call C OOP.
70 years of paradigm theory would like to have a chat with you
I welcome them
Women have penises. They're called vaginas.
A lot of times you don't even need to use pointers. Put the data in vector and let vector manage the memory allocation for you.
Most devs I know only use smart pointers.
I’m curious, do they ever make their own data structures which they need to have highly optimized? (For example, tree-like structures such as Suffix Trees.) I feel like using smart pointers are great for most things, but I still prefer to use raw pointers for something of this nature, personally.
Unique pointers have no overhead. In situations where you want the tree to have shared ownership, rather than copy shared pointer overhead is minimal. When highly optimized low latency code is necessary, which is rare, then yeah maybe something besides shared pointer is necessary. But I expect most people writing their optimized data structures using raw pointers for speed are doing some premature optimization. Start with smart pointers always, if through profiling one finds the overhead to be significant, then maybe consider a different solution.
That's fair, but when it comes to something like competitive programming, raw pointers *can* be desirable (for performance, size constraints, and how fast you can type it up compared to the smart pointer counterparts). Ultimately, it comes down to use cases. (For example, the coding style of competitive programming tends to differ quite a bit from "good"/readable/reusable code.) Generally, I try to avoid pointers entirely (raw or smart), where possible (in favor of references); of course, this isn't always possible.
I’ve never done competitive programming so I’ll take your word on that! It makes sense though. Avoiding pointers is definitely best, and in most cases are likely unnecessary since we should all be using battle tested libraries as much as possible that do the pointer work for us. For those of us that do lower level or library work(for certain domains that is), then pointers will likely be plentiful. I’m currently working on an abstraction layer over SYCL that distributes problems over multiple devices, but from a user perspective is treated as a single “device” to simplify distributed parallel programming and my oh my, shared pointers everywhere. Fortunately the added latency and memory footprint introduced by smart pointers is but a mere blip for HPC workloads haha.
And they still use C++ ? If only there was a language where all pointer are smart...
It’s almost like it’s their job and they can’t just change the language on a whim because of a single feature.
I mean as much as people rag on C++, it’s my language of choice and I’d be bummed to use anything else. Don’t get me wrong, the language is massive and having learning what not to use because most of the features are antiquated af is definitely a huge con for the language. But if limited to modern features, especially C++17 and up, the language is quite nice. Understanding exactly what is happening on a machine level with your code, more or less, rather than relying on a runtime to do garbage collection makes, while still having things be cleaned up “automatically” is my favorite part about it. ETA: I fucking hate the build ecosystem, however. Want to use multiple compilers? Good fucking luck. Got to use external project add. But now, suddenly CLion has no code insight of the external project. So, some compilation database cmake flags and a custom command using jq to merge the databases later, I now have code insights once again. A fucking mess. Just spent my entire work day figuring this out hence the sudden shift in tone lol
I hope you are not talking about java or c# here. So I have to ask, which language are you talking about?
Because using smart pointers makes you a good C++ programmer? 🤦♂️
Std::move()
std::shake_it()
std::free() ❌ std::shake_it_off() ✅
\*extremely loud incorrect buzzer\*
I'm not a C/C++ programmer, but shouldn't it be the other way around? If you can write good code with "raw" pointers then then that makes you better than someone relying on a "smart" crutch. Doesn't it?
No, it doesn't. It makes you an idiot that swats flies with a piece of yarn when you have a spatula available.
I don’t use smart pointers because I don’t use heap.
Fuck smart pointers. Raw pointers full speed full power full danger! (Most of my CPP code is just C code with a hat and trench coat.)
Sameeee
It should be the other way around, downvoted.
tbh so far using smart pointers caused me more memory leaks than not using them. people like to just throw them around without care, but they dont always free themselves. i had a very annoying days worth of debugging when a new senior arrived, got angry at us not using smart pointers, rewrote our code to use them. he missed the fact that there were some very cleverly disguised directed loops of pointers in the data structure. he just removed all destruction related to pointers, so the loops couldnt resolve smartly, as they were locking each others reference numbers. ofc the solution is easy, just need to use at least one weak pointer in every cycle, but i basically had to rewrite the parallelised constructor to explicitly detect loops, yada yada yada and this wasnt the only case when i got punished for using them when working with complex custom data structures. if id give up an idea after the first mental breakdown, i wouldnt code in cpp, lol to be clear: i can see the point of them, but thinking strictly about destruction seems a safer approach to me so far. i may be wrong, but i have the same doubt about using them as about using rust: >!^("isnt this just for people who are a bit shit at cpp?")!<
Part of growing up is realizing that *everybody* is a bit shit at C++
i mean yeah, but the tradeoff seems to turn negative at a non-zero shittiness. these restrictive crutches seem to be optimised for a subpassable ammount of shittiness edit: i.e. "either you die a rust user or cpp long enough to git gud"
I use smart pointers because I don't trust my coworkers to handle raw pointers correctly...
> but thinking strictly about destruction seems a safer approach to me so far No, the correct way is to think about ownership. If you're coworker came in and just replaced everything with `std::shared_ptr`, then they weren't thinking about ownership at all.
Sounds like a skill issue tbh. Shared pointers are bad most of the time, not because they don't work because but needing them is code smell and more often than not just unnecessary
So basically she is honest. C programmers are good C++ programmers. Because they understand how memory management actually works.
Case in point: about 1 million buffer overflow exploits and memory leaks.
Come on, most developers do not really care about memory leaks. Only if they run into memory overflows. Also you can run in any language into memory leaks. A ref counter won't save you. Buffer overflows most likely happen because you are using the wrong functions (not reading documentation) or make inproper allocations. Can both still happen with smart pointers.
What's.... Smart pointer?
The one thing learncpp is CONVENIENTLY not mentioning at all whatsoever. Edit: Apparently they added it this year.
What's the point of c++ if you're not using delete?
i would rewrite the whole story (bad ending also): ~ im a good c++ programmer - be honest ~ yeah im being honest - ever used smart pointers? ~ yeah; for example QScopedPointer, QSharedPointer with several macros prevent overflow or all sorta errors - …… - okay ur recruited go develop the animator for Disney Co Ltd ~ okay Three months later <… TechSolutions-Animator has stopped working. Reason: exit code no. 11 (SIGSEGV) Call stack QtCore.dylib …………> - u really know smart pointers?!!!!! ~ sir, no… I mean yeah, of course i do yeah, but you know, uh, in this case… - shut up. ur fired. ~ f**k. but fair enough.
Programming isn't about what über special functions and quirks of your language you use but about getting the job done. Change my mind while I use Micropython for Microcontrollers because C is annoying 
You shouldn't need smart pointers if you are handling things properly. When something is to be free'd, null all of your pointers to it. It's not hard. They do occasionally make lazy access easier though, so have at it i guess.
wait till a program throws an exception before freeing the memory lol. RAII is the best thing ever
Say it louder for the people teaching tutorials on modern C++ and still refusing to use modern features
Way better to learn without those modern features first, than with, to truly understand why modern features are useful. Especially when you consider that you’d be absolutely fucked if you had to jump in to a code base that does not use modern features, and you’ve only learned to rely on them.
Man, imagine the first carpenter who came across a chisel. "Fuck, this would be so handy, shame that nobody back home uses this, no reason to learn this amazing tool" - you should NEVER stop learning and mastering all aspects of the language you're using even if you dont get to use it on whatever you're working on now.
That is a great analogy.
No, C++ should be learned with those features so you understand them. This is why people struggle to use C++, because they are only taught C with classes and the second they need to use actual C++ features they want to do it the C way and fail
A)There’s a reason I used the word “first”. B) u/belabacsijolvan gave a pretty good example of smart pointers being used, and the use of them fucking everything up. C) As I mentioned above, good luck to those who’ve only learned to use modern features, when they don’t have the option of using them.
Well, that explains why people can't understand C++ errors or the std library, with this mentality
First and only are not synonymous. Don’t know why you think I was saying that one should stop learning before learning modern features.
I'm not misinterpreting what you are saying. What I am saying is that C++ is a higher level than C language compatible with C. I understand learning C and the value of learning to create classes around it. But teaching C++ as if It was C leads to bad C++ practices
I agree with most of what you are saying, except I believe that having an understanding of what is being taken care of for you with smart pointers, will lead to a greater understanding of when to use them and not. if, by chance, the use of them is causing a bug, such as in the example provided by u/belabacsijolvan above, then it’s going to be much easier to debug and fix if you already understand how to do it the hard way. In no way am I saying to not learn the very useful features of modern c++
I do think a deeper understanding is better. I haven't written Assembly in my life, but I like reading it and understanding it, cause it is what the machine uses. I like knowing and understanding C because it's simple and powerful. And I like using C++ because it makes it safer to use an "unsafe" language. But I learned all these separately, I wasn't taught C with classes because I already was taught C, precisely to avoid writing dangerously inadequate C++ code
I did the same in terms of C first and then C++, but was forced to use raw pointers all through school, with the exception of upper year networking courses. It wasn’t c with classes, as smart pointers were the only modern c++ feature we were not allowed to use. Smart pointers are a god send, but not being allowed to use them was beneficial in the long run, despite the many lost hours of sleep it caused.
Too much overhead, you just need pen and paper.
Smart pointers are dumb?
yes I even moved them around with std::move()! Although I'm not sure if they just stayed as an Lvalue and got copied.
What is the difference?
Ever used rvalue references with auto and decltype?
Seriously I was asked this in an interview, and also said no
I never get to use pointers in C++. However, I use pointers a lot when programming in C, mainly because I want to use dynamically allocated strings (rather than static ones).
Genuine question, as someone who learned C++ using kind of outdated information (University...), which smart pointers should I use when programming in C++? Which ones are the most useful?
std::unique\_ptr and std::shared\_ptr
Smart pointers is for kids. Is it so hard to delete things you allocate? Do you have memory of golden fish and forget about things you create? Do you know how class destructor works? I'll be honest - fuck smart pointers.
Raw pointers are fine if the object's lifetime is well controlled. And also, knowing smart pointers exist isn't gonna save you on older projects that aren't using newer C++ versions, and it certainly won't help you when you somehow end up with a bad ref count.
Ahem… what is a smart pointer
I used C++ without libc++/libstdc++ and it was horror. Never using C++ with only libc again.
the amount of people claiming to know C++ but don't know what the STL is lol
std::shared_ptr is awesome The best parts of C++ are the stuff that isn't C with classes imo. Screw classes. Give me a struct with almost everything public and const