Workaround for static methods that need to be virtual

[K]

Hi all; I don't think this is a VC compiler question, so I am asking this
here. I did hunt around the web and Stroustrup before posting, but found no
references to this problem.

I have a base class (BasePort) that defines an interface for subclasses
(LPort, NPort). Each implementation of BasePort as LPort or NPort requires
a default configuration, which is currently obtained via a static method,
GetDefaultConfiguration() (henceforth, GDC). BasePort implements that
method to always return false, in the hopes that it would be obvious to
*Port implementers that something is _wrong_ (it's documented, too).
However, attempts to use LPort or Nport's GDC go to BasePort's GDC, not the
*Port GDC.

So, a bit of thinking here, implies that the BasePort GDC is not virtual so
dynamic binding can't be done, and the base GDC is called, not the sub.
But, it appears that static methods can't be virtual, so redirection seems
problematic.

The obvious solution is to make the methods non-static, and then virtual;
however, the *Port implementations depend on licenses that I do not want to
tie up just to get configurations (plus, the creation of the objects is
fairly expensive) because the licenses are very expensive ($) and needlessly
eating one is an issue.

Another solution is to provide a register method in the parent class, and
each *Port registers it's own GetDefaultConfiguration with BasePort and have
the BasePort GDC resolve the right one. This seems... inelegant.

So, better solutions? Anyone have an idea on how to handle this an C++ OO
way?

Thanks in advance!
--Keith

[Randy King]

K wrote:

So, better solutions? Anyone have an idea on how to handle this an C++ OO
way?

You might check out the example for the Acyclic Visitor Pattern at the
following url:

http://www.objectmentor.com/resources/articles/acv.pdf

[Victor Bazarov]

K wrote:

Hi all; I don't think this is a VC compiler question, so I am asking this
here. I did hunt around the web and Stroustrup before posting, but found no
references to this problem.

I have a base class (BasePort) that defines an interface for subclasses
(LPort, NPort). Each implementation of BasePort as LPort or NPort requires
a default configuration, which is currently obtained via a static method,
GetDefaultConfiguration() (henceforth, GDC). BasePort implements that
method to always return false, in the hopes that it would be obvious to
*Port implementers that something is _wrong_ (it's documented, too).
However, attempts to use LPort or Nport's GDC go to BasePort's GDC, not the
*Port GDC.

So, a bit of thinking here, implies that the BasePort GDC is not virtual so
dynamic binding can't be done, and the base GDC is called, not the sub.
But, it appears that static methods can't be virtual, so redirection seems
problematic.

The obvious solution is to make the methods non-static, and then virtual;
however, the *Port implementations depend on licenses that I do not want to
tie up just to get configurations (plus, the creation of the objects is
fairly expensive) because the licenses are very expensive ($) and needlessly
eating one is an issue.

Another solution is to provide a register method in the parent class, and
each *Port registers it's own GetDefaultConfiguration with BasePort and have
the BasePort GDC resolve the right one. This seems... inelegant.

So, better solutions? Anyone have an idea on how to handle this an C++ OO
way?

If registering with the base class is "inelegant", then my suggestion
may seem inelegant too, but I'll give it nonetheless. It is what is
known as "policy-based design":

template<class DefConfKeeper> // policy - how to get def conf
class BasePort {
// ...
public:
static bool GetDefaultConfiguration(Configuration& c) {
return DefConfKeeper::GetDefaultConfiguration(c);
}
};

struct LPortDefConfKeeper {
static bool GetDefaultConfiguration(Configuration& c) {
// do something with 'c'
return true;
}
};

class LPort : public BasePort<LPortDefConfKeeper> {
...
};

struct NPortDefConfKeeper {
static bool GetDefaultConfiguration(Configuration& c) {
// do something with 'c'
return true;
}
};

class NPort : public BasePort<NPortDefConfKeeper> {
...
};

This solution is not necessarily "OO", but it's certainly "C++".

Victor