static function tables

static function tables

[Ken]

What's the right way to do static tables containing function pointers in
C++?

I have an embedded C app that parses a command from a host and looks it
up in a group of tables. Each table represents an array of related
commands. It contains an 8-byte char[] of the command, a parameter
count, some flags, and a pointer to the function that handles that
command. There are several such tables, linked in based on what feature
set a given app will have.

When I move this app to C++, what's a reasonable OOP-ish way of handling
these tables?

To make command-lookup fast, a table is alphabatized and coded in
assembler (so that I can place labels within the array) and a parallel
26-word array of pointers points to the first command starting with a
given letter. Any suggestions for improvement? A typical table might
have 20-100 commands and an app might have 3-10 tables.

-- 
Ken
mailto:shiva@well.com
mailto:shiva@CompuServe.COM
http://www.well.com/user/shiva/
http://sewnsurf.home.ml.org/
http://www.e-scrub.com/cgi-bin/wpoison/wpoison.cgi (Death to Spam!)

Re: static function tables

[Todd Hoff]

Ken wrote:
> 
> What's the right way to do static tables containing function pointers in
> C++?
> 
> I have an embedded C app that parses a command from a host and looks it
> up in a group of tables. Each table represents an array of related
> commands. It contains an 8-byte char[] of the command, a parameter
> count, some flags, and a pointer to the function that handles that
> command. There are several such tables, linked in based on what feature
> set a given app will have.
> 
> When I move this app to C++, what's a reasonable OOP-ish way of handling
> these tables?

How about not using function pointers? Maybe use a table of command
objects instead? You could have a base command class then
derive more specific commands from these. The table would
contain pointers to command objects so you could treat all
the command the same but the behaviour would be that of the
derived class. Not sure if this fits your app but if it works
it is better than using function pointers. Function pointers
should be very rare in a c++ app.


------------------------------------------------------------------
      tmh@possibility.com   http://www.possibility.com/Tmh
   Desperate measures require the invention of desperate times. 
      -- Todd Hoff

Re: static function tables

[Ken]

Todd Hoff wrote:
> 
> Ken wrote:
> >
> > What's the right way to do static tables containing function pointers in
> > C++?
> >
> > I have an embedded C app that parses a command from a host and looks it
> > up in a group of tables. Each table represents an array of related
> > commands. It contains an 8-byte char[] of the command, a parameter
> > count, some flags, and a pointer to the function that handles that
> > command. There are several such tables, linked in based on what feature
> > set a given app will have.
> >
> > When I move this app to C++, what's a reasonable OOP-ish way of handling
> > these tables?
> 
> How about not using function pointers? Maybe use a table of command
> objects instead? You could have a base command class then
> derive more specific commands from these. The table would
> contain pointers to command objects so you could treat all
> the command the same but the behaviour would be that of the
> derived class. Not sure if this fits your app but if it works

> it is better than using function pointers. Function pointers
> should be very rare in a c++ app.

Agreed. Constant function pointers in a struct are usually an indication
that one needs a virtual method. I've used this idiom in an OS/2
application where I have plenty of virtual memory to play with.

The catch in this case is that the objects are static, and this is a
memory-limited embedded system where I don't want to copy a const array
of structures in ROM into equivalent C++ structures in RAM. This is kind
of a general problem in using C++ in a memory-limited environment. There
are cases where it would be nice to initialize static const C++ objects
at compile or link time (on the host) rather than just before main() (on
the target).

I've seen a trick lately (I think in Embedded Systems Programming) where
one exposes a C++ class that defines an internal private struct for the
static const data. Something like

 class public_class
 {
 private:
     struct static_data { ... };
     static const static_data data[]; // stored in ROM
 };

This looks applicable to the situation.

-- 
Ken
mailto:shiva@well.com
mailto:shiva@CompuServe.COM
http://www.well.com/user/shiva/
http://sewnsurf.home.ml.org/
http://www.e-scrub.com/cgi-bin/wpoison/wpoison.cgi (Death to Spam!)

Re: static function tables

[Todd Hoff]

Ken wrote:

> The catch in this case is that the objects are static, and this is a
> memory-limited embedded system where I don't want to copy a const array
> of structures in ROM into equivalent C++ structures in RAM. This is kind
> of a general problem in using C++ in a memory-limited environment. 

I would be inclined to overload the new operator and take the memory
out of a static array or some other fixed source. Best of both worlds.
In fact, in a memory constrained system i would overload the global
new and allocate memory from pools of fixed sized buffers. Works
best i think.

>There
> are cases where it would be nice to initialize static const C++ objects
> at compile or link time (on the host) rather than just before main() (on
> the target).

Some say potatoes...

> I've seen a trick lately (I think in Embedded Systems Programming) where
> one exposes a C++ class that defines an internal private struct for the
> static const data. Something like
> 
>  class public_class
>  {
>  private:
>      struct static_data { ... };
>      static const static_data data[]; // stored in ROM
>  };
> 
> This looks applicable to the situation.

This is the pimple pattern or the handle pattern. Works fine.
Just better make sure your rom address is correct!

------------------------------------------------------------------
      tmh@possibility.com   http://www.possibility.com/Tmh
   Desperate measures require the invention of desperate times. 
      -- Todd Hoff