pointer

[hamsterman]

@Moschops, good job trolling me.

@CodeMonkey,

1 2 3 4 5 6 7 8 9 10 11

#include <iostream> int main(){ int i; int* ptr = &i; std::cin >> *ptr; }

000A1000 push ebp 000A1001 mov ebp,esp 000A1003 push ecx 000A1004 mov ecx,dword ptr [__imp_std::cin (0A2048h)] 000A100A lea eax,[i] 000A100D push eax 000A100E call dword ptr [__imp_std::basic_istream<char,std::char_traits<char> >::operator>> (0A2044h)] 000A1014 xor eax,eax 000A1016 mov esp,ebp 000A1018 pop ebp 000A1019 ret

That pointer was optimised away (i.e. no object represents the pointer at run-time), so I don't consider a pointer to be a pointer.

I know am being needlessly harsh, but then this has been a long thread full of silly arguments.

[LB]

Assuming there is no compiler optimization, wouldn't references be implementation defined? EG, they don't *have* to be hidden pointers?

[Moschops]

Assuming there is no compiler optimization, wouldn't references be implementation defined?

The standard deliberately leaves the method of implementation to the implementer.

good job trolling me.

No trolling intended. I genuinely do not consider a reference and a pointer to be the same thing.

[LB]

For reference, I'm with Moschops. He has a good point.

[1vRz3TCk]

I wrote:

...that a compiler doesn't have to provide storage for a reference if it can optimised away

that is more a reference to 8.3.2.3 of the standard 'It is unspecified whether or not a reference requires storage'

[zb0S216C]

I've learnt a few things about references, today:

