2010-06-19 23 views
7

SDL en OS X utiliza trucos de preprocesador para sobrecargar main() con su propio punto de entrada, escrito en Objective C, que llama al principal del usuario.Haskell SDL en OS X

Estos trucos hacen que la vida de los usuarios de SDL que no sean C (por ejemplo, los enlaces Haskell) sea muy difícil.

¿Hay una buena razón para esto?

¿Por qué SDL no pudo hacer el objetivo-C Inicialización de cacao en SDL_init?

Respuesta

5

El enfoque para Mac OS X no es muy diferente del enfoque para otras plataformas que no son Linux (Windows, Mac viejo, BeOS). Se podría pedir a los desarrolladores SDL a sí mismos por qué lo hicieron de esta manera, pero puede ver varias razones que pueden haber elegido para hacer esto:

  • Esto mantiene las dependencias de código de SDL, que se centra en la inicialización de SDL-específica subsistemas (video, audio, sincronización, etc.) limitados a los subsistemas específicos con los que SDL está especialmente diseñado para trabajar. Es decir. De esta forma, SDL se mantiene delgado y ruin.
  • Evita tener que introducir un nuevo subsistema específico de plataforma para la inicialización de la aplicación. No todo el mundo va a querer el objeto de aplicación básico y el menú que SDL configura para las aplicaciones de Mac, no por una posibilidad remota, así que si lo va a poner en SDL_init, tendría que hacerlo un subsistema opcional para para no molestar a los desarrolladores que no lo necesitan.
  • Maneja la inversión de control correctamente, que es cómo Mac OS X y otros marcos de aplicaciones normalmente operan, mientras se mantiene la semántica operacional de las rutinas SDL. SDL_init supone que volverá a la persona que llama después de que se complete la inicialización, pero si intentó ingenuamente crear un objeto de aplicación en SDL_init e invocar [app run] en él para finalizar la inicialización de la aplicación y el inicio, nunca volvería. Si no llamó al run allí, tendría que crear una función SDL separada para configurar el ciclo de ejecución de la aplicación. Esto podría complicar bastante la biblioteca de SDL. El enfoque que se eligió evita todo esto, dejando que el marco se ocupe primero de la configuración de la aplicación e invoque la rutina SDL_main() desde applicationDidFinishLaunching.
  • Facilita la conversión de demos SDL codificadas en Linux a Mac OS X. Ni siquiera tiene que cambiar el nombre de main; el cambio de nombre de preprocesador de main() a SDL_main() se ocupa de eso por usted.

Estoy adivinando la última de estas razones es el principal impulsor detrás de la redefinición del principal de SDL_main.h, que estoy de acuerdo es un truco feo.

Si estás dispuesto a renunciar a ese nivel de portabilidad multiplataforma para su biblioteca y aplicaciones, sugeriría una simple modificación de su SDL_main.h para quitar la línea siguiente:

#define main SDL_main 

y la eliminación de la siguiente del SDLMain.m en su proyecto:

#ifdef main 
# undef main 
#endif 

no debería siquiera necesidad de recompilar SDL si usted hace esto. Tenga en cuenta que SDLMain.m ya está configurado para invocar SDL_main() sin el truco del preprocesador, y nada más en SDL va a utilizar esto, así que de esta manera puede simplemente proporcionar SDL_main() como punto de entrada de su juego.

Si quieres ir a otro lado, tomando el relevo main() mismo, todavía querría deshacerse de la #define main SDL_main truco en SDL_main.h, pero aparte de eso, no estás en deuda con la main() que prevé SDL tú. En primer lugar, tenga en cuenta que SDLMain.{h,m} no son parte de la biblioteca propiamente dicha; debe incluirlos por separado en su proyecto. En segundo lugar, tenga en cuenta las siguientes observaciones en SDLMain.h:

/* SDLMain.m - main entry point for our Cocoa-ized SDL app 
     Initial Version: Darrell Walisser <[email protected]> 
     Non-NIB-Code & other changes: Max Horn <[email protected]> 

    Feel free to customize this file to suit your needs 
*/ 

Eso me suena como una invitación para ir a rodar su cuenta si éstos no están trabajando para que, a partir de SDLMain.{h,m} como modelo. ¡Y si haces tu propio, puedes hacer lo que quieras! Para el caso, podría escribir el equivalente a SDLMain.m en Haskell, utilizando HOC, si eso es lo que desea. Sin embargo, a menos que seas un genio con HOC, lo mantendría simple.