Re: [Alephmodular-devel] save; crossplatform issues.

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

On Saturday, January 4, 2003, at 07:50  AM, Chris Bergmann wrote:

>> We have classes we can use for encapsulation. We have the ability to 
>> define Class Foo and have platform specific subclass FooPlatform.
>
> Indeed. The danger here is that virtual functions can be slower than 
> you'd expect. With care and experience, you can write a completely 
> virtual API which performs quite well. And of course many APIs are not 
> performance critical. It's something that needs to be looked on a 
> case-by-case basis. My take on it is - where something can be decided 
> at compile time without loss of flexibility, that path is preferable.
>
I agree on the case-by-case basis. With files and basic GUI functions 
(for instance menus and dialogs) virtual is probably fine. However the 
display class that provides the glue between AM rendering and the 
current platform's screen could benefit from not having virtual 
functions.

> All three methods (classes, single files, multiple files) have 
> difficulties, especially if the code is evolving. For this reason, i'd 
> like to put forward that (in effect) the entirety of the 
> platform-specific code is moved away from the generic code into a 
> separate API layer. IE. Abstraction of file classes is performed at 
> the file class level; not inside the save/load code itself. Same goes 
> for sound code; network code; etc. This may sound obvious but it's 
> easy to overlook and could make for an awful mess later on if not 
> approached thoughtfully.
>
Agreed on providing abstraction at a low level. That already mirrors 
some of how internally Bungie was handling cross platform issues. 
External code calls foo and internally foo is allowed to call _foo, 
_bar, and _baz to handle the internal implementation for the current 
platform.

-Jeremy Parsons