A reference is an alias for the referent. For instance, the reference R, in the eyes of the symbol table, is the referent. The reference doesn't allocate storage because it's not an actual object (it's never pushed onto the stack), but it's name does exist within the symbol table. The reference is bound to the referent, always.

C++ Standard 8.3.2/4:

"There shall be no references to references, no arrays of references, and no pointers to references." (sic)

When sizeof() is applied to a reference, sizeof() yields the size, in bytes, of the referent.

_Wazzak

[hamsterman]

@CodeMonkey,
You clearly know more about the standard than I. So tell me, does it specify that a pointer must have storage or that a reference can't have any? I can surely give you code examples that show all of the cases. Can you give me an example where a reference does not require storage and an equivalent pointer does?
When used like a reference, pointer is treated like a reference.

@Moschops,
I thought you really were thinking something weird. That, as in your analogy, they're as different as int and float. Now you agree that all references are really pointers, but deny the opposite, which was never even claimed. Maybe except by the OP. But I did mention the obvious difference and I did use all kinds of modifiers to imply a subset relation.

[1vRz3TCk]

Can you give me an example where a reference does not require storage and an equivalent pointer does?

No because I don't see references and pointers as being equivalent.

When used like a reference, pointer is treated like a reference.

0_o

See: What is a reference?
http://www.parashift.com/c++-faq-lite/references.html#faq-8.1

mportant note: Even though a reference is often implemented using an address in the underlying assembly language, please do not think of a reference as a funny looking pointer to an object. A reference is the object. It is not a pointer to the object, nor a copy of the object. It is the object.

[hamsterman]

and an equivalent pointer does?

Here equivalent means "producing the same result". Surely you must agree that "functionality of a reference is a subset of functionality of a pointer", right?

I don't see what 0_o means and I don't see any arguments in that quote at all. I'd be fine with arguments about how considering references magical and not at all pointers could be useful for a programmer (magical because there exists no other low level construct that can be used to implement a reference other than a pointer, in x86 at least), but I'd much prefer ones about how my subset relation is wrong.

[1vRz3TCk]

Surely you must agree that "functionality of a reference is a subset of functionality of a pointer", right?

Have I not made it clear that I do not consider a reference to be a pointer? I come to this from reading Stroustrup, Lippman, the standard, and numerous other sources.

Stroustrup wrote:

More generally, if you want to have both the functionality of pointers and the functionality of references, you need either two different types (as in C++) or two different sets of operations on a single type.

From 'Why does C++ have both pointers and references?' in http://www2.research.att.com/~bs/bs_faq2.html

The reason for the 0_o; the sentence, 'When used like a reference, pointer is treated like a reference' makes little sense to me.

[hamsterman]

"When used like a reference, pointer is treated like a reference" means that you write a piece of code using int& ref and then change the declaration to int* ptr and all other occurrences of ref to (*ptr). Is it really not intuitive?

Okay, let's try to spell it out even further.

Things you can do with a reference:
* initialize to an object
* access and modify an object without using its declared name (this one is a bit hard to write in a way that does not imply pointers. I'll just trust you to understand)

Now, if I were to write a list of things you can do with pointers (I won't), would these two points not be in it? Did I miss anything? This is what "functionality of a reference is a subset of functionality of a pointer" means.

By the way, you still didn't write any arguments. Other people saying what you want is not an argument in it self. In your next post, do try to include the word "because".

[m4ster r0shi]

Here's my contribution to the thread:

FAQ says:

Important note: Even though a reference is often implemented using an address in the underlying assembly language, please do not think of a reference as a funny looking pointer to an object. A reference is the object. It is not a pointer to the object, nor a copy of the object. It is the object.

http://www.parashift.com/c++-faq-lite/references.html#faq-8.1

FQA says:

Strange phrases like "a reference IS the object" are used quite frequently in the C++ community. Such claims are only useful to hide the fact that C++ pointers & references are so similar that having both in the language is an unnecessary complication. In other contexts, the claims are simply false. For example, a wide class of bugs comes from accessing dangling references - references to objects which were already destroyed. If a reference is the object, or just another name for it, how can that happen? Names of destroyed objects are inaccessible - it takes a previously assigned pointer to access a destroyed object (C++ also breaks that rule - you can access a destroyed global object by its name from a destructor of another global object, but that's a different can of worms).

http://www.yosefk.com/c++fqa/ref.html#fqa-8.1

[Moschops]

@ The Hamsterman

Now you agree that all references are really pointers, but deny the opposite, which was never even claimed.

I think you must have misread. I said: "I genuinely do not consider a reference and a pointer to be the same thing."

[1vRz3TCk]

"When used like a reference, pointer is treated like a reference" means that you write a piece of code using int& ref and then change the declaration to int* ptr and all other occurrences of ref to (*ptr). Is it really not intuitive?

Well, changing a reference to a pointer and using the pointer as a pointer is not treating a pointer like a reference. That is why your statement makes little sense to me.

and again I draw your attention to Stroustrup, if you want to have both the functionality of pointers and the functionality of references, you need either two different types (as in C++) or two different sets of operations on a single type., this suggests that the functionality of pointer and references are not the same

access and modify an object without using its declared name

again a reference is an alias (alternative name) that you declare for an object, so you are accessing the object using a declared name for the object.

and of course when you have a parameter for a function that is a pointer it is passed-by-value where as a reference is passed-by-reference. (but this may open a different can of worms)

Ok, so you want a because:
Because you can not do the same to a reference as you can to a pointer, and how they are handled in function calls is different, and the semantics of them is different and so on and so forth...a reference is not a pointer or subset of a pointer.

[Cubbi]

FQA wrote:

the claims are simply false

FQA is a great source of trolling material and a reference of outdated public misconceptions about C++. Please don't take it seriously.

[LB]

Conceptually, pointers and references are different. Usage wise, they share some similar traits. In machine code, they're usually the same, plus or minus optimizations.

There. The end. That is what this whole argument has been about, and these three points I gathered from the varying sides. See? You've been arguing on different grounds and together they all still make sense. So, stop fighting over something that can be looked at three different ways - it usually doesn't work out.

[hamsterman]

@Modshops,

I genuinely do not consider a reference and a pointer to be the same thing

In terms of logic, this denies that IsPointer(X) <=> IsReference(X). (equivalence. I'm hoping you have basics in boolean algebra)
a <=> b means that a -> b and b -> a.

I'm fine with that.

Here you agree that IsReference(X) -> IsPointer(X), so you must have a problem with the other half. IsPointer(X) -> IsReference(X) was never even stated though.

@CodeMonkey,
To treat a pointer like a reference means to restrict yourself to things you could do with references.

For Stroustrup, I'd say the quote is not well picked. Functionality is an ambiguous word. He is more concerned with grammatical structures, rather than what they do.

I'm glad you finally added a because. But then a good argument does require you to elaborate. What is it that you can do to a reference but not to a pointer? How are they handled in function calls and from what perspective?

@LB,
Nope, the problem is deeper. I say that conceptually reference is a safer pointer (even safer than const pointer). Usage wise and in machine code, they share a subset relation. The first could be argued, the rest, hardly.
The interesting part is to see how people classify things. Somehow old thing + new syntax + some restrictions = an entirely new thing.

[Moschops]

old thing + new syntax + some restrictions = an entirely new thing.

Presumably here you mean "old thing" to be a pointer, and "new thing" to be reference. I reject this equation - I do not view a reference to be a pointer with new syntax and extra restrictions. To me (and I suspect many others here) a reference is not a modified pointer, but to you it is.

What is it that you can do to a reference but not to a pointer?

You can use one to extend the lifetime of a temporary object.

[1vRz3TCk]

hamsterman wrote:

For Stroustrup, I'd say the quote is not well picked. Functionality is an ambiguous word.

hamsterman wrote:

Let me paraphrase it the last time: functionality of a reference is a subset of functionality of a pointer.

so what, is it ambiguous when it is used by someone to counter your point?

Functionality is an ambiguous word, really? I think not and it has got bugger all to do with "grammatical structures".


I can't be bothered with this anymore. I you want to see it as some type of pointer go for it. I'm not going to change my view, you aren't going to change yours, and hopefully the OP has enough info to make his own mind up.

[Dacster13]

a wide class of bugs comes from accessing dangling references - references to objects which were already destroyed. If a reference is the object, or just another name for it, how can that happen?

That seems to make a lot of sense to me. Anyway, for me I think I'll have to take hamsterman's side on this topic. As far as I see it, a computer processor only understands machine language. So for me I think it's more important how it's implemented in the end by the computer.

In analogy, lets take a car for example. You may change different things, like having automatic transmission (for ease of use), add seat-belts and air bags (for safety), or change it slightly like right-hand drive, 4WD, etc. Yet despite the small differences it still remains a car because of how it's used in the end. Basically, it just reminds me of the quote "a rose by any other name smells just as sweet". That's just my opinion though, and it's why I'm leaning more toward hamsterman's side. Even if Stroustrup decided to call it differently, change it slightly, and make it a bit safer in the end it's pretty much the same thing.