Re: more inheritance patterns
On Jun 27, 7:06 pm, m...@cs.wisc.edu (Mick Charles Beaver) wrote:
Alf P. Steinbach <al...@start.no> wrote:
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:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34