How to use C-Based object class ?? | developer.brewmp.com How to use C-Based object class ?? | developer.brewmp.com

Developer

How to use C-Based object class ??

hi, all

recently i referred to the applet "inotify" (in sample code from qualcomm). i'm bewildered with inheritance using C-based Object Class in brew, so, somebody can give me a hint of how to create and use C-Based object class ??
is there any resources on the net ? thanks a lot.

michael.

In C++ inheritance is like this:
class base { int basevalue; };
class derived : public base { int derivedvalue; };
where derived.basevalue is a valid thing. In memory, the compiler sets up your "derived" memory block to be an 8-byte block looking like this:
memaddr value
0: basevalue
2: " "
4: derivedvalue
6: " "
In BREW they're doing pretty much the same thing when they say:
struct AEEApplet { /*std brew stuff*/ };
struct MyBREWApplication {
AEEApplet m_app; /* my custom stuff */
;
Because in memory it looks like this:
memaddr value
0: /*std brew stuff */
2: " "
4: " "
...
100: /* my custom stuff */
102: " "
But you have to do MyBREWApplication.m_app.STD_BREW_STUFF to access the "base class" data because there's no handy-dandy "public" keyword that automagically wraps an instance of the base class onto the head of your derived class object's memory block. So in C the reference to the "base class" is explicit (".m_app.").
Does this make sense so far?
Now, your application "MyBREWApplication" sort of inherits all the data values of the AEEApplet. This is because you can access all the AEEApplet data from within your "MyBREWApplication" struct.
In so far as the "interface" concept goes (ISHELL_CreateInstance) all's that's going on there is you are returned a block of memory containing function pointers...4 bytes per function, typed to be pointers to functions, one after the other, packed into an "Interface".
Hmm...is this discussion helpful to you Michael?
-Nick

In C++ inheritance is like this:
class base { int basevalue; };
class derived : public base { int derivedvalue; };
where derived.basevalue is a valid thing. In memory, the compiler sets up your "derived" memory block to be an 8-byte block looking like this:
memaddr value
0: basevalue
2: " "
4: derivedvalue
6: " "
In BREW they're doing pretty much the same thing when they say:
struct AEEApplet { /*std brew stuff*/ };
struct MyBREWApplication {
AEEApplet m_app; /* my custom stuff */
;
Because in memory it looks like this:
memaddr value
0: /*std brew stuff */
2: " "
4: " "
...
100: /* my custom stuff */
102: " "
But you have to do MyBREWApplication.m_app.STD_BREW_STUFF to access the "base class" data because there's no handy-dandy "public" keyword that automagically wraps an instance of the base class onto the head of your derived class object's memory block. So in C the reference to the "base class" is explicit (".m_app.").
Does this make sense so far?
Now, your application "MyBREWApplication" sort of inherits all the data values of the AEEApplet. This is because you can access all the AEEApplet data from within your "MyBREWApplication" struct.
In so far as the "interface" concept goes (ISHELL_CreateInstance) all's that's going on there is you are returned a block of memory containing function pointers...4 bytes per function, typed to be pointers to functions, one after the other, packed into an "Interface".
Hmm...is this discussion helpful to you Michael?
-Nick

Why don't you use C++? This works:
struct MyApplet: public AEEApplet
{
;
You just have to remember that even if you give it a constructor, it won't run because AEEApplet_New() allocates it instead of instantiating the object.
It's a shame BREW doesn't use an application factory method to instantiate the applet, so then it wouldn't matter if we were using C++ or C. It's not like they didn't know about factory methods, e.g. ISHELL_CreateInstance().
--t

Why don't you use C++? This works:
struct MyApplet: public AEEApplet
{
;
You just have to remember that even if you give it a constructor, it won't run because AEEApplet_New() allocates it instead of instantiating the object.
It's a shame BREW doesn't use an application factory method to instantiate the applet, so then it wouldn't matter if we were using C++ or C. It's not like they didn't know about factory methods, e.g. ISHELL_CreateInstance().
--t

Just out of curiosity, why do you derive from AEEApplet at all? Most of my apps are in C++ but I have yet to derive anything from AEEApplet. I'm not sure I see what the point is?

Just out of curiosity, why do you derive from AEEApplet at all? Most of my apps are in C++ but I have yet to derive anything from AEEApplet. I'm not sure I see what the point is?

Yeah you can do it the C way too. Doesn't matter.
It sounded like Michael was more comfortable with C++ inheritance rather than doing it C way as Nick described. Of course I could have misinterpreted his post.

Yeah you can do it the C way too. Doesn't matter.
It sounded like Michael was more comfortable with C++ inheritance rather than doing it C way as Nick described. Of course I could have misinterpreted his post.

Quote:Originally posted by Dragon
Just out of curiosity, why do you derive from AEEApplet at all? Most of my apps are in C++ but I have yet to derive anything from AEEApplet. I'm not sure I see what the point is?
You can refer to the AEEApplet members implicitly through "this" and public inheritance lays out the app class in memory as BREW wants it -- i.e. with the AEEApplet part coming first. Further, it models your applet class as "is-a" AEEApplet. I agree that you can also model the relationship using containment, but the former seems more intuitive to me.
You've questioned this before. I got into the habit because that's how Qualcomm's cpp example is set up.
Is there some harmful side effect that I don't know about?

Quote:Originally posted by Dragon
Just out of curiosity, why do you derive from AEEApplet at all? Most of my apps are in C++ but I have yet to derive anything from AEEApplet. I'm not sure I see what the point is?
You can refer to the AEEApplet members implicitly through "this" and public inheritance lays out the app class in memory as BREW wants it -- i.e. with the AEEApplet part coming first. Further, it models your applet class as "is-a" AEEApplet. I agree that you can also model the relationship using containment, but the former seems more intuitive to me.
You've questioned this before. I got into the habit because that's how Qualcomm's cpp example is set up.
Is there some harmful side effect that I don't know about?

Murray,
Thanks for the heads-up. It makes more sense now. I was really just genuinely curious because I simply never saw the need for doing this.

Murray,
Thanks for the heads-up. It makes more sense now. I was really just genuinely curious because I simply never saw the need for doing this.

first, thank you all. it's really helpfull that i learned much and i'm more clear about the difference of inheritance between C and C++, especially from nick's discussion.
as i go through the example code of INotify, i find that the our own notifier is inherit from the interface INotifier, in the following way:
typedef struct _NotifierClass
{
// vtable
DECLARE_VTBL(INotifier)
AEEModObj * pNext;
AEECLSID clsID;// ClassID of notifier class
// data members
uint32 m_nRefs; // Class reference counter
IShell * m_pIShell; // pointer to IShell
IModule * m_pIModule; // pointer to IModule
IDisplay * m_pIDisplay; // pointer to IDisplay
uint32 m_dwNotifyMask; // Used in timer callback function.
NotifierClass;i don't know what the DECLARE_VTBL(INotifier) stand for, and how to inherit from an interface for our own use. and i want to know the ways of inheritance in BREW API really, for example AEEApplet inherits from IApplet, our NotifierClass inherits from INotifier, and so on.
best regards.
-michael

first, thank you all. it's really helpfull that i learned much and i'm more clear about the difference of inheritance between C and C++, especially from nick's discussion.
as i go through the example code of INotify, i find that the our own notifier is inherit from the interface INotifier, in the following way:
typedef struct _NotifierClass
{
// vtable
DECLARE_VTBL(INotifier)
AEEModObj * pNext;
AEECLSID clsID;// ClassID of notifier class
// data members
uint32 m_nRefs; // Class reference counter
IShell * m_pIShell; // pointer to IShell
IModule * m_pIModule; // pointer to IModule
IDisplay * m_pIDisplay; // pointer to IDisplay
uint32 m_dwNotifyMask; // Used in timer callback function.
NotifierClass;i don't know what the DECLARE_VTBL(INotifier) stand for, and how to inherit from an interface for our own use. and i want to know the ways of inheritance in BREW API really, for example AEEApplet inherits from IApplet, our NotifierClass inherits from INotifier, and so on.
best regards.
-michael

Glad to be helpful to somebody!
The DECLARE_VTBL(INotifier) is doing is this inheritance stuff above: adding one class's methods into another class. It allows you to say "derived.basevalue" in your code, except here it will be called NotifierClass.vtINotifier. (I think it's "vtINotifier"... :rolleyes: )
BREW's AEE.h file has the definition for that macro:
#define DECLARE_VTBL(iname) iname vt##iname;
When compiled, that macro will translate in your "NotifierClass" to:
typedef struct _NotifierClass
{
//vtable
INotifier vtINotifier; <<<<<< HERE
AEEModObj * pNext;
...
NotifierClass;
So you get a new INotifier member named "NotifierClass.vtINotifier". This is inheritance because your NotifierClass gets access to INotifier.
Does this help?

Glad to be helpful to somebody!
The DECLARE_VTBL(INotifier) is doing is this inheritance stuff above: adding one class's methods into another class. It allows you to say "derived.basevalue" in your code, except here it will be called NotifierClass.vtINotifier. (I think it's "vtINotifier"... :rolleyes: )
BREW's AEE.h file has the definition for that macro:
#define DECLARE_VTBL(iname) iname vt##iname;
When compiled, that macro will translate in your "NotifierClass" to:
typedef struct _NotifierClass
{
//vtable
INotifier vtINotifier; <<<<<< HERE
AEEModObj * pNext;
...
NotifierClass;
So you get a new INotifier member named "NotifierClass.vtINotifier". This is inheritance because your NotifierClass gets access to INotifier.
Does this help?

Why is it when I try something like this:
class IApplication : public AEEApplet {...};
class cppApp : public IApplication {...};
I get a memory access error when brew tries to execute the handleevent in the cppApp class. I checked on the memory and it seems like all the varibles are a byte or so off from what they would be on a single inheritance.
Does brew not allow for multiple inheritance on it's AEEApp since it has a specific place it puts it's variables? Is there a work around? Please let me know! Thanks for the help!
Ben

Why is it when I try something like this:
class IApplication : public AEEApplet {...};
class cppApp : public IApplication {...};
I get a memory access error when brew tries to execute the handleevent in the cppApp class. I checked on the memory and it seems like all the varibles are a byte or so off from what they would be on a single inheritance.
Does brew not allow for multiple inheritance on it's AEEApp since it has a specific place it puts it's variables? Is there a work around? Please let me know! Thanks for the help!
Ben

Quote:Originally posted by btripoli
class IApplication : public AEEApplet {...};
class cppApp : public IApplication {...};
I get a memory access error when brew tries to execute the handleevent in the cppApp class. I checked on the memory and it seems like all the varibles are a byte or so off from what they would be on a single inheritance.
Does brew not allow for multiple inheritance?Hi Ben,
Strictly speaking, you're doing single inheritance from a derived class. Multiple inheritance is direct inheritance from multiple base classes.
Anyway, I've done exactly what you're doing and it doesn't give me any problems. Are you sure your event handler is static?
--t

Quote:Originally posted by btripoli
class IApplication : public AEEApplet {...};
class cppApp : public IApplication {...};
I get a memory access error when brew tries to execute the handleevent in the cppApp class. I checked on the memory and it seems like all the varibles are a byte or so off from what they would be on a single inheritance.
Does brew not allow for multiple inheritance?Hi Ben,
Strictly speaking, you're doing single inheritance from a derived class. Multiple inheritance is direct inheritance from multiple base classes.
Anyway, I've done exactly what you're doing and it doesn't give me any problems. Are you sure your event handler is static?
--t

hi...
why we need inherited class form AEEApplet, just including it as class member should serve the perpose....
sdg

hi...
why we need inherited class form AEEApplet, just including it as class member should serve the perpose....
sdg

Quote:Originally posted by sdg
why we need inherited class form AEEApplet, just including it as class member should serve the perpose....This is discussed in the thread above, 'spesh the posts by Murray and Dragon.

Quote:Originally posted by sdg
why we need inherited class form AEEApplet, just including it as class member should serve the perpose....This is discussed in the thread above, 'spesh the posts by Murray and Dragon.