LINUX.ORG.RU

Чтобы почитать, о правилах написания портируемого, сишного кода?

 , ,


1

2

Книжки, лекции, статьи, личные советы.

Решение:

Завести виртуалки (или железки),
для сборки, написать систему сборки для них,
с предоставлением отчётности.
Писать юнит тесты, или использовать подход TDD.
Тестировать, спотыкаться о грабли, набирать опыта.
Чтить стандарты своего языка, выбирать наиболее полную 
реализацию стандарта.
Разделять платформозависимый код и кроссплатформенный.
При переносе на другие архитектуры, ознакомится с этими архитектурами. 
И да, использовать кроссплатформенные системы сборки, аля СMake.

★★★★★

Последнее исправление: cetjs2 (всего исправлений: 4)

Правильный вопрос: что бы написать, чтобы было портируемо.

Тут не помогает ничего, кроме большого кругозора и некоторого опыта. Возможно, помогут знания из теории компиляторов. Ну и технические средства:

  • Флаги -std=c89, -std=c99, -std=c11 вместо дефолтного gnu89/gnu99
  • Использование библиотек вместо системных API. Если библиотек не хватает и «приходится» использовать API системы — значит, пора переходить на C++, там кроссплатформенных библиотек для геймдева больше как минимум на один порядок
  • Можно поискать способ отрубить расширения glibc, лично я не знаю такого.
quiet_readonly ★★★★
()
Последнее исправление: quiet_readonly (всего исправлений: 1)
Ответ на: комментарий от quiet_readonly

Ну так то да, везде

--std=c99 -Wall -pedantic

Но вот помнится кто то писал что всякие signed лучше явно указывать не смотря на автоматику и всё в таком роде.

Dron ★★★★★
() автор топика
Ответ на: комментарий от Dron

Для типов переменных лучше использовать описанные в <stdint.h>, платформозависимый код выделять в #ifdef _ПЛАТФОРМА. Ну а вообще, правильно тут тебе говорят, тут не читать надо, а писать. Напиши код для одной платформы и портируй на другую. По граблям походишь - научишься.

feofan ★★★★★
()
Последнее исправление: feofan (всего исправлений: 2)

Больше интерфейсов, хороших и разных. На каждую фигню придумывай интерфейс и реализацию для конкретной платформы.

Стандарт. Чтение и следование ему я думаю не стоит упоминать, т.к. иначе ты ссзб.

nanoolinux ★★★★
()

Что бы почитать, о правилах написания портируемого сишного кода?

Учебник русского?

dmfd
()
Ответ на: комментарий от feofan

Хороший стиль - маленькое платформозависимое ядро + платформонезависимая обвязка. Тогда легко будет добавлять бэкэнды. Почитай кроссплатформенный код. Или хотя бы про архитектуру llvm, например.

feofan ★★★★★
()
Последнее исправление: feofan (всего исправлений: 1)

Заставь код работать на NetBSD/pcc/sparc64.

unsigned ★★★★
()
Ответ на: комментарий от Dron

Если код проекта, который задуман быть кроссплатформенным, находится в процессе написания, то и тестируй по мере написания, что код хотя-бы собирается под нужные платформы.

feofan ★★★★★
()

«Как не надо программировать на C++», «How Not to Program in C++: 111 Broken Programs and 3 Working Ones».

Раздел «Portage to Hell».

anonymous
()
Ответ на: комментарий от feofan

Ай, нет, не получается. Не так давно делал gtk-интерфейс к базе, под оффтопик совсем другие танцы с бубном. При том, что и в движке есть отличия.

Deleted
()
Ответ на: комментарий от Deleted

Так остальные мои советы остаются в силе. И, с некоторых пор, я не считаю gtk кроссплатформенным. Для кроссплатформенной морды куда лучше подойдет Qt или Tk. Впрочем, написание морд - не моя компетенция.

feofan ★★★★★
()
Последнее исправление: feofan (всего исправлений: 1)
Ответ на: комментарий от feofan

Ну, у меня специфическая задача, зависит от платформы много, графика, звук для этих целей SDL, так как писать обвязки самому не имеет смысла, получится ещё один SDL.

С этим то всё более менее ясно, а вот что касается других архитектур, отличных от x86-64?

Dron ★★★★★
() автор топика

С помощью системы сборки подключай те или иные платформозависимые части программы.

netcat ★★
()
Ответ на: комментарий от Dron

а вот что касается других архитектур, отличных от x86-64?

Тестируй сборку под них. Хотя бы изредка. Если у тебя нет подходящего железа, подготовь кросс-тулчейн. Если есть, можешь собирать на железе (можешь не на железе), но тогда можешь тестировать запуск своего программного продукта на этом железе. При отсутствии железа запуск можешь тестировать в виртуалке.

