Discovering C++ Idioms in BREW

CodeGuru | Gamelan | Jars | Wireless | Discussions

Architecture & Design

Database

Java

Languages & Tools

Microsoft & .NET

Open Source

Project Management

Security

Techniques

Voice

Web Services

Wireless/Mobile

XML

New Videos

Technology Jobs

Developer.com Webcasts:

   The Impact of Coding Standards and Code Reviews

   Project Management for the Developer

   Defining Your Own Software Development Methodology

   more Webcasts...

See The Winners!

Local Guides

Architecture & Design
Database
Java
Languages & Tools
Microsoft & .NET
Open Source
Project Management
Security
Techniques
Wireless

Be a Commerce Partner

•Apple's iPhone SDK Off to The Races    March 12, 2008
•Sales Data, New Challengers Don't Bode Well For Moto    February 28, 2008
•iPhone Grabs Market Share, But Not Yet in The Enterprise    February 6, 2008
•Open Wireless Network Looms on Horizon    February 1, 2008

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

Tools:

Add www.developer.com to your favorites

Add www.developer.com to your browser search box
IE 7 | Firefox 2.0 | Firefox 1.5.x
Receive news via our XML/RSS feed

BREW Archives