![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
clipka <ano### [at] anonymous org> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Darren New <dne### [at] san rr com> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Warp wrote:
> Darren New <dne### [at] san rr com> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |