| Re: [AD] Proposal for new branch |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
Angelo Mottola wrote:
Yes. A lot of the duplicated code should be merged together eventually.
vtables introduce overhead and are annoying (for reading, writing,
experimenting, debugging...), so I didn't want to use them
unnecessarily. But we can return to them later, if desired.
The overhead is just some pushes and a call instructions... not much a
loss on modern CPUs.
I didn't just mean that kind of overhead. Everytime you add a new
public function you have to (1) add a function declaration, (2) add a
wrapper function, (3) add a method in some vtable, (4) update old driver
tables, (5) add platform-specific definitions.
I know they can be annoying for debugging, but the advantages are 1)
no code duplication and 2) fewer possibilities to have a port behaving
differently from another one.
I'll stick with the vtables for the joystick API (which I'll be doing
next -- it's the easiest out of the input devices) and see how that
goes. I have doubts though -- remember I actually used C++ to get away
from them ;-)
As a consequence of 1), the lib code also becomes easier to read and
maintain IMO.
Maintain: probably, but vtables are not the only way to reduce duplication.
Readability: no way. An extra layer of indirection that could point to
nearly anywhere -- and sometimes the pointer changes!
About readability, can you stick with the old habit of writing a small
header for each function, telling what the function does? With so much
new code (and expecially since you now have userland functions spread
both on the core source dir and the platform specific dirs, instead of
just on the code dir) it's hard for newcomers to get what's really
going on...
Sure, I was just in a hurry to commit.
Peter