@JvdL said:
@asuffield said:You don't have what it takes to be a software developer.
@Mikademus said:You just seem like an ass with anger issues [...] Ass-u-field
@bstorer said:Your recent MO of posting smug invectives seems misguided at best.
@fist-poster said:You don't understand references [...] You've degenerated into less than a troll
This starts to look like a pissing contest.
To Mikademus, bstorer, fist-poster:
Asuffield is right: references are not safer than pointers and are primarily syntactic sugar that sometimes (operator overloading) makes your code easier to read, but often merely obfuscates it. Compilers will only protect from blatant typos, if at all. If you don't believe him or me, read second opinions by Bjaerne Stroustrup or Dan Saks.
Don't try to beat asuffield on his home ground: he knows more about this stuff than all of us put together.
To asuffield:
You'll stand a better chance that people will listen to you if you wouldn't start your rethoric with insults.
From Stroustrup's page that was linked:
If passing ``not an object'' (e.g. a null pointer) is acceptable, using a pointer makes sense. My personal style is to use a pointer when I want to modify an object because in some contexts that makes it easier to spot that a modification is possible.
I've bolded the relevant portion. The implication is that in all other situations using a pointer does *not* make sense, or equivalently: If passing "not an object" (e.g. a null pointer) is *NOT* acceptable, using a reference makes sense.
That's because a reference *must* refer to an object. Yes you can go out of your way to make that object invalid, but there is little a programming language can do to prevent willful stupidity. So instead the focus is on preventing accidental errors, something which references do quite admirably.