Re: [Alephmodular-devel] Build-selectable binding time

[Br'fin <br...@ma...>]

On Wednesday, January 22, 2003, at 11:01  AM, Woody Zenfell, III wrote:

> Hi,
>
> I was thinking, for a lot of this stuff it may make sense to use like 
> classes, so that we can easily group interfaces and ensure some degree 
> of consistency in their use, and also so that some modules can inherit 
> some routines but override others.
>
> So that would tend to point toward using effectively an 'interface', 
> i.e. a base class with lots of pure virtual functions, that subclasses 
> override.
>
> But in many cases there will always be only one actual concrete 
> subclass used in any given build of the program.  (For example, the 
> Carbon build is probably always going to use the CarbonWidgetManager 
> or whatever, and a build with SDL widgets will always use the 
> SDLWidgetManager.)  So it seems to make sense to allow that choice of 
> subclass to be made at compile-time; thus the compiler and linker can 
> take advantage of this "advance knowledge" to produce better code.
>

One one hand it sounds like a good idea.
On the other hand it's an optimization and makes the code trickier.

I'm inclined to nix the idea for now. It adds to the code complexity 
while possibly solving an inappropriate problem. I admit the question 
is much more interesting with respect to game responsive elements. Such 
as the sound manager and the graphics handler. On the other hand, this 
is Marathon, not Doom III. We shouldn't be taxing the system that badly 
:)

Now if we actually find that we're having problems with a particular 
area being slow, then I'm more likely to say yes to optimizations, but 
just for that specific area.

-Jeremy Parsons