Me encanta cuando las cosas salen de forma tan sencilla.

A mi modo de ver es un indicativo de que el código está bien diseñado.

Aún sigues con esto??

struct equipo
{
    char nombre[20];
    int puntos;
};
 
typedef struct equipo equipo;
 
 
int ordenarPorPuntos( const void* a, const void* b )
{
  const equipo* equipo_a = (const equipo*)a;
  const equipo* equipo_b = (const equipo*)b;
 
  return equipo_b->puntos - equipo_a->puntos;
}
 
void main ( )
{
  equipo grupoA[4];
 
  strcpy( grupoA[ 0 ].nombre, "Equipo 1" );
  grupoA[ 0 ].puntos = 10;
 
  strcpy( grupoA[ 1 ].nombre, "Equipo 2" );
  grupoA[ 1 ].puntos = 14;
 
  strcpy( grupoA[ 2 ].nombre, "Equipo 3" );
  grupoA[ 2 ].puntos = 8;
 
  strcpy( grupoA[ 3 ].nombre, "Equipo 4" );
  grupoA[ 3 ].puntos = 15;
 
  qsort( grupoA, 4, sizeof( equipo ), ordenarPorPuntos );
 
  int i;
  for ( i=0; i<4; ++i )
  {
    printf( "%s   %-2d\n", grupoA[ i ].nombre, grupoA[ i ].puntos );
  }
}

Entiendo que los dos archivos tienen que coexistir en el programa a la vez, no ?

Si estás en c, yo creo que la mejor opción es tener una variable que redirija el flujo del programa en una dirección u otra. Lo más normal sería añadir un 4º parámetro a la función para elegir el camino... un int que haga las veces de booleano, por ejemplo.

Si no, también podrías sacar lo que es común a dos funciones independientes ( funcA ( para lo que hay antes del if ) y funcB ( para lo que hay después ), de tal forma que:

void Transicion(Datos* param,short incrx,short incry)
{
    for (short ini = 1; ini < 21; ini++)
    {
      funcA( param, incrx, incry, i );
      funcB( param, incrx, incry, i );
    }
}
 
void Transicion2(Datos* param,short incrx,short incry)
{
    for (short ini = 1; ini < 21; ini++)
    {
        funcA( param, incrx, incry, ini );
 
        if (param->Valor == 1)
            circlefill(param->Lienzo,param->X*20+10,param->Y*20+10,5,pallete_color[14]);
 
        if (param->Valor == 2)
            circlefill(param->Lienzo,param->X*20+10,param->Y*20+10,7,pallete_color[12]);
 
        funcB( param, incrx, incry, ini );
    }
}

Si estás en c++ podrías crear dos clases tal que una herede de la otra y sobreescriba la función o... si quieres aprovechar al máximo el código... que sobreescriba una función secundaria.

Me explico:

class A
{
  public:
    void Transicion( Datos* param, short incrx, short incry )
    {
      // ...
 
      FuncIf( );
 
      // ...
    }
 
  private:
    virtual void FuncIf( Datos* param, short incrx, short incry )
    { }
};
 
class B : public A
{
    virtual void FuncIf( Datos* param, short incrx, short incry )
    {
       if ( ... )
    }
}

Las funciones no tienen operadores de indirección.

Lo que sucede es que una función puede devolver algo... y ese algo si puede tener operadores de indirección o, directamente, ser un puntero.

Ejemplo:

class poo
{
  public:
    int a;
};
 
poo* func( );
 
int main( ... )
{
  // ...
 
  func( )->a = 7;
}

De todas formas, visto tu nivel te recomiendo empezar con cosas más sencillas... conseguirás metas más fácilmente y eso te motivará más que lo que estás intentando hacer ahora.

jajajaja por ese precio también lo hago yo XDDDDD

jejeje

Tu piensa que si existiesen funciones estándar para hacer todo, el código sería siempre perfectamente portable y quizás no harían falta librerías como la tuya...

... pero la realidad siempre es más cruda, cada sistema operativo tiene sus propias llamadas al sistema, lo que hace que las APIs sean diferentes y esto a su vez conlleva la amargura de saber que es complicado hacer aplicaciones completas que sean portables... salvo que uses librerías portables, como Qt... o la tuya si llegara el caso.

Al final estas librerías tienen por debajo una programación específica para cada arquitectura y separan los elementos específicos con directivas del precompilador ( que es lo que tu has descubierto hoy ).

El problema de usar directivas de precompilador es que dichas directivas se ejecutan antes de que el código pase al compilador, por lo que el compilador va a crear una solución específica para la arquitectura sobre la que esté corriendo... esto quiere decir en cristiano que el código resultante de una compilación no es portable.

Para que el código sea realmente portable tienes que distribuir los fuentes y es responsabilidad de cada usuario el compilar tu librería en su sistema para obtener un código que funcione correctamente en su máquina.

No se si me he explicado con claridad. Si tienes dudas pregunta.

En este foro se resuelven dudas y se ayuda... no se hacen tareas.

Si lo que quieres es que te lo hagan la pregunta a hacerte es... cuánto estás dispuesto a pagar por ello??

Y entonces como estabas haciendo la librería portable??

Me alegro de haber sido útil

Un saludo.

No te lo he dicho enfadado ni mucho menos.

Lo cierto es que hablar en un foro es algo frío y es difícil transmitir sentimientos o sensaciones.

También tienes que pensar que el foro puede parecer una solución fácil a tus problemas... pero si tu intención es dedicarte a esto en el futuro deberías plantearte el uso del foro como ultimísima opción después de sudar tinta intentando arreglarlo tu ( aunque ello incluya aprender a usar el depurador... cosa que te vendrá genial en el futuro ).

Es muy fácil acostumbrarse a que alguien te resuelva los problemas... pero con eso no aprendes a solucionarlos y llegara un momento en el que no haya nadie para resolverlos ( será cuando te paguen por hacer programas ). Si llega ese momento te prometo que sí que vas a saber lo que es sudar tinta