Forums | developer.brewmp.com Forums | developer.brewmp.com

Developer

Forums

Forums:

Is inheritance and polymorphism allowed in Brew. If i use those in my Brew code Microsoft VC++ would not flag those as errors i think but will ARM compiler flag those as errors.
Also is new operator present in Brew. How do u compile the Brew code for an actual device. Should i be using ARM compiler to compile the code.

keshav

Yes inhertance and polymorphism is allowed. You have to use the Arm or thumb C++ compiler for the device. Remember NOT to put any default constructor in your class and to override new and delete operators so that they call the MALLOC/FREE or IHeap functions instead of the default. If you use the CppApp example as the basis of your app, then you are all set to go....

Yes inhertance and polymorphism is allowed. You have to use the Arm or thumb C++ compiler for the device. Remember NOT to put any default constructor in your class and to override new and delete operators so that they call the MALLOC/FREE or IHeap functions instead of the default. If you use the CppApp example as the basis of your app, then you are all set to go....

Sorry, but I cannot understand why default constructors are not allowed. Maybe you can explain
Thanks
Radu

Sorry, but I cannot understand why default constructors are not allowed. Maybe you can explain
Thanks
Radu

Yes it is very strange.

Yes it is very strange.

Well, I use polymorphism, inheritance and default constructors as well and everything is working fine.
To achieve that I have defined very simple base class (CBase)which contains overriden new, delete, new[], delete[] operators. All the other classes in my applications are derived from this class.

Well, I use polymorphism, inheritance and default constructors as well and everything is working fine.
To achieve that I have defined very simple base class (CBase)which contains overriden new, delete, new[], delete[] operators. All the other classes in my applications are derived from this class.

That's how we implemented it also with the exception that we actual have a heap module implemented that was originally a carryover from BREW1.0 when we discovered tons of memory fragmentation issues on the sharp phone.
We basically implemented our own new and delete operators that made the underlying malloc calls.
And we've had no problems with inheritance, default constructors, or polymorphism in our implementations, indeed we rely on them a great deal.

That's how we implemented it also with the exception that we actual have a heap module implemented that was originally a carryover from BREW1.0 when we discovered tons of memory fragmentation issues on the sharp phone.
We basically implemented our own new and delete operators that made the underlying malloc calls.
And we've had no problems with inheritance, default constructors, or polymorphism in our implementations, indeed we rely on them a great deal.

Where are you guys storing the AEEApplet data member? In the base class you are deriving from?
We're having trouble moving our game loop from global space into a class. We're calling ISHELL_SetTimer with the gameloop func as the callback and it doesn't like not being static global function. Any ideas?
I have seen default constructors simply not get called with BREW. Maybe they are being constructed before the BREW shell is completed, but it's still enough to make me leery of relying on them.
Thanks.

Where are you guys storing the AEEApplet data member? In the base class you are deriving from?
We're having trouble moving our game loop from global space into a class. We're calling ISHELL_SetTimer with the gameloop func as the callback and it doesn't like not being static global function. Any ideas?
I have seen default constructors simply not get called with BREW. Maybe they are being constructed before the BREW shell is completed, but it's still enough to make me leery of relying on them.
Thanks.

"...We're calling ISHELL_SetTimer with the gameloop func as the callback and it doesn't like not being static global function..."
To call ISHELL_SetTimer the function to be called after the timer must be a static member function inside the class to work well... It has something to do with having or not the this pointer in the method call.

"...We're calling ISHELL_SetTimer with the gameloop func as the callback and it doesn't like not being static global function..."
To call ISHELL_SetTimer the function to be called after the timer must be a static member function inside the class to work well... It has something to do with having or not the this pointer in the method call.

Check out question 2b of the Technical FAQ (qualcomm.com/brew/developer/support/faq/techfaq2.html)
From what I understand, you can use any C++ feature in your classes EXCEPT in the class/struct you use to hold your AEEApplet data. The reason is that it is BREW that allocates memory for it (in AEEApplet_New()) and it uses a MALLOC(), not a 'new', so the constructor is not called. This also implies that this class/struct cannot contain virtual methods or data members with constructors.
Here is what I do in my code:

Derive class AppData from AEEApplet
AppData contains no constructors, no destructors, no virtual functons
AppData contains only pointer type and fundamental type data member
AppData contains Initialize() and Shutdown() methods
I call Initialize() from AEEClsCreateInstance() after AEEApplet_New()
I call AppData::Shutdown() from the shutdown callback

Form the shutdown callback (or anywhere else for that matter), you can use GETAPPINSTANCE() to get the address of your AppData object.

Check out question 2b of the Technical FAQ (qualcomm.com/brew/developer/support/faq/techfaq2.html)
From what I understand, you can use any C++ feature in your classes EXCEPT in the class/struct you use to hold your AEEApplet data. The reason is that it is BREW that allocates memory for it (in AEEApplet_New()) and it uses a MALLOC(), not a 'new', so the constructor is not called. This also implies that this class/struct cannot contain virtual methods or data members with constructors.
Here is what I do in my code:

Derive class AppData from AEEApplet
AppData contains no constructors, no destructors, no virtual functons
AppData contains only pointer type and fundamental type data member
AppData contains Initialize() and Shutdown() methods
I call Initialize() from AEEClsCreateInstance() after AEEApplet_New()
I call AppData::Shutdown() from the shutdown callback

