pointer

In analogy, lets take a car for example.

Oh God, save us from clumsy analogies. I can use the same analogy to state that a float is the same as a char.

Last edited on

Oh God, save us from clumsy analogies.

Please, the profanity isn't really necessary. I was merely stating my opinion which I am entitled to, and I'm not forcing my views on anyone else. I'm simply explaining why I'm leaning toward hamsterman's side on the topic.

I can use the same analogy to state that a float is the same as a char.

I agree, I think you're correct with that as well. In the end, there are no data types really, it's merely how we want the processor to interpret our 1's and 0's.

closed account (1vRz3TCk)

Dacster13 wrote:
So for me I think it's more important how it's implemented in the end ... Yet despite the small differences it still remains a car because of how it's used in the end.

Wow, is how it is implemented or how it is used that is important?

Cubbi (4774)

Dacster13 wrote:
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.

Taking this analogy, if the car is a pointer, the reference is the driver. A car may hold a driver or may be empty. The driver can be accessed whenever necessary. The driver may be replaced. Cars can do some things drivers can't, drivers can do some things cars can't. Putting a car on a highway without a driver inside is unsafe.

pointers are not in any fashion "improved references". Pointers are and have always been objects that may or may not hold references.

To quote C (not C++), §6.2.5/20

A pointer type describes an object whose value provides a reference to an entity of the referenced type.

Last edited on

The car is an operating system, and the gearbox is the RAM. No, wait, the brakes are the RAM. Or was it the transmisison fluid? Anyway, when the user operates the keyboard, which is the windshield wipers, they cause some fuel to move, which is the int values. The float values are like the fuzzy-dice hanging off the mirror and the mirror, of course, is a pointer because you can move it to see other things.

Wow, is how it is implemented or how it is used that is important?

implemented by the compiler, used by the computer.

I don't think that a reference can be compared to a driver to be honest. I think if a car is a pointer, then you can compare a reference to a car with a driver.

To break it down:

like having automatic transmission (for ease of use)

1
2
3

int a = 10;
int &x = a;
cout << x;

easier to use because there's no need to dereference compared to:

1
2
3

int a = 10;
int *x = &a;
cout << *x;

add seat-belts and air bags (for safety)

int& x; // safer, because the compiler will not allow this

compared to

int *x; // not safe

so basically if the car is the pointer, the value inside the car is what can be the driver. So a reference wouldn't be the driver, it would be a car assured to have a driver in it in my opinion.

Also, like I said what m4ster r0shi, posted seems very logical and reasonable.

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?

Honestly, I'm very open-minded and I'm not closed to the idea that I may be wrong on siding with hamsterman. However, I do try to base my judgement on facts presented. The quote above is very convincing to me though, and no one has seemed to answer it yet. If someone can explain it then I would be satisfied. I'm merely finding this topic very interesting and educative, because it's quite rare to see the different opinions of experienced programmers. I admit that I don't know everything, but that's why I find this highly interesting. And if I learn something new I always see that as a good thing.

Edit:

The car is an operating system, and the gearbox is the RAM. No, wait, the brakes are the RAM. Or was it the transmisison fluid? Anyway, when the user operates the keyboard, which is the windshield wipers, they cause some fuel to move, which is the int values. The float values are like the fuzzy-dice hanging off the mirror and the mirror, of course, is a pointer because you can move it to see other things.

Why try to mock others simply because they have different views from you? I think that is quite inappropriate. I believe no one is 100% correct in their opinions and neither are you. Discussion is important for improving and learning though. That said, I see the sarcasm, and trying to shut up people who have different opinions to yours as something a child would do, and it doesn't really help with learning.

Last edited on

@CodeMonkey,
Functionality means how you can use a thing. To be able to neatly use overloaded operators and to get safer indirection are two uses of references. They can both be called functionality. They have nothing to do with each other.

@Moschops,

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

I'd like to see an example of this.

@Cubbi,
So reference is the concept of indirection, and pointer is a container of references? Then in terms of Haskell, type Pointer = Maybe Reference ? But aren't you abusing the fact that the word reference was used plenty before C++ reference types. That in itself does not make them the same thing..

Cubbi (4774)

hamsterman wrote:
But aren't you abusing the fact that the word reference was used plenty before C++ reference types.

Slightly, because I'm trying to avoid bringing in additional terminology. To be more precise, I was saying that C's concept of "lvalue" ("refers to" is precise terminology for C and C++ lvalues) is what's most closely related to the C++ concept of "reference type". C++ turned C's "dereferenced pointer" lvalues into first-class citizens in its type system (with a curious exception of dereferenced pointers to member functions)

Cubbi (4774)

Since people keep repeating this passage from the FQA, let me debunk a bit

FQA wrote:
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?

It's hard to make sense of this, given loose wording, but I *think* the first sentence meant to say: "undefined behavior occurs when accessing dangling references - references to objects whose lifetime has ended." This is only partially true (like most premises in FQA): there are both well-defined and undefined operations on such references (technically, on the lvalues such references evaluate to: §3.8[basic.life]/6-7).

