Thread: Dynamic array of function pointers

What's macro magic? This isn't a one time solution, when we recompile under different circumstances we may have 4 functions today, 8 tomorrow, 3 the next day etc..It's the nature of the program, each function represents a distinct subroutine needed for a seperate area we are generating. So I want to be able to say, this time we have 4, give me an array that's the size of the day with pointers to all the functions of the day (following a consistent pattern of function0...functionN). Is there some variable way I can do this with macros?

All i really got so far is a switch statement, populating my array up to N times depending on the case. So as of now its limited up to 10 functions (i figured that was a high enough max for now). But it's not a variable/dynamic solution really which I was hoping for. In perl for example you can easily say things like function$variable (where $variable is 0..N), but I guess there's nothing like that in C++.

But also the problem with prototyping these variable functions, this becomes quite difficult without a bunch of conditional preprocessor branches and a single define stating how many functions I will have....

Or you could use Boost and some template metaprogramming:

Code:

#include <iostream>
#include <boost/mpl/vector.hpp>
#include <boost/mpl/push_back.hpp>
#include <boost/mpl/at.hpp>
#include <boost/mpl/size.hpp>
#include <boost/mpl/for_each.hpp>

template <int I>
struct Function;

template <>
struct Function<0>
{
   static void func()
   {
      std::cout << "In Function 0" << std::endl;
   }
};

template <>
struct Function<1>
{
   static void func()
   {
      std::cout << "In Function 1" << std::endl;
   }
};

// Define more functions here if desired

template <int I>
struct FunctionArray_;

template <int I>
struct FunctionArray_
{
      typedef typename boost::mpl::push_back<
         typename FunctionArray_<I - 1>::type, Function<I - 1>
      >::type type;
};

template <>
struct FunctionArray_<0>
{
   typedef boost::mpl::vector<> type;
};

// Modifying this will include that many functions
const int NUMBER_OF_FUNCTIONS = 2;

typedef FunctionArray_<NUMBER_OF_FUNCTIONS>::type FunctionArray;
typedef void (*FuncPtr)();

struct FunctionPointerAssigner
{
private:
   int index_;
   FuncPtr* funcArray_;
public:
   FunctionPointerAssigner(FuncPtr* funcArray) : index_(0), funcArray_(funcArray) { }

   template <class T>
   void operator()(T)
   {
      funcArray_[index_] = &T::func;
      index_++;
   }
};

int main()
{
   std::cout << "Compile time calls" << std::endl;
   boost::mpl::at_c<FunctionArray,0>::type::func();
   boost::mpl::at_c<FunctionArray,1>::type::func();
	
   std::cout << "Runtime calls through function pointers" << std::endl;
   FuncPtr funcPtrs[boost::mpl::size<FunctionArray>::value];
   boost::mpl::for_each<FunctionArray>(FunctionPointerAssigner(funcPtrs));
   for(int i = 0; i < NUMBER_OF_FUNCTIONS; i++)
      funcPtrs[i]();

   return 0;
}

Output:

Code:

Compile time calls
In Function 0
In Function 1
Runtime calls through function pointers
In Function 0
In Function 1

If you know the number of functions

Code:

#define FUNC_NUMBER 100
#define FUNCTION(i) function##i

typedef void (*FuncPtr)();
FuncPtr* funcPtrs = new FuncPtr[FUNC_NUMBER];

for(i=0;i<FUNC_NUMBER;i++)
{
  funcPtrs[i] = &FUNCTION(i);
}

The ## concats the two strings so you would have function1, function2, etc etc

Hmm, won't that for loop just get the address of functioni() FUNC_NUMBER times? The macro is handled at compile-time; the for-loop isn't evaluated until run-time.

No, "##i" should be replaced with the contents of i.
But them main problem I have with the code (except that it's runtime, of course), is that it's using raw pointers, new and no delete.
Replace it with a vector, use push_back and you're done.

EDIT: Oops. Turns out that's not right. See below.

Originally Posted by Elysia

No, "##i" should be replaced with the contents of i.

pianorain's reasoning sounds correct, and a quick test confirms it. Perhaps the use of the identifier i is confusing; if we change the macro to:

Code:

#define FUNCTION(x) function##x

then it will still be the case that "that for loop (will) just get the address of functioni() FUNC_NUMBER times". Consequently, C_ntua's idea does not work.

Ah, now I see. I didn't read that correctly.
Of course. "i" is passed, so obviously that would be what is pasted.
My bad.

One way is to put them in header files and mark them inline. That way you don't need prototypes.
Another way is to abuse templates since you really don't need prototypes there, either. And with templates, you can give your functions all the same name but with a unique identifier (integer) like pianorain showed.

Originally Posted by tempster09

Thanks, I didn't really think it was possible to do something like that in C but I forgot I have done things like your macro in the past. That's exactly what I was looking for. These functions will be stored in seperate .cpp files each because they will be rather large, so what's the best way to go about calling them from let's say main.cpp? Should I just prototype function1...functionN to a reasonable maximum that I should not pass like 50...? Or include function1...functionN header files (will that work if they don't exist?)...Again I guess i'm asking for a variable way to do this or way to access these functions without having to do work every time I add or remove one. Thanks

I guess you're asking about the method I showed. Um, it's hard for me to answer all of your questions. Bear with me.

Building a C++ project effectively goes through two stages. First is the compile stage. To minimize work here, you could use an implementation dependent compiler switch to define the macro that controls the case logic. Unless you have to change the case logic, then you can compile without changing the source.

Compiling produces object code. This is NOT AT ALL related to the OOP object concept. They are a part of the final result (an executable). Object code or object files are the input to the linker, in the second stage.

You have to make sure you have all the functions in you're using in object code, and then make an executable or you will get linker errors. However that is easiest for you is the way you should organize the source.

The way to get a clean build depends. If you have to manage your object code by hand, I pity you. You may be able to define custom build targets in a custom makefile and not have to edit project details at all. I am not privy to your software choices or how their makefiles -- or whatever vendor foo calls them -- work. Optionally, your IDE should let you remove but not delete function implementations that you are not using from the project and just rebuild. The good news is you can also #include conditionally, using similar case logic to what I've shown you, to prevent editing the source.

It sounds a lot harder than a MPL solution, but I have a feeling people here are making MPL sound deceptively easy as well. We're not really functioning with the clearest picture of your plans.

That's all I have to say.

EDIT: Oh! And additionally, inline does almost nothing you can depend on. If that is a part of your solution don't expect it to inline %100 of the time.

Well, you could always use a scripting language or even C++ to read source file and run that program/script prior to compiling. It would be reasonable since you have a distinct name for the functions as "functionN".

The template solution is clever and probably the more real solution, but practically it is not worth the trouble and the "less readable" effect it will give.

Less readable is subjective and I wouldn't say it's trouble at all.