Had this been something like CMonks or PascalMonks I would have been voting ++, but it is not and so I didn't.

That's cool...I'm not looking to start a pissing
contest, but the question didn't have any replies
when I started my post, so I didn't have the
benefit of your code.

As far as the difference between a pointer and a
reference...dude, when it comes down to it, aren't
they really just the same thing? Semantically, yes,
they're different. Under the hood? I pass things by
reference, I give you the address. I use a pointer,
it holds the address of something. I make a reference
and I point you to a seperate chunk of code. I'm not
a complete chimp on that respect. I haven't had the
time or inclination to go look at whether or not the
interpreter makes full substitutions at references or
jumps to the sub when everything's said and done.
That's deeper than I've needed to be for a long time.

I _am_ an Acolyte, though, and one who does not get to
code nearly as much as he wants to, so it is my bad
for missing the pretty obvious reference to the
native sort. I shouldn't have done that. I've always
had that inherent distrust of someone else's code that
I haven't thoroughly looked examined, just a leftover
from school, and that's why I made the comment about
picking a sorting algorithm. I know those ingrown ones
are usually good at large data sets, but I like to pull
off the lid and see _exactly_ how it's working inside,
make sure it fits. You can't blame a guy for that.


ever learning,
-B.

As far as the difference between a pointer and a reference...dude, when it comes down to it, aren't they really just the same thing? Semantically, yes, they're different. Under the hood?

This is one of my pet peeves, so excuse me if I come across somewhat strong.

A reference is not a pointer. Conceptually, there are many similarities, but the basic use of a pointer (at least in C and assembly) is that the pointer itself can be manipulated. As far as I know, you can't manipulate references without Deep Magic. Discussions of pointer concepts are worth very little to non-C/ASM newbies learning references, and can confuse C/ASM people even more. There is nothing to be gained by bringing pointers into a discussion of references.

Now of course, I realize you weren't trying to bring pointers into a reference discussion, you just used a similar term because you're familiar with it, so I'm not attacking you for that. (I'm attacking you for saying "aren't they really the same thing" :) )

As was already said, pointers and references are different in a key way. A pointer is a direct address through which you can get at something. A reference is an indirect way to refer to it which hides any necessary garbage collection from you. Therefore there are significant differences both in implementation and use.

The implementation must differ because you cannot just use a bare address. If you are doing some sort of reference counting (which Perl does) then you need to have the reference modifying reference counts on the thing referred to. If you are doing some sort of garbage collection then the reference needs to be kept track of so that you can know to modify the reference if you move the underlying object from one place to another. Either way a reference is a considerably more complicated beast than a pointer.

The use is likewise different. First of all you would never be able to do games like pointer arithmetic with references since that would have to expose too much of the internal differences. Secondly pointers are an excellent candidate for all sorts of errors in languages that have them, so you need to be careful to carefully track when things are allocated and need to be destroyed. So references are both more limited and far safer.

This terminology difference is preserved across a lot of languages. If the language says it has references, they are opaque and it does garbage collection behind your back. If they claim pointers then that is up to you but you may be able to play a lot of Really Cool Tricks.

When it comes to sort, well trying to roll your own is a Really Bad Idea. The reason is trivial. Perl has a lot more overhead than a low-level language like C. Therefore if you roll your own, you have to expect to be running about 10 times slower than the native function. If you are not then that is a bug in the native function, not an excuse to start rolling your own! If you cannot accept this and keep on reinventing the wheel then your code is going to be slower and more buggy than it needs to be.

And finally, I appreciate the thought of trying to answer, but the execution is still an issue. Perl questions here, particuarly simple ones, tend to be answered fairly fast and completely. So if you don't have an answer that you are sure is accurate and complete, you probably should just wait for someone else to answer it. If nobody answers it for a bit, then give a partial answer if you have one.

I am sorry if I am coming off stronger than I intended. I just wanted to make sure that my -- vote didn't confuse you, that you understood the reason for it. As it stood your answer was one which was misleading in ways that IMO would result in someone becoming further confused. I am trying to explain why I think that, and make sure that you were not left wondering (as has happened to me in the past) why someone voted against your post.