Do you believe smart pointers teach bad habits

Pages: 12
It's not safe to use a saw-blade by hand. It's perfectly safe to push a button on a machine that uses a saw-blade inside a protected box that you can't access.
It appears I am outnumbered in this debate.
I yield I yield.
Rereading, I admit my response was not nice.

But you should yield, 'cause you're wrong. There is no reason someone must learn C before learning C++. Sorry.

Please don't stop paying on the forums because I (or anyone else) was unkind.

But you should yield, 'cause you're wrong.

Please don't stop paying on the forums because I (or anyone else) was unkind.

I'm not retreating, just advancing in the opposite direction.


There is no reason someone must learn C before learning C++.

I wouldn't exactly call manual memory C . It's essentially in every programming language one way or another. Whether the programmers are doing it or it's running in the background via garbage collection, smart pointers, ect. It is widely considered a C++ feature by many people that use languages like Java and C# simply because it's one of the few languages that let you manually manage memory.

Oh, I'm late to the punch, but...

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've worked in large projects (150-200 million lines of code lately). Assuming by "traditional" you mean plain new/delete, I don't remember touching those in production code since at least 2005. Last job, I didn't even use the system heap (there were special heaps and pools and arenas) so if I wanted to use new it wouldn't do me any good.

Personal anecdotes aside, smart pointers were commonplace by 1992 and allocator-aware containers really hit the scene in 1994, still years before C++ was even standardized, so I don't even see where the supposed "tradition" comes from. Schools? They don't teach practical programming.

One thing you're right about though, it's very good to know about the underlying mechanics, but for actual use it's a lot better to also know about RAII and allocators.

I don't even see where the supposed "tradition" comes from. Schools? They don't teach practical programming.


Whether it's considered practical or even "real C++" or not, it's what was mostly used.


Oh, I'm late to the punch,


Hey man don't worry about it, round 2 will start tomorrow(Even if it will just be an infinite regression because none of use will agree with the other).

I'm off to sleep, You guys have a good night.
Even if you would use raw memory, you will have to use RAII. So why not resort to already tested, well known form of RAII container called smar pointer.

Homework: tell why this code snippet is extremely dangerous and can lead to memory leak.
1
2
3
4
5
6
7
template<typename T, std::size_t N>
//...
T* array = new T[N];
//fill array
std::string result = serialize(array, N);
delete[] array;
//... 
Mechennyy wrote:
it's what was mostly used

That's the premise I am questioning. It was mostly taught, I agree, but I don't agree that it was mostly used.

Granted there probably is a survivorship bias (which only strengthens my point), but the commercial codebases I've seen, all used smart pointers in the C++ code written back in early 90s.
dhayden wrote:
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.

A craftsman should definitely know his trade inside and out. It is embarrassing to listen:
Q: "How did you do foo?"
A: "I did press this button."
Q: "Why?"
A: "It was there and I was told that pressing it gets foo done."

However, I don't think that classes reinvent wheel infinitely for the purpose of teaching a language. No, the main goal seems to be to make the student think. One could do that with any language, even pseudo. A real language has the convenience (for the teacher) that it can enforce some syntax. Furthermore, renewing assignments appears like fixing what ain't broken; extra work for the teacher. It is surprisingly easy to be stuck in bad practises, particularly when they appear to "work".

In short, those classes do not really teach the language, they use some facilities of some languages in order to teach something programming-related.


Should one always use a chainsaw without turning it on simply because one might one day run out of fuel and learning to saw with powerless chainsaw is difficult, particularly in acute need?

No. Use the smart pointers. You have to know them in order to use them well. That is not a bad habit; it is a different habit than what MiiNiPaa's homework requires.
Alright, I yield once again. I'm done with this debate and C++.
I will reply to the last 3 posts though.

Homework: tell why this code snippet is extremely dangerous and can lead to memory leak.

I don't know templates so I'm not sure if they would make a difference or not, but the new and delete statements look alright(once again, not sure if templates would change them). Could be out of scope, but can't tell without a full program. Would also have to see the serialize function.

That's the premise I am questioning. It was mostly taught, I agree, but I don't agree that it was mostly used.

Granted there probably is a survivorship bias (which only strengthens my point), but the commercial codebases I've seen, all used smart pointers in the C++ code written back in early 90s.

You may be correct, but the codebases I've seen commercial or otherwise do not.

No, the main goal seems to be to make the student think.

I like to believe that manually managing memory yourself requires more thinking than having someone else(whoever created the smart pointers) do it for you.
The kicker is exception handling. Manual memory management is only viable in a language without exception handling.
but the new and delete statements look alright
At least std:string constructor can throw an exception. And maybe serialize function and filling array might too. What happens to memory then? Will delete be called? The answer is: no, delete will not be called and memory will leak. To avoid that we need to make RAII container:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
template <typename T>
class RAIIarray
{
    T* arr;
public:
    RAIIarray(std::size_t num) : arr(new T[num]) {}
    ~RAIIarray() {delete[] arr;}
    //Basic array operations
    T& operator[](std::size_t index) {return arr[index];}
};
//usage
RAIIarray<int> foo(N);
foo[5] = 6;
//... 
Wait, this looks familiar. How about:
1
2
std::vector<int> foo(N);
foo[5] = 6;
Or std::array<int, N> foo; or std::unique_ptr<int[]> foo(new int[n])? (There is no make_unique or arrays, but it is easier to implement than custom array class). They do the same thing you spent some time creating and even more! They are part of standard library and every programmer would understand what happening without having to look up RAIIarray class documentation. Additionally they are already tested and there won't be strange bugs.
Last edited on
Topic archived. No new replies allowed.
Pages: 12