Какой подход к компиляции кода считается самым лучшим? Через дефайны, передаваемые в билдовый скрипт, создание нескольких бинарников и т.д.?
Положим, у меня есть код, который должен работать на разных моделях железа. Скажем, в модели А функции реализованы одним способом, а в модели Б - другим способом. Но названия и аргументы у них одинаковые.
Я могу:
1. Нафигачить дефайнов в коде. Типа:
#ifdef MODA функция1(...){...} #endif
#ifdef MODB функция1(...){...} #endif
И эти MODA, MODB задавать при запуске компиляции.
Код выглядит мерзко и запутано.
2. Разделить код по файлам с какими-нибудь суффиксами. И по суффиксам в скрипте определять, к какой модели принадлежит данный файл. Соответственно генерить разные бинарники на каждую модель.
Код выглядит опрятно и читаемо, но компиляция идёт долго.
3. Можно в рантайме определять на какой модели мы работаем (есть специально написанная функция). Можно эту функцию вызвать до мейна, записать её результат в переменную, а потом писать:
функция1(...) {
if(РаботаемНаMODA) {...}
if(РаботаемНаMODB) {...}
}
Код тоже как-то убого выглядит. Даже более убого, чем в первом случае.
У профи-программистов какой вариант считается лучшим? :) Или есть ещё какой-то, который я не знаю?
Zellily , в целом, вопрос уже много раз отвечен на тостере.
У тебя какая схема развертывания твоего приложения? Один образ на любое устройство или для каждого устройства свой образ?
Zellily , красивый ответ. :)
Это вопрос архитектуры и решен он должен быть методом расчетов и планирования.
Вот примерное описание отработанного у меня подхода для кроссплатформенной разработки.
В случае распространения узкоспециализированными модулями он тоже подходит.
"Линковка долгая" беспокоить не должна. Сборка и распространение образов должны быть сделаны без участия человека, на CI-серверах. Зашивать образы в тестовое железо тоже лучше автоматически.
Евгений Шатунов, "Методы расчётов и планирования" - эти слова как бальзам на сердце. А у нас переменные и структуры называются: bla-bla и common_area. И это не шутка! А у меня опыта работы не хватает, чтобы всё это разгрести.
4. Вынос всех функций, зависящих от железа, в динамические библиотеки.
При старте определяется железо и подключаются нужные либы.
Особенно актуально, если железо включено не постоянно или может измениться по ходу работы.
Особенно если уже кто-то другой криво реализовал код (по методу наименьшего сопротивления), а ты тупо смотришь на эти функции и думаешь, чё делать. Втыкать ооп и вообще всё рефакторить?
