more inheritance patterns

[Mick Charles Beaver]

Hello,

At work, someone showed me a way to avoid virtual functions while
maintaining an interface class.

Basically,

class _MyClass {
void Method;
};

#if defined(LINUX)
#include "linux/MyLinuxClass.h"
class MyClass : public MyLinuxClass {};

#elif defined(WINDOWS)
#include "windows/MyWindowsClass.h"
class MyClass : public MyWindowsClass {};
#endif

Then, throughout the code base, MyClass would be used, following the
interface defined in _MyClass, while still allowing platform-specific
code where needed.

My question is, where could I read about more constructions like this?
My coworker called it an "inheritance pattern." I'd love to learn more
about them (even though I'm sure a case can be made for avoiding this
style).

Thanks much,
Mick Charles Beaver

[Mick Charles Beaver]

Alf P. Steinbach <al***@start.nowrote:

>This is a programmer enforced design, which requires never using a
pointer to the "abstract" base class. It's a high-performance
requirement, where virtual functions have too high of an overhead and
must be avoided.

Have you measured, and if so, what were the results?

I don't have any hard numbers at my disposal, but on the particular
architecture where it is an issue, virtual functions almost always
result in a branch misprediction.

#ifdef-based code is a point number 4.

It seems you folks go out of your way to create an unmaintainable mess. :-(

If was weened off #ifdef-based code in 1985 or thereabouts. You don't need it.
It's stupid.

I believe it has its place. Maintainability is always a goal, so this
construct and its associated #ifdef's are used sparingly.

-Mick

[James Kanze]

On Jun 27, 7:06 pm, [e-mail] (Mick Charles Beaver) wrote:

Alf P. Steinbach <[e-mail]:

This is a programmer enforced design, which requires never using a
pointer to the "abstract" base class. It's a high-performance
requirement, where virtual functions have too high of an overhead and
must be avoided.

Have you measured, and if so, what were the results?

I don't have any hard numbers at my disposal, but on the particular
architecture where it is an issue, virtual functions almost always
result in a branch misprediction.

Sounds like HP PA. Still what you're hiding here is system
dependencies, i.e. system calls. Even a branch misprediction is
negligible compared to the context switch to system mode, and
everything which goes on there.

#ifdef-based code is a point number 4.

It seems you folks go out of your way to create an
unmaintainable mess. :-(

If was weened off #ifdef-based code in 1985 or thereabouts.
You don't need it. It's stupid.

I believe it has its place.

I has its place, yes. Obfuscation and job security, for
example. Other than that, any #if other than an include guard
is really serious enough to get a programmer fired, at least if
I'm in charge.

Maintainability is always a goal, so this construct and its
associated #ifdef's are used sparingly.

Actually, as you presented it, the construct doesn't need the
#if's at all. You just have to organize your code a little
better. (But of course, as you presented it, the construct just
added a lot of code for nothing anyway.)

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[James Kanze]

On Jun 27, 6:17 pm, Noah Roberts <[e-mail]:

Mick Charles Beaver wrote:

At work, someone showed me a way to avoid virtual functions
while maintaining an interface class.

Basically,

class _MyClass {
void Method;
};

#if defined(LINUX)
#include "linux/MyLinuxClass.h"
class MyClass : public MyLinuxClass {};

#elif defined(WINDOWS)
#include "windows/MyWindowsClass.h"
class MyClass : public MyWindowsClass {};
#endif

Then, throughout the code base, MyClass would be used,
following the interface defined in _MyClass, while still
allowing platform-specific code where needed.

I don't understand, are you saying that you cast your MyClass
objects to _MyClass? I don't see how you could otherwise be
getting any behavior from your MyClass objects at all. The
subclassing thing I understand but I don't see what _MyClass
is doing.

Frankly, the simplest way to implement non-virtual
polymorphism is with templates.

Even that's unnecessary additional complexity (and not a very
good solution for this particular problem). In this case, link
time resolution handles all of the problems simply and
elegantly.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Mick Charles Beaver]

Even that's unnecessary additional complexity (and not a very

good solution for this particular problem). In this case, link
time resolution handles all of the problems simply and
elegantly.

Would you be able to recommend any web resources for learning more about
link time resolution?

Thank you

[Noah Roberts]

Mick Charles Beaver wrote:

>Even that's unnecessary additional complexity (and not a very
good solution for this particular problem). In this case, link
time resolution handles all of the problems simply and
elegantly.

Would you be able to recommend any web resources for learning more about
link time resolution?

Thank you

I never said what you are quoting above. Who did? Did you reply to the
posting you intended to?

[Noah Roberts]

Alf P. Steinbach wrote:

* Mick Charles Beaver:

>Alf P. Steinbach <al***@start.nowrote:

>> 1. Name that starts with underscore followed by uppercase, "_MyClass",
is reserved for the implementation.

I agree that should change.

>> 2. Non-virtual member functions can't be overridden.

This is a programmer enforced design, which requires never using a
pointer to the "abstract" base class. It's a high-performance
requirement, where virtual functions have too high of an overhead and
must be avoided.

Have you measured, and if so, what were the results?

It's interesting if you have done so, because to the best knowledge
available virtual functions have near to zero overhead.

Well, they certainly won't be inlined.

[Mick Charles Beaver]

Noah Roberts <us**@example.netwrote:

I never said what you are quoting above. Who did? Did you reply to the
posting you intended to?

Yet another good reason to attribute a quote to someone.

Ugh.

-Mick