I’m not sure this applies in this case (not sure about what you’re
actually doing - sounds interesting, though; checking the links out
right now :-), but the standard OO approach for
interface/implementation separation would be to keep these two
pointers out of the interface and make the interface a Pure Virtual
class (C++ terminology; don’t remember if Object Pascal has another
name for this) so that it cannot be instantiated by mistake. Then
inherit the implementation class from the interface and add the
private stuff there. Obviously, this isn’t going to be binary
compatible with the traditional C style OO way, as the private
pointers will be added after the interface stuff, physically…
BTW, this applies to C style OO as well; if I want really private
stuff, I just make the public struct a part of the private struct,
which is then used internally. Example:
/* In the API header: */
typedef struct
{
int something;
float *something_else;
} interface_t;
/* In the implementation header: */
typedef struct
{
interface_t the_interface;
int magic;
private_stuff_t *something_private;
} implementation_t;
Just make sure that these structs cannot be instantiated “on the
outside”, as that would result in nasty things when the library
expects the pointers to reference instances of implementation_t! The
"magic" field could be used to practically eliminate the chance of
that happenening, and is definitely recommended for “debug checked
builds”. (Adding that field doesn’t affect the interface, so it’s
safe to use debug libraries with release binaries.)
NOTE: IIRC, the Delphi compiler (and probably some C++ compilers)
insert a Virtual Method Table Pointer as the first field
whether or not it’s needed, which means simple type casting
from interface_t to implementation_t isn’t safe! Keep that in
mind, as many “OO upgraded” languages actully treat the pre-OO
struct/record constructs as objects/classes with different
field visibility defaults… (I don’t think that’s the case
with Object Pascal and record, though. It is with C++ and
struct.)
//David
.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------> http://www.linuxaudiodev.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |--------------------------------------> david at linuxdj.com -'On Saturday 03 March 2001 21:29, Dominique Louis wrote:
Hi Mattias,
Mattias Engdeg?rd wrote:
I’m working on the conversion to Delphi of SDL on behalf of
the JEDI project. Within the SDL_BlitMap structure there is a
structure called private_hwaccel declared. What is it’s
definition. I managed to find the private_swaccel one but not
private_hwaccel structure.
why do you need to know? It’s handled internally by SDL and not
exposed in any way
In the SDL_Surface structure there is a reference to 2 structures
the first being private_hwdata and the second being SDL_BlitMap.
Maybe I am missing something here but isn’t SDL_Surface a public
structure. I am no expert on C/C++, but in Delphi ( Object Pascal )
if a structure is defined within a puiblic structure, the embeded
structure must be visible to the newly defined structure ( I hope
that makes sense ), if you specify it by name. If both these
structures are meant to be hidden from the the developer when using
the dll, I can get around this by defining these structure
variables as just pointers, but I would like to do the right thing
as I hope that more Delphi/Kylix developers will use SDL and I
would hate to get it wrong at this stage. Hence my need for
clarification on this issue.