Form the shutdown callback (or anywhere else for that matter), you can use GETAPPINSTANCE() to get the address of your AppData object.

can anyone post a c++ base class for me to look at. It would help me a lot. Thanks

can anyone post a c++ base class for me to look at. It would help me a lot. Thanks

would all i need is something like this?
class CppBase
{
public:
inline void operator delete(void *p) { FREE(p); };
inline void* operator new(size_t sz) { return MALLOC(sz); };
;
and then derive all my classes from that?
I don't suppose they need to be virtual or something?

would all i need is something like this?
class CppBase
{
public:
inline void operator delete(void *p) { FREE(p); };
inline void* operator new(size_t sz) { return MALLOC(sz); };
;
and then derive all my classes from that?
I don't suppose they need to be virtual or something?

i just globally defined a new a delete and this seems to fix a problem i was having with my program running into memory errors.
// file: cppbase.h
#if !defined(_CPPBASE_H_)
#define _CPPBASE_H_
#include "AEEStdLib.h"
inline void operator delete( void *p ) { DBGPRINTF( "delete" ); FREE(p); };
inline void* operator new( size_t sz ) { DBGPRINTF( "new" ); return MALLOC(sz); };
Then i just include this file in all my classes. You should probably overide new[] and delete[] as well.

i just globally defined a new a delete and this seems to fix a problem i was having with my program running into memory errors.
// file: cppbase.h
#if !defined(_CPPBASE_H_)
#define _CPPBASE_H_
#include "AEEStdLib.h"
inline void operator delete( void *p ) { DBGPRINTF( "delete" ); FREE(p); };
inline void* operator new( size_t sz ) { DBGPRINTF( "new" ); return MALLOC(sz); };
Then i just include this file in all my classes. You should probably overide new[] and delete[] as well.

I'm making full use of the C++ language set and features - including inheritance, polymorphism, operator overloading and so forth - and I have yet to find a real problem. For me it's all working just fine.
However, I've never understood why anyone would derive classes from AEEApplet etc. All you have to do is add pointers to your start objects into the AEEApplet structure, instantiate them upon application start up and off you go.

I'm making full use of the C++ language set and features - including inheritance, polymorphism, operator overloading and so forth - and I have yet to find a real problem. For me it's all working just fine.
However, I've never understood why anyone would derive classes from AEEApplet etc. All you have to do is add pointers to your start objects into the AEEApplet structure, instantiate them upon application start up and off you go.

Quote:Originally posted by Dragon
All you have to do is add pointers to your start objects into the AEEApplet structure, instantiate them upon application start up and off you go.
good idea. I think the reason most ppl derive from AEEApplet is because it's in the CPP hello worlds you find on the internet.

Quote:Originally posted by Dragon
All you have to do is add pointers to your start objects into the AEEApplet structure, instantiate them upon application start up and off you go.
good idea. I think the reason most ppl derive from AEEApplet is because it's in the CPP hello worlds you find on the internet.

Actually, you can use objects in your main CApplication object (the one that contains AEEApplet a; as the first entry).
What you need to use is the "placement new" operator, explained in More Essential C++ by Scott Meyers (Item 8, pages 40).
The placement new operator lets you call the constructor without actually allocating the memory.
First, define placement new like this:
void* operator new(size_t, void* location)
{
return location;

Then, in your application_InitAppData function, call:
CApplication* pMe = new(pIApplet) CApplication();
What this does is call your overloaded new operator, which doesn't actually allocate any memory, it just returns pIApplet. Then it calls the constructor on the memory.
Don't forget to call the destructor directly in application_FreeAppData. You can't use delete, because that will free the memory, which you didn't allocate.
pMe->~CApplication();
I've tested and it definitely works...haven't used it in any production code, because the pointer method that Dragon describes works just fine. But I think this method is superior because BREW will allocate a larger block of memory when you application begins, which means you need to deal with run-time out of memory conditions less often (perhaps) and thus your code requires less testing (perhaps).
-Aaron

Actually, you can use objects in your main CApplication object (the one that contains AEEApplet a; as the first entry).
What you need to use is the "placement new" operator, explained in More Essential C++ by Scott Meyers (Item 8, pages 40).
The placement new operator lets you call the constructor without actually allocating the memory.
First, define placement new like this:
void* operator new(size_t, void* location)
{
return location;

Then, in your application_InitAppData function, call:
CApplication* pMe = new(pIApplet) CApplication();
What this does is call your overloaded new operator, which doesn't actually allocate any memory, it just returns pIApplet. Then it calls the constructor on the memory.
Don't forget to call the destructor directly in application_FreeAppData. You can't use delete, because that will free the memory, which you didn't allocate.
pMe->~CApplication();
I've tested and it definitely works...haven't used it in any production code, because the pointer method that Dragon describes works just fine. But I think this method is superior because BREW will allocate a larger block of memory when you application begins, which means you need to deal with run-time out of memory conditions less often (perhaps) and thus your code requires less testing (perhaps).
-Aaron

hey there: did any one use this "placement new" operator approach with a constructor that takes parameters-- and if so was it succesfully compiled by the ARM CPP compiler-- & any surprises in the mobile ???
big thanks to anyone who can comment on this

hey there: did any one use this "placement new" operator approach with a constructor that takes parameters-- and if so was it succesfully compiled by the ARM CPP compiler-- & any surprises in the mobile ???
big thanks to anyone who can comment on this