Do you believe smart pointers teach bad habits
Pages: 12
Hey guys, I would like to hear your opinions on smart pointers. The main question I have is, do you believe they teach bad habits when it comes to managing memory?
For instance, you use smart pointers for many projects and usually never has to call delete, but then you get assigned to a project that requires manual memory for whatever reason or you have to use a different language like plain C.
Wouldn't it be difficult for someone being so dependent and used to memory freeing itself to keep track of and free everything their-self, as opposed to someone that always uses the more traditional way without smart pointers?
I also understand that some people may probably never have to use manual memory so much. Regardless of what is considered "correct c++", wouldn't it be better to use the traditional way of managing memory in case you are needed to in a large project, and do you believe that it would make you a better programmer overall.
For instance, you use smart pointers for many projects and usually never has to call delete, but then you get assigned to a project that requires manual memory for whatever reason or you have to use a different language like plain C.
Wouldn't it be difficult for someone being so dependent and used to memory freeing itself to keep track of and free everything their-self, as opposed to someone that always uses the more traditional way without smart pointers?
I also understand that some people may probably never have to use manual memory so much. Regardless of what is considered "correct c++", wouldn't it be better to use the traditional way of managing memory in case you are needed to in a large project, and do you believe that it would make you a better programmer overall.
I don't think it teach bad habits but the problem as I see it could be people using them without knowing how they work and what problems they try to solve. Maybe beginners should start without smart pointers so that they can really appreciate and understand smart pointers later.
I completely disagree. You should always use the more high-level technique first and then only switch to low-level when required. What do you think pseudocode is for? When was the last time you needed to manually type up a sound file in notepad?
Your argument is similar if not the same as suggesting to teach c-style dynamic arrays and character pointers before teaching std::string and std::vector - it is widely agreed that strings and vectors should be taught first.
Your argument is similar if not the same as suggesting to teach c-style dynamic arrays and character pointers before teaching std::string and std::vector - it is widely agreed that strings and vectors should be taught first.
Last edited on
From what I see, 90% of the assignments that given in classes these days are teaching students to do things that the standard library already does. Look at all the questions about linked lists, finding the min/max/average values, classes to implement strings or dynamic arrays, queues, stacks, etc. Isn't teaching memory management just another example of this? Maybe it's a good idea to teach this stuff so people understand the issues and what the library is doing. Or to put it another way, if it's bad to teach memory management, then why any of these other things when the library has well designed classes and templates to do it for you?
I don't know the answer, just raising the point.
I don't know the answer, just raising the point.
I understand that it makes life a lot easier for programmers, but I just feel it would be better to use standard pointers.
Let's say you're creating a bunch of software and are using standard pointers, but for whatever reason the memory isn't freeing(whether simply just forgetting to call delete or something else wrong with your code). So you just change to smart pointers instead of working out what you did wrong and trying to correct it, and the smart pointers corrected it for you. Now let's say you get a job doing some embedded stuff in C and you're on a tight deadline. You get the same problems you do every time you use standard pointers, but this time you can't just depend on smart pointers to fix your mistakes for you, and without all the experience of going through and finding out where you screwed up you could miss your deadline.
Whereas someone that mostly uses standard pointers and/or has gone through and fixed their problems before instead of using smart pointers to fix it, would have an idea of what went wrong and where to start looking, or maybe even not have the problem at all from the experience of always using manual memory.
Let's say you're creating a bunch of software and are using standard pointers, but for whatever reason the memory isn't freeing(whether simply just forgetting to call delete or something else wrong with your code). So you just change to smart pointers instead of working out what you did wrong and trying to correct it, and the smart pointers corrected it for you. Now let's say you get a job doing some embedded stuff in C and you're on a tight deadline. You get the same problems you do every time you use standard pointers, but this time you can't just depend on smart pointers to fix your mistakes for you, and without all the experience of going through and finding out where you screwed up you could miss your deadline.
Whereas someone that mostly uses standard pointers and/or has gone through and fixed their problems before instead of using smart pointers to fix it, would have an idea of what went wrong and where to start looking, or maybe even not have the problem at all from the experience of always using manual memory.
| Let's say you're creating a bunch of software and are using standard pointers, but for whatever reason the memory isn't freeing(whether simply just forgetting to call delete or something else wrong with your code). So you just change to smart pointers instead of working out what you did wrong and trying to correct it, and the smart pointers corrected it for you. |
Except you know what you did wrong. You failed to free memory. Instead of dealing with that manually (which you just agreed is an error-prone process), you let a structure deal with it for you.
| Whereas someone that mostly uses standard pointers and/or has gone through and fixed their problems before instead of using smart pointers to fix it, would have an idea of what went wrong and where to start looking, or maybe even not have the problem at all from the experience of always using manual memory. |
Of course someone who uses technique A is going to be better at using technique A than someone who uses technique B. What you're describing is not unique to raw pointers vs smart pointers.
Is your argument that, as C++ programmers, we should just use raw pointers on the off chance that we may be writing some C or older C++ code? Should Java developers not use the tools provided by Java, because they might have to work in an environment that does not supply the same tools? Should someone driving a car not use the steering wheel because that won't be available on a bicycle?
@dhayden: I don't agree with the teaching methods employed by many professors.
@all:
Can you honestly say you think it's better to learn about quarks and charged particles and atoms and molecules and compounds before you learn how to bake bread? Abstraction exists for a reason: it is something we can understand easily and break apart if needed. You don't need to be a physicist to bake bread (which involves a chemical reaction), but you can become a physicist if you want or need to. In general, you don't need to become a physicist to bake bread.
@Mechennyy: You can't argue against C++ abstractions by saying "what if you have to write in C?" - it's not a valid argument.
@all:
Can you honestly say you think it's better to learn about quarks and charged particles and atoms and molecules and compounds before you learn how to bake bread? Abstraction exists for a reason: it is something we can understand easily and break apart if needed. You don't need to be a physicist to bake bread (which involves a chemical reaction), but you can become a physicist if you want or need to. In general, you don't need to become a physicist to bake bread.
@Mechennyy: You can't argue against C++ abstractions by saying "what if you have to write in C?" - it's not a valid argument.
@LB I never said anything about learning raw or smart first, just which would make you a better programmer(in my opinion). Writing in C was just the first thing that came to mind, but I don't supposed that smart pointers can be used in place of raw in every situation?
@ResidentBiscuit
That's different, Java was made with that in mind. C++ was originally going to be just classes and a couple other things added to C(Which ended up being a lot more). Smart pointers was added just a few years ago.
Nothing to say there because I drive a motorcycle, never drove a car.
Same thing I said to LB, I don't supposed that smart pointers can be used in place of raw in every situation?
@ResidentBiscuit
Should Java developers not use the tools provided by Java, because they might have to work in an environment that does not supply the same tools? |
That's different, Java was made with that in mind. C++ was originally going to be just classes and a couple other things added to C(Which ended up being a lot more). Smart pointers was added just a few years ago.
Should someone driving a car not use the steering wheel because that won't be available on a bicycle |
Nothing to say there because I drive a motorcycle, never drove a car.
we should just use raw pointers on the off chance that we may be writing some C or older C++ code? |
Same thing I said to LB, I don't supposed that smart pointers can be used in place of raw in every situation?
Last edited on
Even some of the best programmers have issues with memory management in C++.
I may seem hypocritical for writing this (people who have looked at my code will know that I enjoy managing memory manually), but I still strongly recommend using smart pointers wherever they can be used.
Just be careful with
-Albatross
I may seem hypocritical for writing this (people who have looked at my code will know that I enjoy managing memory manually), but I still strongly recommend using smart pointers wherever they can be used.
Just be careful with
std::shared_ptrs, though. Shared pointers aren't bad, they just have specific use cases while being very tempting to abuse.-Albatross
| LB wrote: I don't agree with the teaching methods employed by many professors. |
I thought about C++ instruction some more. Maybe it's best to teach the STL to beginners. It's easier and it will instill good habits in all programmers. High level classes for CS majors could then get into the details of how one might implement the collections and algorithms.
| Menchennyy wrote: |
|---|
| You get the same problems you do every time you use standard pointers, but this time you can't just depend on smart pointers to fix your mistakes for you, and without all the experience of going through and finding out where you screwed up you could miss your deadline. |
Of course, you would never have had this problem if you just used smart pointers in the first place. After all, I can't think off the top of my head of any situations where a smart pointer or reference (maybe std::reference_wrapper if necessary) can't be used over a C-style raw pointer.
Its similar to a problem that pops up when people try to learn a second programming language, as they could try to use it as if they are using their original language (which often doesn't work). The point is, use C++ abstractions and functionality when you are coding in C++. Treat having to work 'C' style as a different language - just because C and C++ have very similar syntax and the same base doesn't mean that you can treat them as the same language in any way.
Last edited on
The point is, use C++ abstractions and functionality when you are coding in C++. |
Then why is char* and arrays(among other things) still available in C++?
For everyone that claims that manual memory management is unacceptably unsafe, with that logic <vector> would be unsafe since it was written using manual memory.
| Menchennyy wrote: |
|---|
| Then why is char* and arrays(among other things) still available in C++? |
I believe this is for a few reasons. The primary reason would be compatibility - C++ was developed from C, hence it originally would have had them, so people would use them. It would now be a silly idea to get rid of them, because that means that now people would have to rewrite huge chunks of code if they wanted to use any of the features added in newer standards. It would also be useful for interfacing with C code, as well as in the case that you would need to do things like optimizations.
| Menchennyy wrote: |
|---|
| For everyone that claims that manual memory management is unacceptably unsafe, with that logic <vector> would be unsafe since it was written using manual memory. |
We aren't claiming that it is unacceptably unsafe, just that it can be (and often is) unsafe. However, it is perfectly fine when it is localised to within an object (assuming its necessary), because it is simply implementation detail which we don't need to know.
For example, with std::vector, we only assume it is using manual memory management - unless we actually go in and look we can't be sure. However, its not relevant, because all we need (and want) to see is the interface and functionality.
For example, with std::vector, we only assume it is using manual memory management - unless we actually go in and look we can't be sure. However, its not relevant, because all we need (and want) to see is the interface and functionality. |
Memory doesn't free itself(although smart pointers may make you think that), otherwise there wouldn't be any memory leaks. Something frees it when it is told to. Garbage collectors and such are coded using manual memory by the devs of the language or library so you don't have to manage it yourself.
...Maybe I'm just meant to be a C programmer instead.
Maybe you just don't know what you're talking about, and should spend some time studying stuff that really smart people all across the industry have been perfecting for more years than you've been able to form words.
RAII is to garbage collection as a Lamborghini is to a go-kart.
RAII is to garbage collection as a Lamborghini is to a go-kart.
A good programmer, regardless of anyone's opinions, is one who can effectively use the tools provided by their language of choice to accomplish their goals. Using tools in language A that originate from language B will cause problems. Replace A and B with C++ and C.
| RAII is to garbage collection as a Lamborghini is to a go-kart. |
I was just using garbage collectors as an example.
If someone would like to enlighten me on how smart pointers delete memory without being coded using manual memory to delete it, I am listening.
A good programmer, regardless of anyone's opinions, is one who can effectively use the tools provided by their language of choice to accomplish their goals. Using tools in language A that originate from language B will cause problems. Replace A and B with C++ and C. |
I agree with the first sentence.
As for the second....tools that wasn't in language A until about 20 years after it was developed and used language B's as it's standard.
I don't consider C++11 and C++98 to be the same language, just as I don't consider Super Mario Galaxy 1 and Super Mario Galaxy 2 to be the same game. When I say C++ I generally mean the most recent standard (which, as of this post, is C++14).
A compiler is free to implement the standard library however it pleases, for the most part. It could implement smart pointers with special instructions when you compile for a special hardware architecture, and never involve raw pointers in the first place.
It doesn't matter how smart pointers are implemented.
| Mechennyy wrote: |
|---|
| If someone would like to enlighten me on how smart pointers delete memory without being coded using manual memory to delete it, I am listening. |
It doesn't matter how smart pointers are implemented.
Last edited on
| Mechennyy wrote: |
|---|
| For everyone that claims that manual memory management is unacceptably unsafe, with that logic <vector> would be unsafe since it was written using manual memory. |
This is a strawman argument. You are misunderstanding the meaning of "manual memory management is unsafe"
Vector is not manual memory management because vector handles the memory management.
The point is... if you were to write your own version of the vector class from scratch with just the bare basic memory allocation/release tools, it would be risky and there would be a high chance of leaks.
The reason vector is safe and your hand-written class isn't is because vector has been run through rigorous amounts of testing to ensure it does not have leaks. Yes, you could run your own class through the same tests in order to ensure its safety, but that's typically not something worth doing, since it's already been done with vector.
Pages: 12