Продолжение темы портирования на Windows RT. В этот раз несколько слов об особенностях компиляторов.
Не смотря на сплошную стандартизацию C и C++ перенести проект, который разрабатывался с использованием только одного компилятора, на другой компилятор, а тем более другую платформу, достаточно непростая задача. В этой заметке несколько слов о портировании Android проекта на Windows RT. Отдельно отмечу, что речь идёт о математической библиотеке и системных вопросов я касаться не буду.
Проект довольно давно рос и развивался исключительно для Android и успел обрасти большим количеством оптимизаций, в том числе с использованием векторного модуля NEON и распараллеливания с помощью TBB. Первым шагом на пути компиляции было решено отключить оба этих полезных инструмента. Пока не до жиру, надо собрать основной код и получить нужную функциональность. Благо для этого в коде были заранее заготовлены макросы.
Первым препятствием на пути к успешному билду встали суффиксы у констант типа long long unsinged int. Как выяснилось GCC понимает и LLU и ULL суффиксы, а компилятор от Microsoft варант LLU напрочь не переваривает.
Следующая проблема - inline/noinline аттрибуты функций. Рекомендация к включению тела функции в вызываемый код стандартизирована и одинакова у всех. Делается это ключевым словом inline в начале определения функции. Атрибут с обратной семантикой, т.е. не инлайнить функцию, не стандартизирован и у каждого свой. В GCC это __attribute__ ((noinline)) Visual Studio это __declspec(noinline). Для добавления нового компилятора имеет смысл добавить платформо зависимый макрос и использовать его в коде.
Интересная ситуация возникает с экспортом функций и классов. При компиляции GCC под Linux платформы обычно по умолчанию все функции и классы экспортируются из динамических библиотек. Это значит можно сильно не заморачиваться при написании тестов и звать всё что вам нужно. При переходе на Visual Studio картина меняется на противоположную. По умолчанию, всё, что не отмечено для экспорта в интерфейсе библиотеки, не видно. Что затрудняет тестирование приватных классов. Экспорт функций и классов так же не стандартизирован. В GCC используется атрибут
Не смотря на сплошную стандартизацию C и C++ перенести проект, который разрабатывался с использованием только одного компилятора, на другой компилятор, а тем более другую платформу, достаточно непростая задача. В этой заметке несколько слов о портировании Android проекта на Windows RT. Отдельно отмечу, что речь идёт о математической библиотеке и системных вопросов я касаться не буду.
Проект довольно давно рос и развивался исключительно для Android и успел обрасти большим количеством оптимизаций, в том числе с использованием векторного модуля NEON и распараллеливания с помощью TBB. Первым шагом на пути компиляции было решено отключить оба этих полезных инструмента. Пока не до жиру, надо собрать основной код и получить нужную функциональность. Благо для этого в коде были заранее заготовлены макросы.
Первым препятствием на пути к успешному билду встали суффиксы у констант типа long long unsinged int. Как выяснилось GCC понимает и LLU и ULL суффиксы, а компилятор от Microsoft варант LLU напрочь не переваривает.
Следующая проблема - inline/noinline аттрибуты функций. Рекомендация к включению тела функции в вызываемый код стандартизирована и одинакова у всех. Делается это ключевым словом inline в начале определения функции. Атрибут с обратной семантикой, т.е. не инлайнить функцию, не стандартизирован и у каждого свой. В GCC это __attribute__ ((noinline)) Visual Studio это __declspec(noinline). Для добавления нового компилятора имеет смысл добавить платформо зависимый макрос и использовать его в коде.
Интересная ситуация возникает с экспортом функций и классов. При компиляции GCC под Linux платформы обычно по умолчанию все функции и классы экспортируются из динамических библиотек. Это значит можно сильно не заморачиваться при написании тестов и звать всё что вам нужно. При переходе на Visual Studio картина меняется на противоположную. По умолчанию, всё, что не отмечено для экспорта в интерфейсе библиотеки, не видно. Что затрудняет тестирование приватных классов. Экспорт функций и классов так же не стандартизирован. В GCC используется атрибут
__attribute__ ((dllexport)), а в Visual Studio - __declspec(dllexport). Как и с инлайнингом, в таком случае разумно использовать свой макрос.
Комментариев нет:
Отправить комментарий