You know, SDL video is turning into a really well defined interface.
It would fit into a C++ class very easily.
Of course, because of linking oddities it will remain C in the future.
You know, SDL video is turning into a really well defined interface.
It would fit into a C++ class very easily.
Of course, because of linking oddities it will remain C in the future.
You know, SDL video is turning into a really well defined interface.
It would fit into a C++ class very easily.
It might be a good idea to follow this idea & use classes internally
(maybe even templates, as they provide static resolution & thus won’t have
the same overhead as polymorphic classes.) Due to compatibility reasons,
we’d have to export most of the interface as C functions as well…
Of course, because of linking oddities it will remain C in the future.
Are you refering to the name mangling here?
cheers,
phil.
It might be a good idea to follow this idea & use classes internally
(maybe even templates, as they provide static resolution & thus won’t have
the same overhead as polymorphic classes.) Due to compatibility reasons,
we’d have to export most of the interface as C functions as well…
Yeah, it’s the exporting of the interface as C functions that’s a pain… ?
Of course, because of linking oddities it will remain C in the future.
Are you refering to the name mangling here?
Yep, which would be avoided by exporting C functions.
You’d have to keep the SDL_Surface structure a C struct, and
that’s the part that would benefit the most by being a class.
I think I’ll leave it C for now, with the thought in mind…
You know, SDL video is turning into a really well defined interface.
It would fit into a C++ class very easily.
Why not simply write a wrapper, a la gtk?
Of course, because of linking oddities it will remain C in the future.
still…
njhOn Wed, 22 Apr 1998, Sam Lantinga wrote: