Haskell SDL в OS X

Подход для Mac OS X мало чем отличается от подхода для других платформ, отличных от Linux (Windows, старый Mac, BeOS). Вы можете спросить самих разработчиков SDL, почему они сделали это именно так, но я вижу несколько причин, по которым они могли это сделать:

• Это сохраняет зависимости кода SDL, ориентированного на инициализацию подсистем, специфичных для SDL (видео, аудио, синхронизация и т. д.), ограниченными конкретными подсистемами, для работы с которыми SDL специально разработан. т.е. Таким образом, SDL остается скудным и подлым.
• Это позволяет избежать необходимости вводить новую подсистему для конкретной платформы для инициализации приложений. Не всем понадобится базовый объект приложения и меню, которые SDL настраивает для приложений Mac, в далеком будущем — поэтому, если вы собираетесь поместить его в SDL_init, вам нужно будет сделать его дополнительной подсистемой, поэтому чтобы не доставлять неудобств разработчикам, которым это не нужно.
• Он правильно обрабатывает инверсию управления, как обычно работают Mac OS X и другие платформы приложений, сохраняя при этом операционную семантику подпрограмм SDL. SDL_init предполагает, что он вернется к вызывающей стороне после завершения инициализации, но если вы попытаетесь наивно создать объект приложения в SDL_init и вызвать для него [app run], чтобы завершить инициализацию и запуск приложения, вы никогда не вернетесь. Если бы вы не вызвали run, вам пришлось бы создать отдельную функцию SDL для настройки цикла выполнения приложения. Это может немного усложнить библиотеку SDL. Выбранный подход позволяет избежать всего этого, позволяя платформе сначала позаботиться обо всех настройках приложения и вызвать подпрограмму SDL_main() из applicationDidFinishLaunching.
• Это упрощает преобразование демонстраций SDL, закодированных в Linux, в Mac OS X. Вам даже не нужно переименовывать main — препроцессор переименовывает main() в SDL_main() позаботится об этом за вас!

Я предполагаю, что последняя из этих причин является основной причиной переопределения main в SDL_main.h, что, я согласен, является уродливым хаком.

Если вы готовы отказаться от кросс-платформенной переносимости вашей библиотеки и приложений, я предлагаю просто изменить SDL_main.h, удалив следующую строку:

#define main SDL_main

и удалите следующее из SDLMain.m в вашем проекте:

#ifdef main
#  undef main
#endif

Вам даже не нужно будет перекомпилировать SDL, если вы это сделаете. Обратите внимание, что SDLMain.m уже настроен на вызов SDL_main() без взлома препроцессора, и ничто другое в SDL не будет использовать это, поэтому таким образом вы можете просто указать SDL_main() в качестве точки входа в вашу игру.

Если вы хотите пойти другим путем, взяв на себя main(), вы все равно хотите избавиться от взлома #define main SDL_main в SDL_main.h, но в остальном вы не обязаны main(), которые SDL предоставляет вам. Во-первых, обратите внимание, что SDLMain.{h,m} не являются частью собственно библиотеки; вы должны включить их отдельно в свой проект. Во-вторых, обратите внимание на следующие комментарии в 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
*/

Для меня это звучит как приглашение попробовать свои собственные, если они не работают для вас, начиная с SDLMain.{h,m} в качестве модели. И если вы катите свой собственный, вы можете делать все, что хотите! Если на то пошло, вы можете написать эквивалент SDLMain.m на Haskell, используя HOC, если это то, что вы хотите. Однако, если вы не разбираетесь в HOC, я бы все упростил.