Darren New <dne### [at] sanrrcom> wrote:
>  > class dfbScreen::MyIDirectFB: public IDirectFB

> I'm not sure what this means, but I'm pretty sure it's not going to work 
> well. :-) DirectFB is all built on top of C, with fake OO stuff, so there's 
> no way to get one of these for real.

  Why wouldn't it work? dfbScreen::MyIDirectFB *is* IDirectFB (this is OOP,
after all). Wherever an object of type IDirectFB is expected, you can pass
a pointer to an object of type dfbScreen::MyIDirectFB. And yes, even if you
are passing it to a C function.

  Just to make sure, I made a complete test to see that, indeed, it works:

/*-----------------------------------------------------------
  SomeCStruct.h
  -----------------------------------------------------------*/
#ifdef __cplusplus
extern "C" {
#endif

struct SomeCStruct
{
    int i, j;
};

void someCFunction(struct SomeCStruct* object);

#ifdef __cplusplus
}
#endif
/*-----------------------------------------------------------*/

/*-----------------------------------------------------------
  SomeCStruct.c
  -----------------------------------------------------------*/
#include "SomeCStruct.h"
#include <stdio.h>

void someCFunction(struct SomeCStruct* object)
{
    printf("i=%i, j=%i\n", object->i, object->j);
}
/*-----------------------------------------------------------*/

//-----------------------------------------------------------
// MyClass.hh
//-----------------------------------------------------------
class MyClass
{
    class SomeCStructWrapper;
    SomeCStructWrapper* obj;

    MyClass(const MyClass&);
    MyClass& operator=(const MyClass&);

 public:
    MyClass();
    ~MyClass();
    void foo();
};
//-----------------------------------------------------------

//-----------------------------------------------------------
// MyClass.cc
//-----------------------------------------------------------
#include "MyClass.hh"
#include "SomeCStruct.h"

class MyClass::SomeCStructWrapper: public SomeCStruct
{
 public:
    SomeCStructWrapper(const SomeCStruct& init): SomeCStruct(init) {}
};

MyClass::MyClass()
{
    SomeCStruct instance = { 5, 10 };
    obj = new SomeCStructWrapper(instance);
}

MyClass::~MyClass()
{
    delete obj;
}

void MyClass::foo()
{
    someCFunction(obj);
}
//-----------------------------------------------------------

//-----------------------------------------------------------
// test.cc
//-----------------------------------------------------------
#include "MyClass.hh"

int main()
{
    MyClass obj;
    obj.foo();
}
//-----------------------------------------------------------

  Compiled with:

gcc -Wall -O3 -c SomeCStruct.c
g++ -Wall -O3 MyClass.cc test.cc SomeCStruct.o

  Works just fine.

-- 
                                                          - Warp

Post a reply to this message

Here's another idea - a bit kludgey as well, but what the heck:

   struct MyIDirectFB;
   class dfbScreen
   {
       MyIDirectFB* dfb;
       ...
   };

and in your .cpp:

   struct MyIDirectFB
   {
     IDirectFB data;
   };

Requires a bit more effort in coding, but as I said: what the heck...

Or you might cheat a bit on the compiler, using something like:

   #ifndef _DIRECTFB_H__INCLUDED_
     // (or whatever symbol directfb uses in the header)
     struct IDirectFB;
   #end
   class dfbScreen
   {
       IDirectFB* dfb;
       ...
   };

and include <directfb> from your implementation instead of from your 
header file.

There's more than one way to skin a cat...

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Here's another idea - a bit kludgey as well, but what the heck:

>    struct MyIDirectFB;
>    class dfbScreen
>    {
>        MyIDirectFB* dfb;
>        ...
>    };

> and in your .cpp:

>    struct MyIDirectFB
>    {
>      IDirectFB data;
>    };

  Inheritance achieves the exact same thing, except that it makes MyIDirectFB
to be of type IDirectFB directly.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>>  > class dfbScreen::MyIDirectFB: public IDirectFB
> 
>> I'm not sure what this means, but I'm pretty sure it's not going to work 
>> well. :-) DirectFB is all built on top of C, with fake OO stuff, so there's 
>> no way to get one of these for real.
> 
>   Why wouldn't it work? 

I'm not sure what I was thinking of. I'll have to look at this again (and 
look up some syntax to see what "x::y : z" means :-) when I'm not at the end 
of a day.

-- 
   Darren New, San Diego CA, USA (PST)
   I ordered stamps from Zazzle that read "Place Stamp Here".

Post a reply to this message

clipka wrote:
> Darren New schrieb:
>>
>> What I'm doing right now is declaring
>> struct _IDirectFB; struct _IDirectFBFont; ...
>> class dfbScreen {
>>   struct _IDirectFB* dfb;
>>   struct _IDirectFBFont* font;
>>   ...
>> }
>>
>> But that seems wrong, given that I have to grope around in someone 
>> else's headers to pull out private declarations to make it possible to 
>> compile a header that doesn't depend on those declarations.
> 
> Yes, that's why you normally /do/ include the headers... after all, 
> that's what they are for.

It seems wrong that I should have to expose the DirectFB declarations to 
classes that don't care about the directfb declarations, simply because the 
private parts of one of the classes they use has a pointer to something in 
the directfb libs. That's what's the "seems wrong" part.


> I'm not sure, but you might also be able to directly use
>     struct IDirectFB;

IDirectFB isn't a struct or a class. It's a typedef. Therein lies the problem.

> Unfortunately, C++ doesn't natively make a good job at separating 
> interface from implementation (the bane of allowing direct access to 
> data members, and "inlining" of classes as data members).

Yeah. Plus having to declare everything *and* define it.

> Speaking of interfaces, you might make dfbScreen abstract (serving as 
> what would usually be declared as an interface in Java), so that you can 
> keep the actual implementation of it in the background - private data 
> members included.

What I did for the "real" library interface was to have a Player and a 
Player_p object, and the Player.h forward-declared Player_p and the 
Player.cpp included the actual definition. It's just an extra level of 
indirection and another header file and such, which seemed unnecessary for a 
unit-test helper function. (Only the fact that I expect to have to do unit 
tests for multiple GUI bits drove me to make it separate from the unit tests 
to start with, and then I got sidetracked down to figuring out how to do it 
better. :-)

-- 
   Darren New, San Diego CA, USA (PST)
   I ordered stamps from Zazzle that read "Place Stamp Here".

Post a reply to this message

Warp wrote:
>   Why wouldn't it work? 

Hmmm. I remember.
You get an IDirectFB by calling
   IDirectFB* myIDFB;
   good = DirectFBCreate(&myIDFB);
You get a "screen" by calling
   IDirectFBScreen* myIDFBScreen;
   good = myIDFB->GetScreen(myIDFB, this, that, &myIDFBScreen);

In other words, DirectFB is allocating and initlaizig the space, as well as 
filling in pointers (like the GetScreen pointer) for each one, and then 
putting the space it allocated into the pointer whose address you passed in.

I'm not sure how to cleanly turn that into a class without wrapping every 
single function. None of those functions take a pointer to your own class, 
so there's a bunch of casting on every creation at a minimum, and you have 
to hope your class is laid out the same as the parent struct and all that.

Maybe it'll work, but it's 9 hours of working on this stuff today already, so...

-- 
   Darren New, San Diego CA, USA (PST)
   I ordered stamps from Zazzle that read "Place Stamp Here".

Post a reply to this message

Darren New schrieb:

> I'm not sure how to cleanly turn that into a class without wrapping 
> every single function. None of those functions take a pointer to your 
> own class, so there's a bunch of casting on every creation at a minimum, 
> and you have to hope your class is laid out the same as the parent 
> struct and all that.

Fun fact about structs in C++: They /are/ classes. Only major difference 
(IIRC) being that their members default to "public:".

Classes only start to really diverge from classic C structs when you go 
for stuff like virtual methods or multiple inheritance. In the former 
case there'll be a few hidden data members that C++ will automatically 
add, while in the latter case... heck, I have not the slightest clue :-)

Post a reply to this message

Darren New schrieb:

>> Unfortunately, C++ doesn't natively make a good job at separating 
>> interface from implementation (the bane of allowing direct access to 
>> data members, and "inlining" of classes as data members).
> 
> Yeah. Plus having to declare everything *and* define it.

No, you can pretty much mash that all together (not that I'd advocate 
it, because /then/ you really need to give up ever inch of 
implementation-hiding.)

Post a reply to this message

clipka wrote:
> No, you can pretty much mash that all together (not that I'd advocate 
> it, because /then/ you really need to give up ever inch of 
> implementation-hiding.)

I guess if you really want to recompile your entire library inside every 
source file that uses any of it, yah.

Besides, I'm not sure Qt works that way. It has to run a preprocessor on 
stuff, and putting code in .h files is a good way to make that not work.

-- 
   Darren New, San Diego CA, USA (PST)
   I ordered stamps from Zazzle that read "Place Stamp Here".

Post a reply to this message

clipka wrote:
> Fun fact about structs in C++: They /are/ classes. Only major difference 
> (IIRC) being that their members default to "public:".

That much I knew already. But I don't know if C structs are C++ structs for 
sure. :-)

-- 
   Darren New, San Diego CA, USA (PST)
   I ordered stamps from Zazzle that read "Place Stamp Here".

Post a reply to this message