This seems a bit of a stumper to me.

I'm trying to set up a simple class (for testing) that just initializes 
directfb. So I have this header file:

class dfbScreen
{
    IDirectFB* dfb;
    IDirectFBScreen* screen;
    IDirectFBFont* font;
      ....
    public:
       void openscreen();
       void closescreen();
       dfbScreen(); ~dfbScreen();
}

Now, of course, the implementation of those need to know the actual 
declarations of IDirectFB, IDirectFBFont, and so on. But everything in 
DirectFB is done with pointers, so you never actually declare a IDirectFB 
value as a value, only as a pointer.

So what do I need to put before "class dfbScreen" such that I can include 
just that class header file (without #include <directfb.h>) such that it 
compiles, given that directfb.h includes lines like
   typedef struct _IDirectFB IDirectFB;
   typedef struct _IDirectFBFont IDirectFBFont;
and so on?

If I put "class IDirectFB;" in front, it tells me that's a redeclaration 
when I include <directfb.h>.  If I don't, it tells me IDirectFB isn't defined.

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.

I tried googling, but I didn't really find any clear answer.

The other choice is to make it into a separate class and add another level 
of indirection, but that too seems like a solution to what shouldn't be a 
problem?

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

Post a reply to this message

You stumbled across a limitation of C++: You cannot pre-declare typedeffed
types because typedef doesn't create a real type, and there's currently no
way of saying that "xyz is a typedeffed name, but don't mind what it actually
is an alias for" (like you can do for classes and structs).

  I'm afraid there are only ugly solutions to that problem. The least ugly
of them would be to simply #include that header.

  (A very ugly solution would be to use void pointers, and then reinterpret
cast them as needed. But if you are determined to not to have to #include
that header, then that's something that would work.)

-- 
                                                          - Warp

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
>   (A very ugly solution would be to use void pointers, and then reinterpret
> cast them as needed. But if you are determined to not to have to #include
> that header, then that's something that would work.)

  I thought of another uglyish kludge that might work and, while kludgey,
not necessarily as ugly as the void pointers:

// Header:
class dfbScreen
{
    class MyIDirectFB
    MyIDirectFB* dfb;
...
};

// Source file:
class dfbScreen::MyIDirectFB: public IDirectFB
{
 /* If IDirectFB supports copying, you can just implement a constructor
    here which takes an instance of type IDirectFB in order to initialize
    objects of type MyIDirectFB, like:

    MyIDirectFB(const IDirectFB& init): IDIrectFB(init) {}

    If IDirectFB does not support copying, then you'll have to replicate
    its constructors here. No way of automatizing that until the next C++
    standard gets implemented in compilers.
  */
};

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>   I'm afraid there are only ugly solutions to that problem. The least ugly
> of them would be to simply #include that header.

Yeah. This is supposed to support numerous underlying technologies, so 
including that header would fail when that class started using something 
other than DFB. For now, putting the "struct _IDirectFB" into the private 
part is probably better.

>   (A very ugly solution would be to use void pointers, and then reinterpret
> cast them as needed. But if you are determined to not to have to #include
> that header, then that's something that would work.)

Before that, i'd just add an extra layer of indirection to my own private 
type that was just the pile of pointers.

 > 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.

Anyway, thanks for your help. I've got a satisfactory kludge. I was just 
hoping there was something less obviously kludgey I was missing.

-- 
   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:
> 
> 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.

I'm not sure, but you might also be able to directly use

     struct IDirectFB;

instead of

     class IDirectFB;

> The other choice is to make it into a separate class and add another 
> level of indirection, but that too seems like a solution to what 
> shouldn't be a 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).

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.

Post a reply to this message

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

Darren New schrieb:
> 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. :-)

Well, C structs are fully compatible to C++ structs, aren't they? You 
can link a C++ program against any C library; and you can compile a C 
library with a C++ compiler, and still link it to a C program. So...?

Post a reply to this message

clipka wrote:
> Well, C structs are fully compatible to C++ structs, aren't they?

Aren't they?  That's what I understood the intent to be, but I'm not sure I 
ever looked it up definitively. :-) Good to know.

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

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> 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 :-)

  Firstly, C++ structs are enormously different from C structs in that C++
structs are, in fact, C++ classes. The *only* difference between a struct
and a class is default accessibility of members (iow. if access rights are
not specified, members will be by default private in a class but public in
a struct). This means that you can add a whole lot of things to a C++ struct
which you cannot to a C struct, such as constructors, a destructor, assignment
and other operators, member functions, and public/protected/private access
right specifiers.

  But secondly, if you *inherit* from a C-style struct (POD), this base
part will still be a basic struct even if you use things like virtual
methods or multiple inheritance in the derived class. In other words,
if something expects a pointer to an object of the struct type, you can
pass it a pointer to an object of the derived type and it will work just
fine. The inherited class using things like virtual functions and multiple
inheritance does not affect the base struct part.

-- 
                                                          - Warp

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> I'll have to look at this again (and 
> look up some syntax to see what "x::y : z" means :-)

  That might surprise many beginner and mid-level C++ programmers, but
