Discovering C++ Idioms in BREW

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;

A Singleton should not be directly instantiated (that’s why the private constructor) and obviously getInstance() returns the same instance. Let’s see how this translates in BREW. Singleton has a unique instance, kept by CPPApp (b_). To access it, Singleton is a friend of CPPApp. On the other hand, the creation of b_ has to be done by CPPApp (in OnAppInitData()) and has to be inhibited at compile time in other contexts (private constructor). This implies that CPPApp has to be a friend of Singleton. An example of using Singleton is presented in test1().

It was mentioned before that simply using CPPApp::sharedValue might create some discomfort for the user. There are some problems with this design:

A proliferation of public variables in CPPApp
Class Test has no real variable sharedValue; it has to create a link between CPPApp::sharedValue and a member static function to mimic this

A more complex design might alleviate these issues:

class CPPApp : public AEEApplet
{
//....
private:
   friend struct Static;
   void* statics[4];    //simple container
};

struct Static
{
   template <class T>
   static typename T::STATIC_TYPE staticValue()
   {
      CPPApp* c = CPPApp::getInstance();
      return *static_cast<typename T::STATIC_TYPE_PTR>
             (c->statics[T::getUID()]);
   }
    template <class T>
   static void  staticValue(const typename T::STATIC_TYPE t)
   {
      CPPApp* c = CPPApp::getInstance();
      c->statics[T::getUID()] = &t;
    }
};

template <class TP>
struct StaticBase
{
   typedef  TP* STATIC_TYPE_PTR;
   typedef  TP& STATIC_TYPE;
};

Static defines the manipulation pattern and StaticBase is a simple policy class for manipulating types. There is a container of static variables in CPPAppp, Every static variable is uniquely identified by type and an unique ID, a simple int in this case. Let’s take, for example, a simple class having two static variables:

struct A  : public Static
{
   StaticA a; 
   StaticB b;
};

This is how the two variables have to be defined to be unique:

struct StaticA : public StaticBase<int>
{
   static size_t getUID()
   {
      return 0;
   }

};

struct StaticB : public StaticBase<int>
{
   static size_t getUID()
   {
      return 1;
   }

};

Now, CPPApp has an automatic way of keeping track of static variables (of course, the array will be replaced by a container in real life). They are strongly typed and user classes now own them:

void test2()
{
   Writer writer;
   int val = 777;
   A::staticValue<StaticA>(val);
   StaticA::STATIC_TYPE i = A::staticValue<StaticA>();
   writer.WriteLine(i);
   i = 2345;
   writer.WriteLine(A::staticValue<StaticA>());
   val = 888;
   A::staticValue<StaticB>(val);
   writer.WriteLine(A::staticValue<StaticB>());
   A::staticValue<StaticB>() = 4567;
   writer.WriteLine(A::staticValue<StaticB>());
}

Resulting Context:

We’ve obtained a behavior consistent with static semantics.
But, additional complexity was added.

EverLoad

Problem:

How does one use the new/delete operator in BREW?

Forces:

BREW doesn’t offer a predefined new/delete global operator
New/delete operators[7] are of significant importance in BREW (see “Stack Starvation” for a reason why heap allocation is unavoidable)

Solution:

Always overload the new/delete operator (always in pairs)
Always overload the new[]/delete[] operator
The new/delete operator can be overloaded at a global scope or class scope. A good rule of the thumb is to implement a global overload and to use class scope for specific memory allocators[4]
Exercise care in switching compilers; there are ANSI/ISO C++ incompatibilities in this area (notably “inline” and operator delete accessibility are pertinent to this topic)[8]

Example:

//global scope
void* operator new(size_t sz);
void operator delete(void *p);

void* operator new[](size_t sz);
void operator delete[](void *p);

class A
{
public:
   static void* operator new(size_t sz);
   static void operator delete(void *p);
//....
}

Related Patterns:

Variable Allocation

What’s Next?

The next article will continue this discussion, presenting other idioms.

References

[1] http://brewforums.qualcomm.com

[2] http://brew.qualcomm.com/brew/en/developer/resources/ds/faq.html

[3] http://brew.qualcomm.com/brew/en/developer/resources/ds/okb.html

[4]

Small Memory Allocation – Part 2
http://www.developer.com/ws/brew/article.php/3323091
Small Memory Allocation – Part 1
http://www.developer.com/ws/brew/article.php/3315011

[5] GOF. Design Patterns: Elements of Reusable Object-Oriented Software, Addison Wesley. 1994

[6] John M. Vlissides. Pattern Hatching: Design Patterns Applied, Addison Wesley. 1998

[7] For a complete discussion of the new/delete operator, see Scott Meyers. More Effective C++, Addison Wesley. 1996

[8] http://fusshuhn.ourfamily.com/cppincomp.html

Download

Download the accompanying code file here (77 Kb).

Discovering C++ Idioms in BREW

Stack Starvation

Static Is Dynamic

EverLoad

What’s Next?

References

Download

Latest Posts

Best Collaboration Tools for Database Developers

Nutcache versus Airtable | Developer.com

Java versus PHP

Advantages and Disadvantages of OOP in Java

Tips for Managing Developers

Related Stories

Advertisers

Menu

Our Brands