Как сделать код на c кроссплатформенным
Язык C в конечном итоге компилируется в язык ассемблера, специфичный для машины. Тогда как C может быть кроссплатформенным, если каждый процессор имеет свой собственный синтаксис языка ассемблера? Если я пишу ядро операционной системы на C, то как мне заставить его работать на разных процессорах?
Как вы ожидаете, что ядро ОС будет работать на разных процессорах? это так как есть разные процессоры, которые необходимы для основного компонента ОС.
с ядром операционной системы ситуация более конкретна, так как машинный код ядра операционной системы сильно зависит от специфики платформы, поэтому почти наверняка только общие части ядра написаны на чистом C, и весьма вероятно, что есть небольшой фрагмент сборки для конкретной платформы, поддерживающий ядро. со специализированными задачами, такими как переключение контекста, управление блоками памяти и т. д., которые полностью зависят от платформы.
Весь код C не является переносимым. Если вы пишете ОС, оборудование самого низкого уровня, которое взаимодействует с конкретным процессором, не является переносимым. Только слои абстракции поверх него. То же самое касается водителей и т.
Ответы 2
C является переносимым на уровне исходного кода. Это означает, что вы можете перекомпилировать свою программу на выбранной платформе и запустить там свое приложение.
Например, вы можете найти история C в википедии. В то время программирование велось на ассемблере под каждую конкретную машину, поэтому наличие высокоуровневого (по тем временам) языка программирования было благом: это ускорило разработку, а также позволило портировать программы с одной машины на новую просто портируя компилятор (позже компилятор C можно было бы написать на самом C, опять же ускорив процесс переноса, но это уже другая история).
В частности, идея переноса UNIX между операционными системами появилась, когда UNIX работал в PDP-7, и появился PDP-11. Наконец, даже ядро UNIX было переписано на C, что сделало операционную систему действительно популярной из-за простоты переноса: нужно было написать лишь небольшой объем сборки для очень специфических частей ядра, чтобы вы могли иметь UNIX наверху. и скоро запустится на новой машине, по крайней мере, по сравнению с другими операционными системами того времени.
Сам язык C является кроссплатформенным, потому что вы не запускаете код C непосредственно на машинах. Исходный код C скомпилирован в сборку, а сборка — это код, специфичный для платформы. Единственная не кроссплатформенная часть — это компиляторы и результирующая сборка.
По сути, вы можете использовать один и тот же код C с разными компиляторами для создания необходимой сборки. Поскольку вы используете один и тот же исходный код C, он считается кроссплатформенным.
Как я могу сделать свой код C++ кроссплатформенным? Мне это нужно для работы на Windows и Xubuntu.
Если я хорошо понимаю вопрос. Вы можете использовать директивы препроцессора C/C++:
Обновление: ОК, теперь вопрос ясен.
Для кроссплатформенного кода C++ вы можете использовать Qt. Это мощный фреймворк на C++, кроссплатформенный и бесплатный.
Как правило, любая достаточно сложная программа должна изначально разрабатываться как кроссплатформенная. Переоснастить существующую программу кроссплатформенностью практически невозможно.
Без подробностей сложно сказать больше.
Вопросы, которые помогут заполнить детали: Где ваша программа НЕ кроссплатформенная? В пользовательском интерфейсе? В конкретных библиотеках? В конкретные вызовы ОС?
У вас есть доступ ко всему исходному коду программы? или вы полагаетесь на внешние статические библиотеки и / или библиотеки DLL?
Имеется реализация одного нетривиального алгоритма на ассемблере. Код предназначен для исполнения на процессорах Intel в реальном режиме. Вряд ли его можно переписать на C без потери производительности, так как там использованы такие возможности микропроцессора как флаг PE; кроме того, код хорошо оптимизирован с использованием таких команд как LoopNE, LodSB и т.д. Можно ли такой код сделать кроссплатформенным?
Если кому-то интересно, это реализация декодирования по Хэммингу. Модуль можно собрать под MSDOS с использованием Open Watcom. Хотелось бы использовать его в программе, разработанной под Windows и Linux. Можно ли это сделать с помощью того же Watcom, или нужно для каждой платформы писать свою реализацию?
Или, быть может, можно иметь один код + конфигуратор к нему под конкретную платформу?
Выбирать между нативной и кроссплатформенной разработкой часто заставляет ограниченный бюджет. Плохо это или хорошо — не суть важно. Важно разобраться, когда делать нативное приложение, а когда хватит и кроссплатформы.
Особенности разработки нативных приложений
Что это вообще такое?
Нативное приложение делают отдельно под каждую платформу. Если вы хотите иметь нативные приложения для iOS и Android, нужно разрабатывать два отдельных приложения на разных языках, например, для iOS Swift, а для Android — Kotlin.
Что хорошего в нативе?
Гибкий, богатый функционал. В приложении можно реализовать любые возможности, поддерживаемые телефоном.
Нет, золото из свинца вы не получите, но фотографии, видео, геопозиция, платежи, гироскоп, компас, распознавание отпечатка пальца — вот это все и немножко больше можно задействовать, по-максимуму реализовав возможности смартфона.
Отличная скорость работы приложения. При разработке используется родной для платформы код, и у готового приложение получается быстрый отклик и отзывчивый интерфейс. По сравнению с таким же по функционалу и качеству кода кроссплатформенным приложением, нативное быстрее на 30%.
Быстрое обновление. Если функционал iOS и Android обновляется, сразу же обновляются и нативные приложения. С кроссплатформенным приложением придется ждать обновления фреймворка. И никто не скажет, на сколько это затянется.
Правильный интерфейс. Дизайн элементов и механика платформ iOS и Android отличаются, так что только с нативной разработкой приложение будет работать в привычном режиме: стандартные движения, классическая графика, расположение элементов и пр.
Для приложений, чей UI/UX основан на стандартных паттернах пользователей, это может быть критичным.
Особенности кроссплатформенной разработки
Что такое кроссплатформа?
Это практика создания универсального кода в кроссплатформенном фреймворке. Получается приложение, работающее одновременно на iOS и Android.
Что хорошего в кроссплатформенной разработке?
Стоит меньше и делается быстрее. Кроссплатформенная разработка, как правило, экономит ресурсы, поскольку код пишется одновременно для iOS и Android. Экономия составляет до 50% времени.
На Flutter, например, писать код быстрее, чем на натив. И, соответственно, дешевле.
За счет экономии времени и денег кроссплатформенная разработка — самое то для быстрой проверки и запуска идеи. Но если идея выстрелит и стартап окажется удачным, будьте готовы переписать приложение под натив. Зачем и почему так — в следующем разделе.
Единый UI. Логика работы у iOS и Android разная, поэтому нативные приложения в них выглядят по-разному. Кроссплатформенное приложение одинаково на всех платформах.
Меньше ошибок в бизнес-логике. Кроссплатформенные приложения пишут кроссплатформенные разработчики, которые пользуются единой основой для iOS- и Android-версии.
Широкая аудитория. Кроссплатформенные приложения доступны пользователям iOS и Android, поэтому аудитория изначально шире. С другой стороны, с кроссплатформой до аудитории можно и вовсе не добраться: у AppStore, например, очень жесткие требования к гибридным приложениям и они с большим трудом проходят модерацию в маркете.
Самые неприятные ограничения кроссплатформенных фреймворков
Дело вот в чем: верстка для кроссплатформы делается по той же технологии, что и для адаптивных сайтов, а при переносе макетов в код нативных приложений соблюдается сетка iOS и Android. Сетки у iOS и Android разные, плюс у них разные размеры и форматы иконок для экрана приложения. Именно поэтому нативная интеграция лучше отображается на разных мобильных устройствах. Даже если это один из тысяч смартфонов на Android и модель с нестандартным экраном. У нестандартного экрана все равно будет стандартная сетка, так что макет со стандартизированными колонками нормально интегрируется в приложении. Кроссплатформенная верстка на нестандартный экран может не встать ни на Андроиде, ни на iOS. Отсюда и баги, которые крайне сложно находить и устранять. У нас был случай, когда в приложении отображалась ошибка с нажатием одной из кнопок. Ошибка воспроизводилась только на одной модели Xiaomi Redmi Note. Мы тестировали приложение на пяти других моделях Xiaomi, искали ошибку на симуляторах, но проблема не воспроизводилась. Пришлось купить именно ту модель Xiaomi Redmi Note, на которой не срабатывала кнопка, и только тогда мы отыскали причину бага.
Рано или поздно наступает момент, когда каждая правка такого приложения превращается в ад, муки и дорогие часы техподдержки.
Кто помнит, несколько лет назад на рынке мобильных приложений случился бум недорогих коробочных решений за 300-500 тыс. рублей. Их много сделали для сервисов доставки еды и такси. Приложения работали на кроссе и первое время баги редактировались командой разработки. Через пару лет исправление багов стало настолько трудозатратным и дорогим, что разработчики отказались от поддержки, а владельцы бизнеса остались у разбитого корыта. Старые приложения копили баги и работали из рук вон плохо. Чтобы перевести клиентов на новые, нужно было провести масштабную работу с аудиторией. И не факт, что получилось бы.
Привередливость операционных систем. У платформ множество различий и все их нужно учитывать в кроссплатформенном фрейме. Например, macOS управляет оперативной памятью, а Windows — нет.
Чтобы приложение не только бесперебойно работало, но и полноценно использовало системные функции, нужен хороший, очень хороший кроссплатформенный разработчик, а их на рынке немного.
Apple предпочитает нативный код. В политике Apple кроссплатформенные решения не в почете: иногда компания выпускает запрещающий список кроссплатформ, которые больше не смогут публиковаться в App Store.
Сложная оптимизация. Чтобы код работал как часы, его нужно оптимизировать. А в кроссплатформенном фреймворке это сделать непросто: базовые структуры платформ слишком разные. Одно из временных решений — кодировать исходное приложение в многоплатформенной среде, а затем экспортировать приложение в собственной код и уточнить. И здесь сходит на нет и экономия времени, и экономия денег.
Постоянно появляются новые устройства. Каждый год выходят новые флагманы, а это обновленные процессоры, новый функционал и опции. В кроссплатформенной среде проблематично все время адаптироваться к новым устройствам и возможностям.
Как выбрать платформу разработки
Отталкивайтесь от задач, которые поставлены перед проектом. Нативное приложение — единственный вариант для узкой или исключительно требовательной платежеспособной аудитории. Для технически простых проектов, рассчитанных на широкую аудиторию или B2B приложений для корпоративного использования можно выбрать кроссплатформу.
Если приложению нужна максимальная производительность, предусмотрена многоступенчатая вложенность, требуется предельная отзывчивость, максимум системных функций — это только натив. Также, только в нативном приложении можно реализовать сложные интерфейсы. Вот почему игровые продукты с 3D графикой могут быть только нативными.
Нужен быстрый результат и возможность поэкспериментировать, когда внедряете что-то необычное? Делайте кроссплатформенное приложение. Выводите на рынок новый продукт, а спрос пока не сформирован? Делайте MVP на кроссплатформе. Сможете недорого протестировать идею и быстро выйти на рынок.
Читайте также: