Являются ли эти C #ifdefs для переносимости устаревшими?

Question

Я работаю со старым кодом C, который все еще имеет несколько пыльных углов. Я нахожу множество #ifdef операторов вокруг, которые относятся к операционным системам, архитектурам и т. Д. И изменяют код для переносимости. Я не знаю, сколько из этих утверждений все еще актуально сегодня.

Я знаю, что #ifdef не лучшая идея в определенных обстоятельствах, и я обязательно исправлю это, но здесь меня интересует то, что тестируется.

Я перечислил их ниже. Если бы вы могли сказать мне, являются ли какие-либо из них определенно полезными в наше время, или если машины или ОС, с которыми они связаны, давно устарели, это было бы здорово. Кроме того, если вы знаете какой-либо центральный справочник по ним, я бы хотел услышать об этом.

Заранее спасибо, Росс

BORLANDC
BSD
CGLE
DRYRUN
HUGE
IBMPC
MAIN
M_XENIX
OPTIMIZED
P2C_H_PROTO
sgi
TBFINDADDREXTENDED
UNIX
vms
__GCC__
__GNUC__
__HUGE__
__ID__
__MSDOS__
__TURBOC__

Answer 1

Вот, пожалуйста.

Answer 2

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

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

Answer 3

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

Если, например, вам не требуется поддержка 16-разрядных систем, вы можете обойтись без __HUGE__, __MSDOS__ и __TURBOC__.

Answer 4

В каком контексте используется этот код?

1. Если это библиотека, которую используют другие люди за пределами вашей организации, вам не следует трогать этот материал, если вы не выпускаете новую версию и явно удаляетеподдержка некоторых ОС.В последнем случае вы должны удалить все соответствующий код IFDEF как часть создания нового выпуска и должны четко указать, что вы удаляете.
2. Если это библиотека людей внутри вашегоорганизации используют, вы должны спросить тех людей, что вы можете удалить, а не нас.
3. Если этот код используется очень узко (т.е. вы контролируете его использование напрямую), вы можете, если хотите, безопасно удалить любой видпереносимости компилятора, так как вы используете только один компилятор.

Answer 5

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

Answer 6

Любой #ifdef, основанный на произвольных определениях препроцессора, предоставленных реализацией, устарел - особенно те, которые находятся в пространстве имен, зарезервированном для приложения, а не реализации, как большинство из них! Правильный современный способ достижения такого рода переносимости - либо обнаружение наличия различных интерфейсов / функций / поведения с помощью скрипта конфигурирования, либо #define HAVE_FOO и т. Д., Основанные на этом, непосредственно тестирует стандартный препроцессор (например, UINT_MAX для определения целочисленного размера) и / или предоставления предварительно скомпилированных заголовочных файлов для каждой платформы, которую вы хотите поддерживать, с соответствующими HAVE_FOO определениями.

«переносимость» старого стиля #ifdef тесно связаны с знанием каждой отдельной платформы по всему вашему источнику, создавая кошмар, когда платформы меняются и принимают новые функции, поведение или настройки по умолчанию. (Только представьте, что в старом коде беспорядок, предполагающий, что Windows 16-битная или Linux имеет SysV-стиль signal()!). Современный стиль изолирует знания о платформе и позволяет условной компиляции в ваших исходных файлах зависеть только от наличия / отсутствия / поведение функции, которую он хочет использовать.