Sign in to follow this  
barakat

***** OR &&&&

Recommended Posts

Which is better ? if we have a method in an object called writeToFile() to make it
void writeToFile(ofstream * foutPtr );
void writeToFile(ofstream & foutRef );

which is more effeicient ?[embarrass]

Share this post


Link to post
Share on other sites
Neither. They're both the exact same thing, internally. Just different syntax used.

Heck, I wouldn't be suprised if this worked on many compilers:

void writeToFile( ofstream & foutRef )
{
//...
}

void (*pointerToFunc)( ofstream * ) = ((void (*)( ofstream * )) writeToFile;

//...

writeToFile ( ofs );
pointerToFunc ( & ofs );

Share this post


Link to post
Share on other sites
They'll be the same thing on any compiler I know because when you pass a reference, under the hood it's passing a pointer. You simply don't need to dereference it before you access it.

References are conceptually different than pointers. Passing a reference actually handing the caller the object. You're not passing a pointer or a copy. You're passing the actual object. Any changes you make to the object will be observed by the caller... Of course on any system I've ever heard of, the way to pass the actual object is to pass it's address. Just remember that a reference is not a pointer. It is the object.

Share this post


Link to post
Share on other sites
You're not going to see any sort of difference. References let you use the familiar dot notation for accessing members and also imply that the object probably isn't null (or at least, users aren't tempted to call delete on it).

And what is with all the nano-optimization posts today?

Share this post


Link to post
Share on other sites
Quote:
Original post by MaulingMonkey
Neither. They're both the exact same thing, internally. Just different syntax used.

Heck, I wouldn't be suprised if this worked on many compilers:

*** Source Snippet Removed ***


I'm not going to try it, but it shouldn't work. Every time the compiler accesses a reference it should always dereference before any casts are applied. So you will end up trying to make a pointer of first sizeof(ofstream*) bytes actual data within the object, which the compiler shouldn't let you do.

Share this post


Link to post
Share on other sites
Well I did try it, and although I certainly don't recommend doing this in any shape or form it seems to work fine under both BCB and GCC. I even tried passing a derived class by pointer/reference to base and calling a virtual method and it worked fine.

Enigma

Share this post


Link to post
Share on other sites
One of the main differences between pointers and references is that references are GUARANTEED to refer to some object. Pointers can be NULL, and often a lot of code is wasted checking to see if they are NULL, and if so, returning an error code or something. The compiler will not allow you to initialize a reference to NULL, nor will it allow you to not initialize a reference. When declaring a reference, you MUST assign it an object to refer to. Similarly, you cannot pass NULL as an argument to a function that takes a reference. References also cannot be reassigned to bind to another object. If you do something like:

int a = 2, b = 3;
int & c = a; // Make c refer to a
c = b; // Equivalent to "a = b;" since c refers to a. This does NOT rebind c to b
cout << a << ' ' << b << ' ' << c << endl; // Prints "3 3 3"

Share this post


Link to post
Share on other sites
IIRC, it is possible to create a 'null' reference, but the result is undefined. It just isn't done under normal circumstances. I don't remember the construct that does it, but it's something like int &i = *(int*)0; or something like that.

Also, null pointers can be handy, when you have a value that may or may not point to something. If it should always point to something, then you probably want references, but if it may point to nothing, then a pointer is the only option.

Share this post


Link to post
Share on other sites
Quote:
Original post by smr
Quote:
Original post by MaulingMonkey
Neither. They're both the exact same thing, internally. Just different syntax used.

Heck, I wouldn't be suprised if this worked on many compilers:

*** Source Snippet Removed ***


I'm not going to try it, but it shouldn't work. Every time the compiler accesses a reference it should always dereference before any casts are applied. So you will end up trying to make a pointer of first sizeof(ofstream*) bytes actual data within the object, which the compiler shouldn't let you do.


I'm not following what you're saying. But the fact of the matter is that the function does NOT take the object by value - it is a REFERENCE! Since this is not the actual data - just an under the hood pointer - there is no data truncation occuring here.

Quote:
Well I did try it, and although I certainly don't recommend doing this in any shape or form it seems to work fine under both BCB and GCC. I even tried passing a derived class by pointer/reference to base and calling a virtual method and it worked fine.

Enigma


Scary.

Quote:
IIRC, it is possible to create a 'null' reference, but the result is undefined.


Correct. And we all know, undefined is programmer-speak for "STEP AWAY FROM THE BUTTON BEFORE YOU RELEASE THE HOARDS OF GIANT BLUE MONKEYS!!!".

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
A reference gives the compiler slightly more opportunity for optimization than a non-const pointer, since it knows that a reference cannot be reassigned to refer to a different object. A const pointer (not to be confused with a pointer to const data) gives performance equivalent to a reference in all cases.

Regards,

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this