Comment by dools | Hacker News Reader

Comment by dools | Hacker News Reader

I'm not sure I agree entirely with this explanation. He emphasises that this is unsafe behaviour that is protected against in safer languages - I've never heard it said that the use of pointers should be considered unsafe and there are also pointers in other languages that exclude things like multiple-inheritance and have garbage collection (which could be considered safer languages).

I like the room key analogy (almost) but I don't think it needs to be stolen and I don't think all the talk about policies and contracts is necessary at all.

It could simply say the thing you're returning is not the local variable. It is a pointer.

I have a box and instead of giving you the box I give you a key to the box. Anytime you want to use the contents of the box you must come over to the box and open it, but you can't take the box with you. If you want to put something in the box you just walk over and put it in - but here's the rub: you have no guarantees that you're the only one with a key. I could give out the key to a bunch of people so you don't know what will be in the box and who owns it.

Use with caution!

I think he means that pointers are unsafe in the same way that dynamite is unsafe. They both have legitimate uses, but you need to be very careful when you are using them. (Rather than unsafe in the sense of don't use them at all).

I like your box analogy, but I don't think it goes far enough - with C++ pointers it is not always ok to put something in the box. If the pointer is out of date or invalid there is a chance that writing to it will make the OS kill the entire process.

Languages with garbage collection don't tend to have that kind of problem, since whatever is at the memory location will stay at that location until everyone surrenders their pointers.

I agree with you for the most part. C/C++ lets you do what you want, presumably because you know what you're doing. But I don't agree that pointers are evil, and should be avoided. If you want to do any practical programming with C/C++ at all, you have to learn how to dynamically allocate memory and use pointers. Generally, pointers work as advertised. It's the cases where they work when they shouldn't that is the problem. In these cases a compiler usually warns you, so you are still covered. So in C/C++, just because it works, doesn't mean your code is right.

> C/C++ lets you do what you want, presumably because you know what you're doing.

Frankly, C++ is kinda schizophrenic about it. First, it is really anal about class membership, to the extent they had to introduce friend qualifier to get around its impracticality. And then you get this.

But I don't agree that pointers are evil, and should be avoided.

No one is saying that at all. Pointers aren't evil, but they are dangerous.

Perhaps a better analogy is a sharp chef's knife. In the right hands it's an effective and efficient tool that lets you do things quicker and just as safely as any other tool.

In the wrong hands it is dangerous to the person using it and to those around them.

There are numerous other examples: welding torches, motorbikes, explosives etc etc.

Exactly. I didn't mean to imply that pointers are evil or should be avoided. That was supposed to be the point of my dynamite analogy, but I guess the comment made elsewhere on this topic about the inadequacies of analogies holds true here.

So, for the avoidance of doubt, I believe: pointers are awesome, powerful tools and you can do some great things in C/C++ using them and I sometimes miss them (a little bit) when using other languages. But you can also do some terrible things with them - and I have done some spectacularly bad things with them in the past. But that doesn't mean they are bad - it just means that I am reckless.

^ Ditto. I thought pointers were being shown in a negative light at first, but now I see the point. In my opinion too, manual memory management is a very important part of developing highly scalable applications, but should only be done if absolutely needed - which is fortunately rarely the case nowadays as most people just develop for the Web, and can afford to throw money at the problem. But for embedded systems where resources are limited and inputs are very limited, it is still very useful. In the early years, it was C + inline assembly for further optimization - where you try your best to avoid assembly. I guess now, it's a dynamic/interpreted language, plus C/C++ for further optimization, and avoid C/C++ like the plague as much as possible.

"I've never heard it said that the use of pointers should be considered unsafe..."

Please pardon the bluntness, but that sounds like a fundamental failing of whomever you've been learning. Use of pointers in the C family of languages is unsafe. That's "unsafe" in the context of computer languages.

As for the analogy, the talk about policies and contracts is important. There's nothing in the hotel preventing you from using the key to gain unauthorized access to the room just like there's nothing in C++ to prevent you access memory you have no business trying to access.

Reply on news.ycombinator.com