The Nightstar Zoo

So, I don't get it.

What can you do safely with pointers (to single objects; arrays are a different sack of potatoes) that you can't do with references?

Vorn

How do you mean? In general, or in a specific language?

In C++, you can't do dynamic allocation with references AFAIK.

_________________
"I remember the first time I got laid. There was nothing but darkness at
first. Then movement, coming in fits and starts. Then I felt a weird
urge, and used my sharp beak to break free of that damnable prison."
—— Karim Rashad, in rec.martial-arts

In general. In Java and other pointer-free languages, dynamic allocation happens in just references.

What is the advantage to having a distinction between a pointer and a reference?

Vorn

Pointers can have null values, which makes them more expressive. (And Java has pointers, not references. java.lang.NullPointerException sound familiar to anyone? )

Java does not make a distinction between pointers and references, though, and you can't do pointer arithmetic. Therefore they are more like references than pointers.

Vorn

As Vorn touched on, there is no fundamental difference between pointers and references. They both are a data type that allow access to an object via its underlying memory.

Their semantic distinction depends on the language you're using, but in general a reference does so while still hiding the actual address in memory and offering a language construct to proxy dereferences.

The functional distinction again depends on the language, but, as Bo Lindbergh pointed out, one difference is that a pointer can be NULL, and a reference cannot. This can be very good for expressivity purposes, or very bad for obscure-bug purposes.

All things being equal, I prefer a language where I can make that decision based on the design, over a language that makes the decision for me.

Nullpo!

GA!

_________________
"I remember the first time I got laid. There was nothing but darkness at
first. Then movement, coming in fits and starts. Then I felt a weird
urge, and used my sharp beak to break free of that damnable prison."
—— Karim Rashad, in rec.martial-arts

Yes, but is working with pointers explicitly really necessary for the level of abstraction you're working at? While it is certainly important in systems programming to be able to get at the low-level implementation details, why should a programmer be aware of pointers - or even references - when writing applications? Seriously, in most apps, if you have to deal with any data structures at a level of abstraction below that of a list, heap, or bag, then you're probably working at too low a level of abstraction.

This is my real problem with hybrid languages like C++, Java, Ada, Object Pascal, etc.: they try to have both the efficiency of a systems language and the abstraction of a very high-level language, but to achieve neither. IMAO, it would be better to use a very-high-level language (e.g., Lisp, Smalltalk, ML, Erlang), and use C or assembly for post-optimization, than to try and split the difference through the whole program and end up with the sort of mess that is all too common with current systems. It isn't a matter of 'paradigmatic purity'; it's a matter of not having to pay attention to implementation details which are irrelevent to the task at hand. Writing code in C++ is like laying out a building blueprint where you need to specify the exact location of each nail or bolt or risk structural failure. There are times when the details need to be laid out precisely, but most of the time, having to do so is just a costly distraction. I wish that software houses would see how much time, money and effort they waste with these 'modern' languages.

Of course, wishing this and expecting it to ever be done are two different things, which is why I'm currently studying for the SCJP...

_________________
Schol-R-LEA;2 ELF JAM LCF BiWM MGT GS
First Speaker, Last Eristic Church of Finagle and Holy Bisexuality
#define KINSEY (rand() % 7) // Keeper of the Tent Peg of Homosexuality +5
You draw it, we misinterpret it. - Bo Lindbergh // Realitas vestri renuo, sufficioque mei.
"Fundamentalism, not atheism, is the ultimate rejection of faith."

I won't deffend C++ (for any reason, anywhere, ever) but having a marginally efficient language like Java that almost never needs to fall back on C is a big plus for portability and other reasons. They achieve a middle ground that ends up being pretty powerful.



Nyah, well you know how things go. Some people prefer that every project be in one language so they don't have to worry about hiring people that know that particular set of languages, so it's easier to outsource, etc.

• You can overwrite a pointer without affecting the underlying object. If you are passed in, for example, "const Foo *pFoo", you can assign the address of a different Foo to pFoo. That's a mutable pointer to a constant Foo. Compare "const Foo const *pFoo". Coming from a language like C, this was a critical distinction, where string constants are represented by a mutable pointer to a constant character. (Though technically this is getting into arrays.)
  
• You can swap two pointers and you can sort an array of pointers. I know you didn't want to mess with arrays, but still. A good half-semester of my CS program was dedicated to understanding arrays of pointers. This was a key feature for old machines, back when we had to walk barefoot ten miles uphill both ways to get to a compiler.
  
• With a pointer, you can write algorithms that focus on the fact that you have a-pointer-to-something and ignore for a moment the type of object-pointed-at. A whole host of concepts ensue from this distinction that are not present with references. These can mostly be filed under "pointer arithmetic" and "you can swap pointers".
  
• Null pointers have already been mentioned. You can get a null reference in C++ too, by the way, and just like Java it's a fatal error.
  
• You can cast the a pointer to something to a pointer to anything. This is usually either a bad design or a horrific hack to get around a bad design; I have written both types. This is considered a feature of references over pointers: that the type of a reference cannot be cast away without great effort (and probably a pointer).
  
• You can defer the initialization of a member pointer, but a member reference must be initialized to some valid or at least intermediate value immediately--even before the constructor proper runs in some cases. If your member reference does not have a void ctor, you have to use the ":" construction syntax in your constructor, e.g. "Foo(void) : m_rBar(42) {...}". The practical upshot of this is that it is much easier to defer initialization of pointer members, but you do not have to test a reference member to see if it is initialized. It always is.

That's all I can think of for now.

How about, "pointers are a concept whose roots and semantics are determined by the hardware, and everybody who does references is free to do them differently?"

Seriously. All the answers I've seen are true about references in Java (and other languages using its runtime), but not true about references in general. This is because references are a constructed semantic concept, not something whose semantics are determined by the hardware.

Example: I maintain a game program in C. I was using pointers to keep track of dynamically allocated objects, but ran into trouble with wild pointers (from the game map) after freeing the objects they pointed at (from events in the game schedule). After analyzing the problem, I refactored. Now all the client code uses GUIDs instead, and there is a manager data structure containing the only copy of the pointer which keeps track of which GUID corresponds to which object. Using wild GUIDs after an object is deallocated now return error codes that can be checked and handled. This solves the problem where wild pointers after an object was deallocated would crash the program with an invalid memory access or point to new objects that happened to have been allocated in the same memory space as deallocated objects.

What I've done here is implemented my own references for the sake of safety. Those GUIDs are references to objects. But because the code that implements them isn't the same code as the JRE, they don't have quite the same properties as Java references.

My point is that references, smart pointers, et al, have semantics that depend on the underlying code that implements them and what problems they are there to address, so you have to qualify anything you say about them by saying what language or what runtime environment (or, if not native to the language, what library) implements them.

One thing that is universal is that reference access is never quite as fast as pointer access.

Bear