in reply to Dynamic sort algorithm selection

So basically you want a pointer to a function.

I'm not too sure how to do that..I know that you
can create/use pointers within perl, but I haven't
dug through my tchrist notes in too long to even
have a clue of remembering how.

As far as making pointers to functions...couldn't
you just make a simple if/else or case based on the
designation variable to avoid the whole headache?
TIMTOWTDI, and all that, I guess.

What algorithm are you looking to use for your
array sort? The first glance made it look like a
bubble sort, which is fine if you aren't trying for
high performance. Otherwise, _Algorithms and Data
Structures_ by Corman-- aka the white cookbook, is
a good place to get a lot of non-language specific
psuedocode for just about every basic sorting option.

good luck, -B.

Replies are listed 'Best First'.
RE (tilly) -2: Dynamic sort algorithm selection
by tilly (Archbishop) on Nov 15, 2000 at 17:15 UTC
    I am the -- vote, and I voted -- because there are several accurate answers and yours did not even meet the technical bar of knowing what the construct you want is called (reference), realizing that constructing code had already been posted (eg by me), or realizing that the person was asking about Perl's native sort function. (Indeed if you need to roll your own then you probably don't want to use a comparison function written in Perl!)

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