I've started making my first plugin class which is a subclass of
another class.
Now, I have a question. Are there any known issues with this?
I've made an assumption during my coding and design, which now I'm
nearing completion, I realise might have been a bad assumption to make.
Basically, I'm assuming that subclassing in RB works like it's
supposed to. In C++, if you subclass something, the struct's fields
will be appended, as if it were one normal class.
So this:
struct a {
int f1;
};
struct b : public a {
int f2;
};
"b" should be the same as if I did this:
struct b {
int f1;
int f2;
};
That's the idea.
But does RB's subclassing work the same way? Does it currently, on
all platforms? Has it always done so on all platforms?
Or must I use the GetClassData (or whatever the macro is called) upon
the REALobject, for each class type? :( Because RB may have put them
ordered backwards or something stupid like that.
More importantly, can I rely on it working the sane normal and
standard way in the future?
Any ideas anyone??
My guess (Without testing) is that RB does it the proper way, but
they'll give me the tired line "don't rely on undocumented behaviour" :(
I suppose the real question (to me), is why on Earth would RB ever
need to do subclassing in anything other than the standard way? If I
can rely on this behaviour, I'd like to assume it's always true.
Otherwise, I must pass around 2 or 3 pointers to some functions when
I really only wanted to access one pointer :(
I do a lot of work on the bare structs, without actually doing so
much work on the REALobject. For speed I prefer passing struct
pointers internally within my plugin. But if I'm to do that, and I
can't rely on subclassing working properly, I'll need to pass each of
the subclass's structs individually. It's ugly.
It'll work, though!! I'd use it if there was no other choice.
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>
