pointers--when to use them

[nuzzle]

The example was just to show that the generalized statement made as in:
was not completely true. This was just to show that a reference could be linked to an object on the heap until anytime upto the end of the object's lifetime. Return of new was not what the example was just limited to illustrate. Plus I think you missed the rest of the statements I made there in where I mentioned about possibility of null references and the way you could have nothrow version of new be able to cope up with the syntax and hence leading to a possibility that new could well have been returning a reference. But I guess if you can skip all that context, it might as well sound like a Hopeless Nerd. Thanks for the comment.

To put in a personal reflection.

My reply in #6 was an attempt to give the broad view, to see the forrest and not the individual trees. And I think it was very good actually.

Then in comes you. The nerd, incapable of taking the broader view of things.

I tell you this. Do you have a better overview than I gave in my reply #6? Then post it! On the other hand if you want to discuss "the individual trees" then put in your claims and I'll reply. And you'll be surprised, the topic of pointers in C++ is wider than you've ever imagined.

[Lindley]

So you don't think that one of the most important uses of pointers in C++ is to point to allocated memory on the heap?

Then why is every known way to get at memory on the heap returning a pointer?

Well, putting aside the fact that this is an artifact left over from C for better or for worse, the vast majority of code should not *care* whether the objects it's operating on live on the stack or the heap.

So the only place the origin of the object matters is on the level where it is created. On that level (and anywhere 'ownership' of the object may have meaning), sure, putting heap objects into a smart pointer makes much more sense than putting them into a reference.

Everywhere else, the driving concerns should be
1) Is NULL a valid value for the thing or not
2) Which produces cleaner-looking code.

There are other considerations, but those are the ones most often directly relevant.

[nuzzle]

Well, putting aside the fact that this is an artifact left over from C for better or for worse, the vast majority of code should not *care* whether the objects it's operating on live on the stack or the heap.

So the only place the origin of the object matters is on the level where it is created. On that level (and anywhere 'ownership' of the object may have meaning), sure, putting heap objects into a smart pointer makes much more sense than putting them into a reference.

Everywhere else, the driving concerns should be
1) Is NULL a valid value for the thing or not
2) Which produces cleaner-looking code.

There are other considerations, but those are the ones most often directly relevant.

What did you say and how does it contribute to this thread?

[Lindley]

Hey, you're the one pretending you know better than everyone. One bad example was posted, true, but pointing that out was all that was necessary.

[nuzzle]

Hey, you're the one throwing names around and pretending you know better than everyone. I'm just here to help.

There's more than enough nonsense posted around these parts from time to time without jumping on the backs of those who are more or less right, that's all.

So you think you're right without saying?

I don't buy that.

You have to promote your arguments like anybody else.

[Lindley]

Oh, hell no. I'm wrong all the time. I welcome such instances, since it gives me an opportunity to learn some better techniques and strategies.

Over-use of pointers was one of the ways I used to be wrong. Since I started using references more (together with a heavier emphasis on STL constructs), my code has become much safer, cleaner, and more readable. It's still evolving, of course. There are always opportunities for style improvement.

My point above was simply: Using a (smart) pointer to own an object on the heap is wise. But there's absolutely no reason to prefer pointers over references just because the object in question came from the heap, so long as the pointer (or reference) in question isn't expected to represent ownership of the object.

[nuzzle]

Oh, hell no. I'm wrong all the time. I welcome such instances, since it gives me an opportunity to learn some better techniques and strategies.

Over-use of pointers was one of the ways I used to be wrong. Since I started using references more (together with a heavier emphasis on STL constructs), my code has become much safer, cleaner, and more readable. It's still evolving, of course. There are always opportunities for style improvement.

My point above was simply: Using a (smart) pointer to own an object on the heap is wise. But there's absolutely no reason to prefer pointers over references just because the object in question came from the heap, so long as the pointer (or reference) in question isn't expected to represent ownership of the object.

I know. You think you're the greatest but that's not what we're discussing.

Look at my reply #6. Then tell me what you think.

[Lindley]

Okay.

There are many algorithms, data structures and language mechanisms you simply cannot implement efficiently without the use of pointers.

Assuming you're working from scratch, yes. If you leverage the STL you can create lots of data structures and run lots of algorithms without resorting to pointers. Of course, they probably use pointers internally, but from my view that's beside the point---you should never care about details past an interface when coding.

One important example is recursive data structures such as lists and trees.

I would say those are the poster child for pointer usefulness, assuming again you're talking about starting out at the C level and coding from there.

Another is parameter passing in functions.

I'd actually say that using a pointer for an out parameter without a good reason (and there are a few) is actually a sign of someone too steeped in the C mindset. A good C++ coder should choose references or pointers for parameter passing depending on the rules I posted in #32, barring a good argument otherwise.

The two most important uses of pointers are,

- to avoid extensive shuffling of data back and forth in memory, and

Certainly when dealing with heavyweight objects, moving pointers to them is a lot better than moving the entire object. No argument there. There are various ways this could be done without explicitly requiring the use of pointers, such as shuffling an index array, but that's largely a matter of semantics.

- to refer to memory allocated on the heap.

That's what the central issue is, isn't it? My argument is that yes, pointers are better for referring to something on the heap.....when you know where it is. And the amount of code that cares about where the object is should be as small as possible. Again, details past an interface shouldn't matter, so wrap up the messy details in as tight an interface as possible so you can present a clean face to the world.

exterminator's point was an extreme example of that---too extreme. But what he was getting at is correct; that you can (and should!) treat heap-allocated and stack-allocated objects as identically as possible whenever you can; and that includes referring to them via references sometimes.

A different question is whether pointers must be an explicit feature of a programming language? Not necessarily. In C++ it is but in Java it is not.

Personally, I feel that a difference which makes no difference is no difference. Java may not have something called a pointer exactly, but their references do the same exact things for the most part.

I know. You think you're the greatest but that's not what we're discussing.

I think I'm still exploring the solution space with a high temperature. I haven't gotten so far along in the simulated annealing process to suspect myself of nearing a global optimum yet.