Back to General and Gameplay Programming

Why do I never see pointers being passed by constant reference?

General and Gameplay Programming Programming

Started by Nemesis2k2 July 15, 2005 07:32 PM

35 comments, last by Oxyacetylene 18 years, 9 months ago

Deyja

920

July 16, 2005 09:03 PM

Quote:where "doing it right" is more important to me than how long it takes.

You can spend a hundred years making the perfect do-do trap, and you still aren't gonna need it. I call this additional principal Ysag Ni.

Furthermore; you're all quite loony. Heres how this conversation should have gone down:

OP: "Sending pointers by reference is faster"

First reply: "Sending a pointer by reference just makes an extra indirection because you have to dereference the reference then dereference the pointer"

OP: [rant]

And then we could all ignore him. When you lay knowledge before an ignorant person, you do yourself no favor by trying to force them to pick it up.

On another topic;

Quote:A bright-eyed, promising young C++ recruit learns that postincrementing a non-POD type like an iterator could create a temporary copy, and goes around religiously replacing all postincrements with preincrements.

Going back and retrofitting something so trivial is certainly a waste of time, but learning the difference between pre and post increment and getting into the habit of preffering pre increment certainly won't hurt. Also the comment serves no purpose and should certainly be eradicated with extreme prejudice.

http://jemgine.omnisu.com

BriTeg

168

July 16, 2005 09:19 PM

I personally thought this was generally a very good thread, except for the heat towards the end. Thinking the original issue through in detail and better understanding what's going on was good for many people, myself included, I'll wager.

Brianmiserere nostri Domine miserere nostri

Oxyacetylene

426

July 16, 2005 09:24 PM

Quote:Original post by Deyja
you're all quite loony. Heres how this conversation should have gone down:

OP: "Sending pointers by reference is faster"

First reply: "Sending a pointer by reference just makes an extra indirection because you have to dereference the reference then dereference the pointer"

OP: [rant]

And then we could all ignore him. When you lay knowledge before an ignorant person, you do yourself no favor by trying to force them to pick it up.

This thread is now about how an array is the same thing as a pointer.

char firstArray[250];

char secondArray[250];

//This will work because an array is the exact same thing as a pointer
secondArray = &firstArray

//Oh no, wait, it didn't... but an array is still a pointer OK

Deyja

920

July 16, 2005 10:01 PM

Quote:Oh no, wait, it didn't... but an array is still a pointer OK

It sure is a pointer. Specifically, it's a const pointer. Meaning you can't change where it points, which is why your attempt to prove that arrays aren't pointers fails, and why you thought you were correct!
It also fails because you are trying to set it to a pointer to a char pointer, instead of to a char pointer, which wouldn't have worked even if the destination wasn't also const. I assumed you meant 'secondArray = firstArray;' or possibly 'secondArray = &firstArray[0];' instead of 'secondArray = &firstArray'. Note the subtle difference.

Also; here is a working example which proves that arrays are pointers:

void AcceptsIntPointer(int* const the_int) {/* do stuff */}void foo(){   int an_array[100];   AcceptsIntPointer(an_array);}

[edit] Sorry - accidentally made the_int a pointer to constant int instead of a constant pointer to int.

[Edited by - Deyja on July 16, 2005 10:01:36 PM]

http://jemgine.omnisu.com

SiCrane

11,840

July 17, 2005 07:55 AM

An array is not a pointer in C++. An array has a unique type that has an implicit decay to a pointer type. The type of char firstArray[250] is char [250] that has an implicit decay to char *, however it is not a char *. This functions much the same way that a short has an implicit conversion to a long. This includes the rvalue temporary construction when bound to a const reference of a type not equal to its own.

If an array was a pointer something like this would compile:

  int array[5][5];  int ** ptr = array;

However it doesn't. The associated pointer type with the type of an int[5][5] is int (*)[5].

mcfly

151

July 17, 2005 08:18 AM

Quote:Original post by Deyja
It sure is a pointer. Specifically, it's a const pointer.
Also; here is a working example which proves that arrays are pointers:

*** Source Snippet Removed ***

And here's an example which proves they're not:

template<typename Object,size_t N>void AcceptsIntPointer(Object (&object)[N]){// do stuff with ARRAY}template<typename Object>void AcceptsIntPointer(Object& object) {// do stuff with POINTER}void foo(){    int an_array[100];    AcceptsIntPointer(an_array);}

Oxyacetylene

426

July 17, 2005 01:57 PM

Hahaha, sorry guys, I didn't think anyone would actually take the bait on that one! :) I came home from the pub a bit drunk, and thought it would be the height of comedy to post that.

Quote:
I assumed you meant 'secondArray = firstArray;'

Yes, sorry that's the one I meant.

Anyway, I'd say an array isn't a pointer. I could be wrong here, but I was under the impression that an array on the stack is just the same as any other variable on the stack, except that there's more than one of them. Surely if an array is a pointer, then so is any other variable on the stack? Just because using the name of the array without an array index acts like a pointer, doesn't mean the array itself is a pointer.

Besides which, to be really pedantic, an array and a pointer are two different concepts entirely, regardless of how an array is implemented on a low level.

Anyway, sorry for bumping this thread again, I just had to get my tuppence worth in.

Why do I never see pointers being passed by constant reference?

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Why do I never see pointers being passed by constant reference?

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Reticulating splines