- Forum
- General C++ Programming
- Are smart pointers widely used?
Are smart pointers widely used?
I first learned to program C++ in the 1990's, so I tend to think about C++ in pre-C++11 terms. I'm starting a new hobby project and have been reading up on smart pointers (I'd like to create an editor that edits a tree of nodes, so having shared pointers seems to make a lot of sense). However, I'm a little reluctant since I've come across so few uses of smart pointers in the wild. I've never worked professionally on anything that used smart pointers, and the news group posts I read seem to be evenly divided between "it's the modern way to do things" and "it's a crutch for people who don't really know how to program".
Are smart pointers widely used and it is good practice to use them?
Are smart pointers widely used and it is good practice to use them?
Don't use new. Don't use delete. Don't do old-school manual memory management.
Once you've internalised that, your options are (in rough order of preference) to not use the heap, to use existing containers that handle memory for you (such as vector), and smart pointers.
In cases where the pointer isn't for memory management but just as a handle to some other object, a reference is better.
Smart pointer exist for good reasons. Very good reasons.
It's not about being "modern". It's about writing safe, correct, efficient code that's easy to understand, maintain and alter.
Once you've internalised that, your options are (in rough order of preference) to not use the heap, to use existing containers that handle memory for you (such as vector), and smart pointers.
In cases where the pointer isn't for memory management but just as a handle to some other object, a reference is better.
Smart pointer exist for good reasons. Very good reasons.
It's not about being "modern". It's about writing safe, correct, efficient code that's easy to understand, maintain and alter.
Last edited on
the STL lacks a tree, so if you are rolling out your own, you either need to fake it like my post on stuffing a tree into a vector, or use some kind of pointers.
there are quality tree libraries out there, pretty sure boost has one.
or, can you do it some other way? Why a tree?
there are quality tree libraries out there, pretty sure boost has one.
or, can you do it some other way? Why a tree?
It's to let the user interactively create a set of nodes kind of like a flowchart. They can create boxes and simple shapes, draw connecting lines between them and add text to them. So I'm going to need to create a lot of nodes, as well as delete them (or let them be reference collected) and change how they are ordered.
I think the premise of creating them on the heap and using pointers to keep track of who is referring to who is a good one - I'm just trying to see if managing this with smart pointers is a good idea.
I think the premise of creating them on the heap and using pointers to keep track of who is referring to who is a good one - I'm just trying to see if managing this with smart pointers is a good idea.
you may want to to a full graph instead, if they can come in to edit and set 5 new nodes that lead into the previous 'root' or something like that (?). As far as pointers go, I am a bad person to ask; I would do it the way you suggest but I am also a 90s era coder at heart. I don't know a way to avoid dynamic memory if making a classic tree or graph without jumping thru weird hoops. I mean you can treat any stl container's 'add to me' functionality as a replacement for 'new' etc...
Last edited on
| kitfox wrote: |
|---|
| I've never worked professionally on anything that used smart pointers |
All C++ code I've ever worked on professionally used smart pointers, going back well into the 1990s. It also used raw pointers, both have their place.
And yes, despite that you've heard that it's "the modern way to do things" , many types of smart pointers were around in the 90s. Two of them were even proposed for the C++ standard in 1994 (shared ptr proposal failed and was picked up by boost to evolve there, scoped ptr proposal was accepted with modifications, as auto_ptr)
| kitfox wrote: |
|---|
| a tree of nodes, so having shared pointers seems to make a lot of sense |
Put them in a single container (perhaps from a graph library), maintain inter-node relationships as keys/indices into the container (or if you can't afford lookup cost, as non-owning raw pointers, but then you have to keep lifetimes in mind).. or if it's really a tree, let each parent own its child - again, no parent sharing involved.
Last edited on
Well, I was thinking of having a top level Document object that would be the main 'owner' of all the nodes. However, I'm going to need to pass these to different user interface components to be viewed and edited. I'd also like to have have features, such a list that tracks the currently selected nodes, or a connection object that indicates a relationship between two nodes.
If I were to use a unique_ptr to refer to these nodes, my understanding is that my Document object would loose track of the node as soon as it passed it to something else to use. That seems to leave shared_ptr for tracking these nodes. Or are you suggesting that I allocate my nodes in something like a std::map in my Document and use some sort of token object to grab a reference to them when something outside of the Document needs to refer to them?
If I were to use a unique_ptr to refer to these nodes, my understanding is that my Document object would loose track of the node as soon as it passed it to something else to use. That seems to leave shared_ptr for tracking these nodes. Or are you suggesting that I allocate my nodes in something like a std::map in my Document and use some sort of token object to grab a reference to them when something outside of the Document needs to refer to them?
| I first learned to program C++ in the 1990's, so I tend to think about C++ in pre-C++11 terms. |
I started in C back in the late 70's, and took up C++ in the late 80's. When C++ "2.0" was released (the version where templates were introduced), and the compilers began to support them, creating "our own" smart pointers and containers was one of the first things "everyone" (using C++) did. That was in the middle 90's.
So, yes, smart pointers are foundational to modern C++ development. What you are referencing as post C++11 (inclusive) ideas is the simple fact that smart pointers were first brought in as a standard in C++ at that time. Their use had already become central to the work long before.
Indeed, the entire idea of the smart pointer is a simple, direct example of RAII, which is even more fundamental than smart pointers themselves.
You will not find a competent C++ programmer this side of the 21st century writing any dynamic allocations that does not use smart pointers, unless everything goes into a container (which, if you think about it, is merely a different category of storage).
Smart pointers are containers for 1 (setting aside the notion of specializations for arrays and such).
Anyone telling you they are crutches is missing the point of the language and should not be referenced for any form of wisdom on the subject. Anyone who thinks that way has ignored all that happened in C++ since about 1994.
Also, learn all of them. Smart pointers are not always shared pointers. Shared pointers have their place, but they are quite often overused (in part because for a long while they were about the only smart pointer in use). Where the shared pointer is indicated, use it.
If you read any text regarding the relic "auto_ptr", be advised this is a deprecated version that has been replaced. It was a mistake (a fundamental flaw in the design went unnoticed for a while). It is still referenced in older texts and posts, but has been replaced by the likes of "unique_ptr" and "scoped_ptr".
Or are you suggesting that I allocate my nodes in something like a std::map in my Document and use some sort of token object to grab a reference to them when something outside of the Document needs to refer to them?
That may be an idea. But its just that, one idea. Does it seem to fit your needs?
That may be an idea. But its just that, one idea. Does it seem to fit your needs?
| It's to let the user interactively create a set of nodes kind of like a flowchart. They can create boxes and simple shapes, draw connecting lines between them and add text to them. |
A drawing program? None of the already existing fits the bill?
I think Torvalds did call entire C++ a crutch and does not allow any into Linux kernel.
| I think Torvalds did call entire C++ a crutch and does not allow any into Linux kernel. |
Actually, he said worse at the time, but it was in the early 90's.
His insistence on C is both historical and because of his own familiarity and preference. Torvalds was critical of C++ before "version 2", when templates were first introduced, and has little to no commentary in the modern era of the language.
Topic archived. No new replies allowed.