Dynamic array of function pointers

Below is what I want to accomplish. These function pointers depend on how many functions I will be creating. They will always follow the pattern function1, function2, etc.. where it will be function#. Is there any way to go through a loop that assigns function# up to n to these array values? So my code snippet will always populate the array of function pointers up to n with function#'s? Or do I have to hard code an array with functions1...n, than only use the indices 0 to n? Hopes this makes sense, thanks.

Code:

---

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

//where N is variable
for(i=0;i<N;i++)
{
  funcPtrs[i] = &functionN
}

---

You could do it with macro magic, but why would you want to? By necessity you will have N functions, therefore you can make just a regular array of them. You could just use the initializer and not have to write a loop at all.

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....

Well I still don't see a reason to avoid a normal array. The preprocessor can help you compile sections of code. I'll show a contrived example in a moment. Before that though, I assumed you would write a maximum number of functions.

So it depends on what you will link. As far as what gets compiled:

Code:

---

#define MAX_FUNCS 6
#define MIN_ARRAY 3

FuncPtrs doThis[MAX_FUNCS] = {
#if COMPILE_FUNCS == MIN_ARRAY
  &foo,
  &bar,
  &baz,
#elsif COMPILE_FUNCS == 4
  &foo,
  &bar,
  &baz,
  &quz,
#else /* case COMPILE_ALL */
  &foo,
  &bar,
  &baz,
  &quz,
  &qux,
#endif
};

---

This way, you can define a macro COMPILE_FUNCS with some implementation dependent, special number that will keep what you are using and ignore the other compiling options. COMPILE_FUNCS is the length of the array. As long as there is a MIN_ARRAY you will always use this technique can work.

You get the best of everything: array initializers, automatic storage, and case specific compiling.

You'll want to do this after committing more research time to the C++ preprocessor. Things can be a lot more robust then what I've shown you, such as making the compiler throw an error if there is a logical problem or a needed define is missing. But this is what I recommend.

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.

Quote:

---

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.

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

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.

Quote:

---

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. :p 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.