Different implementation of a member function from instance to instance in C++

Question

I know there is another very similar post here on SO. But I think it's a bit different. The main question here is not a discussion of advantages or disadvantages of some methods (though it appears naturally) but what methods exist in order to reach polymorphic behavior and what is the best one with respect to some criteria (see below).

Suppose I have a class with the following structure

class Evaluator
{
    public :
        double Evaluate( double x )
        {
            /*something here*/
        }

};

where we can choose different implementation of Evaluate function from instance to instance. I want to find optimal (in some sense) solution with respect to the following criteria.

• Implementation of the Evaluate function (what Evaluate exactly is) is determined at the construction step of an instance
• It should be as simple as possible to add new implementation of the Evaluate function
• Evaluate function is intended to be a method of an abstract class
• Not only Evaluate method is intended to be used but also its derivative. So it would be good if function and its derivative live together

Solutions that I've found could help to understand what I want to reach.

Using pointer to a function

//somewhere in someheader.h
#include <cmath>

namespace evals
{
    inline double Sin( double x ) { return sin(x); }
    inline double Sigmoid( double x ) { return 1. / ( 1. + exp( -x ) ); }
}

//somewhere in Evaluator.h
class Evaluator
{
    protected :
        double (*_eval)( double );

    public :
        Evaluator( double (*eval)( double ) ) : _eval( eval ) { }
        double Evaluate( double x ) { return _eval( x ); }  
};

//somewhere in test.cpp
#include "someheader.h"
#include "Evaluator.h"

Evaluator e( &evals::Sin );
e.Evaluate( 3.14159 );//returns sin( 3.14159 )

Using virtual functions

//somewhere in someheader2.h
#include <cmath>

namespace evals
{
    class AbstractEvaluate
    {
        public :
            virtual double Return( double x ) = 0;
    };

    //concrete evals
    class Sin : public  AbstractEvaluate
    {
        public :
            double Return( double x ) { return sin( x ); }
    };

    class Sigmoid : public AbstractEvaluate
    {
        public :
            double Return( double x ) { return 1. / ( 1. + exp( -x ) ); }
    };
}

//somewhere in Evaluator2.h
#include <string>
#include "someheader2.h"

class Evaluator
{
    protected :
        AbstractEvaluate* _eval;//cannot have an instance, only a pointer

    public :
        Evaluator( std::string evalName )
        {
            //according to some rule return pointer to desired concrete evaluate class e.g.
            if( evalName == "Sin" ) { _eval == new evals::Sin; }
            else if( evalName == "Sigmoid" ) { _eval == new evals::Sigmoid; }
            else { /*some default behavior*/ }
        }

        double Evaluate( double x ) { return _eval->Return( x ); }
}

//somewhere in test.cpp

#include "Evaluator2.h"

Evaluator e( "Sin" );
e.Evaluate( 3.14159 );//returns sin( 3.14159 )

Discussion

While the second approach is more attractive for my personal problem (see the last criterion) I see the dangerous new operator there. Is it actually a problem and would an appropriate destructor resolve it? What else could be a problem with solutions I provided? And the main question: what is the best way to do what I want?.

Answer 1

The second one is a Strategy Pattern. I should go for the second one, much cleaner and readable.

I would fix the if-branching and the dynamic construction object in this way:

someheader2.h

#include <cmath>

namespace evals
{
    class AbstractEvaluate
    {
        public :
            virtual double Return( double x ) const = 0;
            virtual ~AbstractEvaluate() {} // or = default in C++11
    };

    //concrete evals
    class Sin : public AbstractEvaluate
    {
        public :
            double Return( double x ) const { return sin( x ); }
    };

    class Sigmoid : public AbstractEvaluate
    {
        public :
            double Return( double x ) const { return 1. / ( 1. + exp( -x ) ); }
    };
}

evaluator2.h

#include <string>
class Evaluator
{
    public :
        Evaluator( const evals::AbstractEvaluate& evaluator )
           : _eval(evaluator)
        {
        }

        double Evaluate( double x ) const { return _eval.Return( x ); }

    private:
        const evals::AbstractEvaluate& _eval;

};

#include <iostream>
#include "Evaluator2.h"

int main(int argc, char *argv[])
{
   evals::Sin eval = evals::Sin();
   Evaluator e = Evaluator(eval);
   std::cout << e.Evaluate( 3.14159 );//returns sin( 3.14159 )

   return 0;
}

It's a basic dependency injection and it's safer to error.

Of course you can still improve your code if you want, for instance managing smart pointer or even better using a factory.

Factory should be the best because would take care of the construction of the evaluation class hiding how is managed.

_eval is a reference because null is not an accepted value. For the same reason, Evaluator accept a const reference beacuse it has to be constructed with a valid Evaluate object.

Answer 2

I would simply pass the function to call in the constructor of the Evaluator class, and store it as a mere pointer to function. No abstract class is involved but thanks to lambda functions, it is simple to use

Class definition:

class Evaluator {
    typedef double (*Func)(double);
    Func func;
public:
    Evaluator(Func func): func(func){}

    double evaluate(double x) {
        return func(x);
    }
};

Usage:

#include <iostream>
#include <cmath>
#include "Evaluator.h"

int main() {
    Evaluator eval1(sin);
    double val = eval1.evaluate(3.1415927);
    printf("%g - %g\n", val, eval1.evaluate(3.1415927 / 2));
    Evaluator evalsig([](double x) { return 1. / ( 1. + exp( -x ) ); });
    printf("%g\n", evalsig.evaluate(0.));
    return 0;
}

Compiles without a warning and outputs as expected:

-4.64102e-08 - 1
0.5

Among the nice points, no dynamic object is ever used, so no need for specific copy or move constructor or assignation nor explicit destructor.