Thread: List of functions

Yes. And also, no.
You can use function pointers. That way you can store the addresses to the function in a list and call them later. But they must share the same signature. Otherwise you have to figure out the correct signature for the function later on and do casts. Nasty stuff, and error prone.

The short answer is not because it's difficult, but because C wasn't designed for it. It's not the goal of the language, so to speak.
I don't have a solution yet. I must think on this, and I don't think I have time at the moment.
But consider a higher level language, such as C++ if you still need to stay close to the hardware. It will simplify things a bit, albeit perhaps not completely fix.

Now then, the question is: why do you need this? It obviously is tricky to implement and when it's tricky to implement, often it is a sign that you're going about something the wrong way.

I can't use C++, because compiler might not be available for that hardware. I would rather stay in ANSI C domain and use assembler language instead (should I?)

I use SQLite database ( http://www.sqlite.org/c3ref/column_blob.html ). It's easy to implement when you do not care about the speed, but when you have thousands of records each if matters.

I don't think machine language will help you here...

Yes you can. Although you're going around it the wrong way.

Code:

zac@neux:~ (0) $ gcc -o example code.c
zac@neux:~ (0) $ ./example 
item[0] = String value
item[1] = 64
item[2] = 3.141000
zac@neux:~ (0) $ cat code.c 
#include <stdio.h>
#include <stdlib.h>

enum types_tag
{
   TYPE_STRING = 0,
   TYPE_REAL,
   TYPE_INT
};

struct database_tag
{
   enum types_tag type;     /* type of value held */
   union
   {
      int integer;
      double real;
      char * stringValue;
   } value;
};


const char * stringize_value(const struct database_tag * db)
{
   static char buffer[256] = {0};      /* large enough for stringized real or int */
   char * ret = NULL;

   switch(db->type)
   {
      case TYPE_INT:
         sprintf(buffer, "%d", db->value.integer);
         ret = buffer;
      break;

      case TYPE_REAL:
         sprintf(buffer, "%f", db->value.real);
         ret = buffer;
      break;

      case TYPE_STRING:
         ret = db->value.stringValue;
      break;

      /* unknown type */
      default:
         ret = "unknown type";
   }

   return ret;
}

int main(void)
{
   size_t i = 0;
   struct database_tag items[] = {  {TYPE_STRING, 0},
                                    {TYPE_INT, 0},
                                    {TYPE_REAL, 0}};
   items[0].value.stringValue = "String value";
   items[1].value.integer = 64;
   items[2].value.real = 3.141;

   for(i = 0; i < (sizeof items / sizeof items[0]); ++i)
   {
      printf("item[%lu] = %s\n", (unsigned long int) i, stringize_value(&items[i]));
   }

   return 0;
}

In asm I'd put params on the stack and would fetch them from there.

Thanks for example, but you still use switch. In my case it would be switch for each cell in the table.

Originally Posted by Alh

In asm I'd put params on the stack and would fetch them from there.

... as what size/type?

Originally Posted by Alh

The size of data would depend on the arch (4 bytes on x86). The type depends on how your asm subprogram will interpret data.

If that's all you think is to it, then I certainly wouldn't recommend it. It wouldn't work anyway. How would you know what type to interpret the argument at when you pop off at the caller? Or whatever calling convention your compiler/OS is using (yet another consideration). And you've already made it compiler specific, assembler specific and machine specific. All for a simple return value, pfft!

Is there anything wrong with the idea I posted?

If the function knows what data to expect, why not just return void* and be done with it!?!

Because SQLite API return types are not void* (char*, int, double). I can not return a pointer when it's an int.

Originally Posted by Alh

Thanks for example, but you still use switch. In my case it would be switch for each cell in the table.

As in the switch will be tested for each cell in the table?