The Nightstar Zoo

Nightstar IRC Network - irc.nightstar.net
It is currently Tue Sep 19, 2017 5:36 pm

All times are UTC - 6 hours [ DST ]




Post new topic Reply to topic  [ 12 posts ] 
Author Message
 Post subject: Pointers v. References
PostPosted: Sat Nov 19, 2005 3:09 pm 
Offline
Energizer Bunny
User avatar

Joined: Wed May 22, 2002 12:24 am
Posts: 1634
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


Top
 Profile  
 
 Post subject:
PostPosted: Sat Nov 19, 2005 4:08 pm 
How do you mean? In general, or in a specific language?

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


Top
  
 
 Post subject:
PostPosted: Sat Nov 19, 2005 9:59 pm 
Offline
Energizer Bunny
User avatar

Joined: Wed May 22, 2002 12:24 am
Posts: 1634
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


Top
 Profile  
 
 Post subject:
PostPosted: Sun Nov 20, 2005 4:51 am 
Offline
Entertainment
Entertainment
User avatar

Joined: Sat May 11, 2002 7:55 pm
Posts: 867
Location: 59°20'N 18°03'E
Pointers can have null values, which makes them more expressive. (And Java has pointers, not references. java.lang.NullPointerException sound familiar to anyone? 8-))


Top
 Profile  
 
 Post subject:
PostPosted: Sun Nov 20, 2005 11:02 am 
Offline
Energizer Bunny
User avatar

Joined: Wed May 22, 2002 12:24 am
Posts: 1634
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


Top
 Profile  
 
 Post subject:
PostPosted: Sun Nov 20, 2005 3:19 pm 
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.


Top
  
 
 Post subject:
PostPosted: Sun Nov 20, 2005 4:21 pm 
Bo Lindbergh wrote:
Pointers can have null values, which makes them more expressive. (And Java has pointers, not references. java.lang.NullPointerException sound familiar to anyone? 8-))


Nullpo!

GA!


Top
  
 
 Post subject:
PostPosted: Mon Nov 21, 2005 2:34 pm 
Pi wrote:
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.


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...


Top
  
 
 Post subject:
PostPosted: Mon Nov 21, 2005 11:19 pm 
Schol-R-LEA wrote:
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.


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.

Schol-R-LEA wrote:
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.


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.


Top
  
 
PostPosted: Fri Dec 30, 2005 5:16 pm 
Offline
Nightstar Graveyard Daemon
User avatar

Joined: Mon Jun 03, 2002 8:30 pm
Posts: 1071
Location: Wouldn't you rather observe my Velocity?
Vorn the Unspeakable wrote:
What can you do safely with pointers (to single objects; arrays are a different sack of potatoes) that you can't do with references?


  • 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.


Top
 Profile  
 
PostPosted: Fri Aug 21, 2009 9:38 pm 
Offline
Safari Exhibit
Safari Exhibit

Joined: Sun Oct 07, 2007 1:46 pm
Posts: 110
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


Top
 Profile  
 
PostPosted: Fri Dec 18, 2015 2:31 am 
Offline
Intern
Intern
User avatar

Joined: Wed Apr 08, 2009 7:02 pm
Posts: 1074
Location: Puget Sound, WA
Since I started out with Assembly language with the 8080, Z-80, and 8088, I find pointers to be very intuitive, and C to be a useful tool. When I returned to college in 1986, Clemson University supported several compilers for COBOL, Fortran, C++, BASIC, etc., but, in reality, they had code converters which took high-level languages, converted them to C, and then converted the C code to assembly code for the target system. C is a very powerful tool, but with great power comes great responsibility.

_________________
===============================================
"A sufficiently-advanced technology is indistinguishable from magic."
Arthur C. Clarke
"Sufficiently advanced magic is indistinguishable from technology."
Jack L. Chalker
"Magic is just another way of saying 'I don't know how it works.'"
Larry Niven
"Any technology, no matter how primitive, is magic to those who don't understand it."
Florence Ambrose


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 12 posts ] 

All times are UTC - 6 hours [ DST ]


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group