A ver, los punteros a funciones miembro no funcionan exactamente igual que los punteros a funciones que, imagino, estás acostumbrado a usar.

class POO
{
  public:
    int funcion( );
}

Si yo creo 20 instancias de la clase que he declarado encima de esta línea, en el código no voy a encontrar 20 copias de "funcion". Únicamente habrá una y será compartida por todas las instancias de "POO". Esto quiere decir que, aunque tu veas que la firma de la función es, símplemente, "int funcion( );", internamente esta función ha de recibir un puntero que apunte a la instancia de "POO" sobre la que tiene que trabajar.

El ejemplo que tu has puesto te podría servir, con algún retoque, para referenciar funciones miembro estáticas, pero no te sirve para funciones miembro dependientes de la instancia. Si quieres acceder a una función no estática necesitas facilitar una instancia de FOO válida.

Lo que pretendes hacer tiene mejores soluciones:

* Guardas simplemente un puntero a "MiClase" en la estructura.
* Haces que "funcion1" sea estática, dado que no accede a elementos no estáticos de la instancia "no vas a tener problemas
* Te replanteas el diseño. Esta opción es la recomendada salvo que estés haciendo una práctica. Este tipo de códigos complican muchísimo el mantenimiento de una aplicación.

Migrar aplicaciones siempre es complicado y, por experiencia, considero un error intentar que la migración reproduzca de forma totalmente fiel la arquitectura anterior.

El problema que se suele producir es que el código acaba siendo poco amigable, ya que cada lenguaje tiene sus propias características y cosas que en un lenguaje se hacen de una forma, en otro deben hacerse de forma totalmente diferente. Esto hace que aparezcan estructuras raras y poco claras que acaban dando problemas.

Si el código va a acabar siendo el mismo entonces no vas a obtener ninguna ventaja por la migración.

Mi consejo es que las partes feas como estas reciban un repaso y se refactoricen como es debido. Se que al final es como todo, hay dinero de por medio que limita el alcance de todo proyecto, pero una arquitectura bien hecha reduce muchísimo el mantenimiento futuro... es elegir entre pagar un poco más hoy o un mucho más mañana.

class FOO
{
public:
 
  void func1( )
  {std::cout << "func1" << std::endl;
 
  void func2( )
  { func3( ); }
 
  void func3( )
  { std::cout << "func3" << std::endl; }
};

En este ejemplo, tanto func1 como func3 pueden pasar a ser estáticas sin ningún problema, ya que no arrastran dependencias a miembros no estáticos.

Sin embargo, para pasar "func2" a estática sería necesario hacer "func3" también estática, ya que func2 depende de "func3" y una función estática no puede acceder directamente a los miembros no estáticos de una clase.

ok ok, yo el planteamiento que te he dicho parte del desconocimiento más absoluto del código con el que estás trabajando. Obviamente sin tener código es difícil dar soluciones concretas.

En cualquier caso, que te sea breve

Un saludo.

http://www.parashift.com/c++-faq/memfnptr-vs-fnptr.html