feofan ★★★★★
()
Последнее исправление: feofan (всего исправлений: 1)
Ответ на: комментарий от feofan

Думается да, на клепать виртуалок, благо комп свободный для этого есть и гонять там код, решая попутные проблемы. Надо подумать как автоматизировать всё это дело, конечно с предоставлением отчётности.

Dron ★★★★★
() автор топика
Ответ на: комментарий от feofan

Да, потрачу время, набросаю автоматику сборки в виртуалках, с отчётами веб мордой.

Dron ★★★★★
() автор топика
Ответ на: комментарий от feofan

Ну юнит-тесты, я для каждой(почти) функции пишу. Только это наверное не TDD, так как их, после реализации пишу.

Dron ★★★★★
() автор топика
Ответ на: комментарий от Dron

Тоже нормальная практика. Значит, после сборки в тех же виртуалках запускай юнит-тесты.

feofan ★★★★★
()
Ответ на: комментарий от feofan

написание морд - не моя компетенция

Пришлось.

Мой, к слову, приятель, тоже «на лету» втыкался в базы и в морды к ним. Но у него проще в этом плане, практически сразу после института стал заниматься базами, поэтому инструмент выбрал давно.

Deleted
()
Ответ на: комментарий от Deleted

Ну, написание морд в принципе не моя компетенция. Я - эмбеддерщик. Отсюда приличный опыт crossdevelopment.

feofan ★★★★★
()

Plan-9

«они» ещё пачку статей опубликовали о процессе написания портируемого кода ( в том числе как избегать #ifdef для различения bigendian|littleendian)

так же :

как К.Томпсон и Ко поправили свой компилятор сей( и перепроектировали его библиотеки) шобы избегат вложеность #include как явление.

qulinxao ★★☆
()
Ответ на: комментарий от netcat

Ну на CMake ты меня уже подсадил :).

Тут мне просто интересно как именно на архитектурах разных происходит разработка , скажем к примеру PowerPC. Ну я методом тыка буду пробовать.

Dron ★★★★★
() автор топика
Ответ на: комментарий от qulinxao

Ну да, на код плана просто смотреть полезно для здоровья. Там чёткое разделение зависимого кода, как смотрю асм в основном, от всего остального сишного.

Dron ★★★★★
() автор топика
Ответ на: комментарий от Dron

Самое неприятное при портировании кода — это вовсе не причуды редких систем и архитектур (никто же не заставляет обходить баги системы, нужной 3,5 некрофилам).

Неприятно встречать никак не задокументированный вызов API системы (хотя бы даже обращение к вызовам ядра mach на айфоне). Особенно если он скопипащен. Приходится вначале искать причину, по которой был использован именно этот метод, затем устранять его дублирование и каждую копипасту проверять.

Тем более что автор этого кода скопировал код со stackoverflow, напастил по-быстрому и теперь искренне не понимает, почему порт пишется так медленно.

quiet_readonly ★★★★
()
Ответ на: комментарий от quiet_readonly

Вот чтобы такого не было, нужна грамотно спроектированная архитектура. LLVM, Qt, KDE - примеры такой архитектуры.

feofan ★★★★★
()
Ответ на: комментарий от quiet_readonly

Ну это да, особенно доставляют разнообразные «хаки» разработчиков, хотя таки штуки они обычно гордо описывают и обязательно в комментах смайл вляпают :). А во когда «хак» тихий вот это действительно жесть.

Dron ★★★★★
() автор топика

Что бы почитать о правилах написания портируемого сишного кода?

anonymous
()

Не бывает полностью кроссплатформенного кода. Бывает код который может быть скомпилирован одним(или несколькими, чаще 2-3) компилятором для нескольких (как правило несколько типовых) платформ. Все остальное иллюзия домыслы и фантастика.

P.S. И даже при таком раскладе количество ошибок, подпорок и костылей в «среднем» по размеру проекте, воистину гигантское.

Jetty ★★★★★
()

Но на самом деле никакая теория нифига не спасет кроме как писать код. Тупо писать много кода.

Jetty ★★★★★
()
Ответ на: комментарий от feofan

платформозависимый код выделять в #ifdef _ПЛАТФОРМА.

НЕ НАДО так делать. Платформо-зависимый код надо выделять в отдельный .c файл, и разбираться с этим на уровне системы сборки.

anonymous
()
Ответ на: комментарий от anonymous

Прав ты, анонимный брат. Но то было в небольшом эмбеддед проекте - там можно =)

feofan ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.