 |
Download these IBM resources today!
e-Kit: IBM Rational Systems Development Solution
With systems teams under so much pressure to develop products faster, reduce production costs, and react to changing business needs quickly, communication and collaboration seem to get lost. Now, theres a way to improve product quality and communication.
Webcast: Asset Reuse Strategies for Success--Innovate Don't Duplicate!
Searching for, identifying, updating, using and deploying software assets can be a difficult challenge.
eKit: Rational Build Forge Express
Access valuable resources to help you increase staff productivity, compress development cycles and deliver better software, fast.
Download: IBM Data Studio v1.1
Effectively design, develop, deploy and manage your data, databases, and database applications throughout the data management life.
eKit: Rational Asset Manager
Learn how to do more with your reusable assets, learn how Rational Asset Manager tracks and audits your assets in order to utilize them for reuse.
|
|
 |
 |
  |
|
|
|
|
Discovering C++ Idioms in BREW
By Radu Braniste
Go to page: 1 2 Next
The following is a non-exhaustive list of recurring idioms in BREW, considered mainly from a C++ perspective. This is by no means a new enterprise, but the existing information is mostly scattered in articles, the BREW Forum[1], or knowledge bases[2][3]. The initial title was "Design Patterns in BREW," but the term "idiom" was finally preferred, largely because idioms are defined as low-level patterns specific to one language and this is exactly what this article wants to be about. Two of the idioms presented in this installment, "Stack Starvation" and "EverLoad," are fairly common and their implementation is (almost) trivial. The third one, "Static Is Dynamic," needs more attention and raises some interesting problems.
Stack Starvation
Problem:
- How can one keep stack usage to a minimum?
Context:
- Automatic variables have to be created on the stack.
Forces:
- Allocation on the stack is fast, safe (automatic deallocation), and convenient[4]
- But, most devices have a relatively small stack
- The BREW stack is usually very limited and easy to overrun
Solution:
- Use dynamic allocation (see EverLoad).
- Avoid recursion.
- Avoid passing parameters by value.
Example:
struct STR{...};
bool f(/*const STR s - it copies STR on stack*/ const STR& s )
{
//char a[300]; avoid, expensive
char* a = new char[300];
//while (f(s)) {}; recursion
delete[] a; //don't forget to deallocate - error prone
}
Resulting Context:
- Overrunning the stack was avoided.
- But, additional memory handling (error prone) is needed. This can add to memory fragmentation. Using Smart Pointers or reusing pre-allocated memory (Pooled Allocation)[4] might be beneficial.
Related Patterns:
Smart Pointers, Pooled Allocation, Variable Allocation, EverLoad
Static Is Dynamic
Problem:
- How does one emulate static semantics in BREW?
Context:
- Static variables are not allowed in BREW
Forces:
- Static variables share data between instances of the same class
- There are patterns and libraries based on static variables
- Emulating static behavior is a compromise; there is nothing like the real thing
Solution:
- The entry point class (application class) is a Singleton; use it to store all the data that has to be shared.
- Use GETAPPINSTANCE to statically access the application class.
- Wrap "static" data if better static semantics are needed.
Example:
Cppapp is the application class in subsequent examples.
class CPPApp : public AEEApplet
{
//other members omitted for brevity
//... ...
public:
static CPPApp* getInstance()
{
return (CPPApp*)GETAPPINSTANCE();
}
private:
CPPApp( const CPPApp&);
const CPPApp& operator=( const CPPApp&);
private:
int sharedValue;
friend Singleton;
Singleton * b_;
};
boolean CPPApp::OnAppInitData()
{
b_ = new Singleton (2);
//...
return TRUE;
}
void CPPApp::OnAppfreeData()
{
delete b_;
//....
}
struct Singleton
{
static Singleton * getInstance()
{
CPPApp* c = CPPApp::getInstance();
return c->b_;
}
int getValue()
{
return i_;
}
private:
friend CPPApp;
Singleton (int i) : i_(i)
{}
private:
int i_;
};
struct Test
{
void test1()
{
Singleton * b = Singleton::getInstance();
b->getValue();
Singleton * bb = Singleton::getInstance();
bb->getValue();
// Singleton * bbb = new Singleton (11); //doesn't compile
}
static int& shared()
{
return CPPApp::getInstance->sharedValue;
}
};
The reference returned by shared() behaves fundamentally like a static value. Because there is only one instance of CPPApp, there will be only one instance of sharedValue and implicitly one value for the refernce returned by shared().
There are problems with this approach, as we will see later, but the overall the solution is satisfactory.
Let's see how this applies to Singleton, a pattern based on an internally kept static instance[5][6]. Usually, we express a Singleton like this:
struct Singleton
{
static Singleton* getInstance()
{
if (!instance_ )
instance_ = new Singleton;
return instance_;
}
private:
static Singleton* instance_;
private:
Singleton(){}
};
Singleton* Singleton::instance_ = 0;
Go to page: 1 2 Next
|
IE 7
Firefox 2.0
