Hello!
"If you make a pointer parameter instead of a reference parameter, you open up more possibilities for error since now people can pass a null pointer"
On the opposite shouldn't we use pointer so we can ALWAYS
check for invalid input?
with pointer:
void MyFunc(MyClass *c){
assert(c);
//or if(c==NULL){ ...}
}
with reference
void MyFunc(MyClass &c) {
//how can i check reference is valid??
}
Pointers/References
AP: "legal" does not mean "it is not allowed by the compiler". Dividing by zero is just as legal as a null reference, but no compiler will ever solve divide-by-zero problems.
Here, "legal" means that you can only manage to create a null reference through an illegal operation that should not be there in the first place (and it is only fitting that things are only assured to work correctly in a program that does not have other errors around that might compromise their stability). In your case, you have a "dereferencing a null pointer" illegal operation.
Here, "legal" means that you can only manage to create a null reference through an illegal operation that should not be there in the first place (and it is only fitting that things are only assured to work correctly in a program that does not have other errors around that might compromise their stability). In your case, you have a "dereferencing a null pointer" illegal operation.
Second AP:
You can only create an invalid reference from a pointer. If you check the validity of the pointer before creating the reference, then your reference is assured to be valid. Therefore, using references allows you to create a "safe" area where you don't need a pointer check in every function.
(This does not cover cases where the validity of a pointer could not be verified anyway, such as objects being deleted then used, or pointers to junk memory).
You can only create an invalid reference from a pointer. If you check the validity of the pointer before creating the reference, then your reference is assured to be valid. Therefore, using references allows you to create a "safe" area where you don't need a pointer check in every function.
(This does not cover cases where the validity of a pointer could not be verified anyway, such as objects being deleted then used, or pointers to junk memory).
Quote:Original post by ToohrVyk
Second AP:
You can only create an invalid reference from a pointer. If you check the validity of the pointer before creating the reference, then your reference is assured to be valid. Therefore, using references allows you to create a "safe" area where you don't need a pointer check in every function.
(This does not cover cases where the validity of a pointer could not be verified anyway, such as objects being deleted then used, or pointers to junk memory).
You miss the thrust of my argument. Perhaps i should have been clearer. It is not inconceivable that in a program one could have a reference to a dynamically allocated 'data object'. This dynamically object can be deallocated at will. The reference would no longer be valid!
In conclusion, C++ references give the illusion of safety. Under certain conditions, this safety is non-existant.
Pointers and reference as said are the same thing.
The difference is that with references the code is cleaner and it is common that a reference should point to a valid object; although you can hack this behaviour
On the other hand pointers are better when you have to deal with special methods like object.clone() patterns
References are safer because references must be used only as returned/passed parameter and they cannot exist alone.
When you see a pointer returned from a function you should ask: "Should I delete that pointer? And if so, how? The pointer can be NULL?"
With references we have no problem at all!
Conclusion: Use references when you can, and pointers when you have to
The difference is that with references the code is cleaner and it is common that a reference should point to a valid object; although you can hack this behaviour
// crazy code!!!int* p = NULL;pass_an_invalid_reference(*p);On the other hand pointers are better when you have to deal with special methods like object.clone() patterns
References are safer because references must be used only as returned/passed parameter and they cannot exist alone.
When you see a pointer returned from a function you should ask: "Should I delete that pointer? And if so, how? The pointer can be NULL?"
With references we have no problem at all!
Conclusion: Use references when you can, and pointers when you have to
The above agument still stands since a practicing C++ programming could fall into one of these traps.
The first being, reference to a null pointer.
The second, reference to a non-valid area of memory.
The first being, reference to a null pointer.
The second, reference to a non-valid area of memory.
Quote:Original post by ToohrVyk
Second AP:
You can only create an invalid reference from a pointer. If you check the validity of the pointer before creating the reference, then your reference is assured to be valid. Therefore, using references allows you to create a "safe" area where you don't need a pointer check in every function.
(Second AP)
This suppose that you check your pointer BEFORE you call your function
Lets say, for example, you're writing a blackbox (a sound manager)
You should assume that the "user" of your blackbox can
pass anything as an argument (including invalid pointer or reference),no?
And is it not easier to check with pointer that reference??
thx for your response.
Sorry, I had misunderstood your point. You are indeed right that, in a program where you dereference null pointers, references are not any more safe than pointers, and actually, they are even less safe since you cannot check their value.
However, your first argument does not hold at all in a program where no null pointers are (edit: meant to be) dereferenced, which is, i'm sure, the case for the majority of programs in the world. And in those cases, I fail to see how you could hope to create a case where pointers would be safer than references.
EDIT: if you REALLY want to be able to solve anything your user might do, how do you prevent the user from accidentally going past the bounds of a buffer, overwriting your internal memory and causing your black box to crash? The fool-proof-ness of a black box should not be pushed beyond the simple contract of not causing problems when used in conjunction with legal code.
As for your second argument, neither pointers nor references can keep you safe from accidental deletion of the pointed-to/referenced object. If you wish this kind of additional safety, look into boost::shared_ptr.
Base line:
+ references are assured, in a correct program, to point to an object (except cases where neither references nor pointers could be)
- references can not represent a "no object" value
+ pointers can represent a "no object" value
- you need to manually check whether a pointer points to something, or is in a "no object" state
[Edited by - ToohrVyk on January 16, 2005 9:43:50 AM]
However, your first argument does not hold at all in a program where no null pointers are (edit: meant to be) dereferenced, which is, i'm sure, the case for the majority of programs in the world. And in those cases, I fail to see how you could hope to create a case where pointers would be safer than references.
EDIT: if you REALLY want to be able to solve anything your user might do, how do you prevent the user from accidentally going past the bounds of a buffer, overwriting your internal memory and causing your black box to crash? The fool-proof-ness of a black box should not be pushed beyond the simple contract of not causing problems when used in conjunction with legal code.
As for your second argument, neither pointers nor references can keep you safe from accidental deletion of the pointed-to/referenced object. If you wish this kind of additional safety, look into boost::shared_ptr.
Base line:
+ references are assured, in a correct program, to point to an object (except cases where neither references nor pointers could be)
- references can not represent a "no object" value
+ pointers can represent a "no object" value
- you need to manually check whether a pointer points to something, or is in a "no object" state
[Edited by - ToohrVyk on January 16, 2005 9:43:50 AM]
It is not possible to have a null reference. The only possible way to get something that seems to be a null reference is to dereference a null pointer. Dereferencing a null pointer is undefined behaviour.
Null References.
Enigma
Null References.
Enigma
Quote:Original post by ToohrVyk
Sorry, I had misunderstood your point. You are indeed right that, in a program where you dereference null pointers, references are not any more safe than pointers, and actually, they are even less safe since you cannot check their value.
However, your first argument does not hold at all in a program where no null pointers are dereferenced, which is, i'm sure, the case for the majority of programs in the world. And in those cases, I fail to see how you could hope to create a case where pointers would be safer than references.
i'm suggesting that pointers are safer than references. I'm suggesting that references are not as safe as some people on this forum seem to think.
Problems of derefencing null pointers DO exist in programs during the development/testing and debugging stage. In non-trivial applications, references are not 'bullet proof'.
How this fits into the thread discussion of whether one should prefer pointers to references when passing parameters I'm not sure. I personally would use references when there is a good reason to do so and use pointers where I have to.
Oh by the way, there are at least 2 anonymous posters on this thread!
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