there's nothing special going on there. You can pre-declare an inner
class and declare it later. The "x::y" part simply means "class y inside
class x". And the ": z" part means, of course, inheritance from z.

  In other words, this is perfectly valid (and quite handy):

class A
{
    class B;
    ...
};

class A::B
{
    ...
};

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> I'll have to look at this again (and 
>> look up some syntax to see what "x::y : z" means :-)
> 
>   That might surprise many beginner and mid-level C++ programmers, but
> there's nothing special going on there.

Oh! OK. Heh. I don't think I've ever had the pleasure of needing or using 
inner classes before, in any language, so it didn't leap out at me.

Oh! And A::B means class B inside class A, not class A inside class B. Wow, 
that confused me for a bit.

I see that. Yes, that could work cleanly, if I wanted to redeclare every 
function exported by DirectFB. Easier to kludge it in *this* case, but I'll 
remember the trick for another time where I'm writing actual production 
code. :-)

(Indeed, I'm doing the same thing with the "Player" vs "Player_private" 
except I'm not making it an inner class. I'll have to think if that would 
help anything.)


-- 
   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:
> The inherited class using things like virtual functions and multiple
> inheritance does not affect the base struct part.

Cool. Not even C# manages that. (You can't put virtual methods on a value 
class.) Another win for C++ MI.

-- 
   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 <dne### [at] sanrrcom> wrote:
> Oh! OK. Heh. I don't think I've ever had the pleasure of needing or using 
> inner classes before, in any language, so it didn't leap out at me.

  Why not? It aids in limiting the visibility of types, and thus increases
modularity. If a class uses a helper class which is completely exclusive
to that class (and might even be a friend), then it makes sense that the
helper class is defined as a private inner class.

-- 
                                                          - Warp

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> Darren New <dne### [at] sanrrcom> wrote:
> > Oh! OK. Heh. I don't think I've ever had the pleasure of needing or using 
> > inner classes before, in any language, so it didn't leap out at me.

>   Why not? It aids in limiting the visibility of types, and thus increases
> modularity. If a class uses a helper class which is completely exclusive
> to that class (and might even be a friend), then it makes sense that the
> helper class is defined as a private inner class.

  Forgot to mention practical examples.

  Ever wondered what, for example, std::list<int>::iterator is? Well,
surprisise surprise, it's an inner class inside std::list<int>. It's so
related to std::list that it makes a lot of sense to make it an inner class.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> Oh! OK. Heh. I don't think I've ever had the pleasure of needing or using 
>> inner classes before, in any language, so it didn't leap out at me.
> 
>   Why not? 

I just haven't needed it. In languages where there's specific header files 
(i.e., C and C++), I don't include the header file for the child class. In 
languages where there's specific support for the concept (C#) I use the 
internal visibility. I haven't done much in Java since they invented inner 
classes, but those aren't really "invisible" so much as obsfucated anyway, 
so there didn't seem to be a benefit there either.

I.e., everyone already has modular visibility controls, so putting it inside 
a class rather than a namespace didn't seem worthwhile.

> It aids in limiting the visibility of types, and thus increases
> modularity. If a class uses a helper class which is completely exclusive
> to that class (and might even be a friend), then it makes sense that the
> helper class is defined as a private inner class.


Yes it does. I didn't say it was bad. I just said I never found the need to 
use one. The existent mechanisms were already sufficient.


-- 
   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 wrote:
> Yes it does. I didn't say it was bad. I just said I never found the need 
> to use one. The existent mechanisms were already sufficient.

Altho your point of a public class with an embedded iterator is a good one. 
I even expect C# uses embedded classes to implement that in the libraries, 
now that you mention it. Of course, the name isn't exposed outside the class 
in any way, so it's hard to tell without reading actual source code. 
Instead, there's a call called "getEnumerator" or something on the 
collection that returns something that inherits the Enumerator interface or 
some such. You don't directly instantiate an iterator, but rather ask the 
class for one.

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

Post a reply to this message