The second sentence seems to imply that the potential problems mentioned in the previous sentence somehow wouldn't apply if the object's original name was used to access it after its lifetime has ended. That is simply false, the behavior is indistinguishable from accessing by reference.

@Cubbi thanks for the explanation, I'm actually trying my best to be very subjective and non-biased, because to me both sides seem to have very good and valid points. That's why I said I was leaning toward hamsterman's theory more (never said I believed it's 100% the truth) because that question about dangling references went unanswered and no one seems to have been addressing it. Basically I've read through all the posts, and I try to analyze and ask myself questions after every explanation. Like is that possible? Then try to see if the different cases support both the theories presented.

For me I'm just trying to prove it to myself, and I'm not trying to prove anyone wrong at all. Also, I don't believe that if a lot more people believe in certain things that those ideas are automatically correct. The chinese proverb "what is popular is not always right" is what makes me believe it's not merely a popularity contest. For example, in the time of Galileo most believed the Earth was the center of the universe but it didn't make them right. So, if a theory fails in even a single case then how can I believe it to be true? It would just make me feel like I'm lying to myself if I did.

Anyway, back on topic, your answer made me think of another question.

I believe, what it's trying to say is basically if a reference is indeed the object then once the object gets destroyed the reference should also be destroyed, if it is indeed the same object. So because of that case, the theory "the reference is an object" seem somewhat shaky in my opinion.

Secondly, I think you are saying that accessing a dangling reference leads to partial undefined behavior if I'm not mistaken? Doesn't that seem similar to dangling pointers too? Here's what wikipedia says about dangling pointers.

Dangling pointers arise when an object is deleted or deallocated, without modifying the value of the pointer, so that the pointer still points to the memory location of the deallocated memory. As the system may reallocate the previously freed memory to another process, if the original program then dereferences the (now) dangling pointer, unpredictable behavior may result, as the memory may now contain completely different data.

It seems very similar to dangling references I mean. And as hamsterman's theory goes "references are just hidden pointers".

Is it possible that if it is a hidden pointer like hamsterman says it is, that this could very well be the same reason for the undefined behavior when trying to access a dangling reference, and the partial well-defined behavior is just something the compiler adds to make it somewhat safer similar to Java in a sense? Or is there something I'm missing or completely wrong about with that idea?

Last edited on

LB (13399)

LB wrote:
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.

hamsterman wrote:
Somehow old thing + new syntax + some restrictions = an entirely new thing.

I'm confused...how were my usages of "conceptually" and "usage wise" ignored??

@Cubbi,
Thanks for the effort. But I still don't understand.

Wikipedia wrote:
Lvalues are values that have addresses being programmatically accessible to the running program [...]

Implying that to store an lvalue, means to store an address. The problem is that all of the terminology surrounding pointers and references is interchangeable.

@LB,
That sentence was just an angry generalization for the rest of the thread. The reply to your statement is the paragraph before it.

Gaminic (1621)

Just wondering, but are references ever used outside of function parameters and return types? I honestly don't see the point of this type of code:

1
2
3

int a = 10;
int &x = a;
cout << x;

Second question for those on the "pointer = reference" side: if it were up to you, which one would you delete, and why?

@Gaminic I'd probably delete references if it was me, since you can't change the value of a reference once it's set. Meaning you don't have dynamic memory allocation and data structures. So references wouldn't be as useful as pointers because of the restrictions imposed on by the compiler.

Actually the variables to objects in java are called references too. And Java programmers like to argue that Java uses "references" not pointers. Yet basically they're very similar.

in C++ using pointers: Object *o = new Object;

in Java using "references" Object o = new Object();

If you see what I mean, Java programmers like to argue it isn't a pointer though just because you can't dereference it, and instead the compiler does it for you behind the scenes.

Basically if you remove pointers from C++, there would be a lot of important things you won't be able to do. If instead references were to be removed. One can still always use pointers for pass by reference, etc. That's just my own opinion though, I'm not sure how others see it.

Last edited on

References could be used as members of a class.

I only delete pointers.
On a more serious note, I wouldn't remove either, as both have their place. I use both, for the same purposes, in different circumstances. Same goes for const pointers.

Gaminic (1621)

@Dacster13: Is it possible to overload operators so that they can still be chained, without using references?

@Moschops,
You can use one to extend the lifetime of a temporary object.
I'd like to see an example of this.

Here's one example, from here: http://herbsutter.com/2008/01/01/gotw-88-a-candidate-for-the-most-important-const/

string f() { return "abc"; }

void g() {
const string& s = f();
  cout << s << endl;
}

Gaminic (1621)

What's the difference between that and string s = f();?

What's the difference between that and string s = f();?

1
2

string s = f(); // This one creates a new string object named s
const string& s = f(); // This one doesn't create a new string object named s

Last edited on