POV-Ray : Newsgroups : povray.off-topic : C# 4.0 Default parameters : Re: C# 4.0 Default parameters Server Time
9 Oct 2024 16:15:38 EDT (-0400)
  Re: C# 4.0 Default parameters  
From: Warp
Date: 4 Feb 2009 12:27:35
Message: <4989d007@news.povray.org>
Mike Raiford <"m[raiford]!at"@gmail.com> wrote:
> At least in C# you can't do function pointers.

  There are situations where function pointers are actually useful.
Here's one actual example which I have used in the past (simplified here,
of course):

class MyCLP: public CommandLineParser
{
    bool debugParamHandler(const std::string&)
    {
        // do whatever here
    }

 public:
    MyCLP()
    {
        setOptionHandler("debug", &MyCLP::debugParamHandler,
                         "The short description of the -debug parameter");
    }
};

  The idea is that 'CommandLineParser' is a class which parses the command
line parameters (in the project in question it parsed things like the input
and output file names as well as many default parameters supported by all
the programs in the project), and if you want to support a parameter specific
to this program, you specify it with the 'setOptionHandler' function. You
give the function the name of the parameter and a pointer to the function
which CommandLineParser should call when that parameter appears in the
command line.

  The internal implementation of CommandLineParser becomes a bit complicated
(for many reasons), but this is by far the best way from the *usage* point
of view. Any other solution would require to always write a lot more code
if you want to add support for a new command-line parameter. This solution
requires the minimum amount of code you have to write in order to do that.

  This doesn't mean this could be the only way of implementing this
functionality. It's just the simplest from the usage point of view.

  The next best thing would be to have just one generic virtual function
in the base class which gets called when a registered command-line parameter
appears, and then you implement this virtual function. However, you would
have to implement it as a big if... else if... else if... else if... else
block, so it becomes more cumbersome than the way described above.

  Another example of where a function pointer can be handy is when wanting
to supply a comparator to a STL algorithm or data container.

  For example, suppose that you want to sort an array of objects in a
special way (or simply if the objects don't support the < comparison).
What to do? What you do with the STL is:

    std::sort(array.begin(), array.end(), objectComparator);

  Now a comparator is "anything that behaves like a function taking two
const references to array elements, and returns a bool". The most obvious
thing which behaves like that is a *function* with that signature. For
example assuming that the element of the array is of type Object, you would
write such a function as:

    bool objectComparator(const Object& lhs, const Object& rhs)
    {
        // return true if lhs < rhs, else false
    }

  Now if you pass this function as the third parameter for std::sort(),
as above, what you are doing is actually passing a function pointer.
(If you look at the type id of the resulting std::sort() function, the
type of the third parameter will indeed be a function pointer with that
signature.)

  It's possible to create an object which behaves like such a function
(a functor object), but it's more writing.

-- 
                                                          - Warp


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.