Как обойти соглашения о присвоении имен в Symbian? - PullRequest
0 голосов
/ 05 августа 2009

Я собираюсь написать библиотеку C ++, которая будет использоваться приложением Windows, а также в Symbian. Linux не является текущим требованием, но, как правило, должно быть возможным.
По этой причине я хотел бы использовать соглашения об именах STL / Boost вместо Symbian's , к которым, я думаю, трудно привыкнуть.
Это, кажется, уже представляет проблему при компиляции кода с Carbide.c ++, поскольку он обеспечивает соблюдение соглашения об именах Symbian.

Как я могу использовать «нормальные» имена и при этом быть совместимым с Symbian? Сначала я подумал об условно-повторном присвоении имен классов для платформы Symbian, но боюсь, что это приведет к путанице.

Могут ли возникнуть другие проблемы из-за несоблюдения правил именования Symbian?

1 Ответ

4 голосов
/ 05 августа 2009

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

Конечно, вашей библиотеке, возможно, нужно каким-то образом взаимодействовать с базовой операционной системой. С помощью открытых библиотек C / C ++ вы можете делать много вещей, не прибегая к использованию собственных API-интерфейсов Symbian C ++ и их соглашений об именах.

В Carbide.c ++ вы можете отключить статический анализ CodeScanner, поскольку он действительно полезен только для кода, написанного на родном Symbian C ++.

Итак, в итоге, проблемы заключаются в следующем:

  • Люди из родного Symbian C ++ не совсем знакомы с вашими соглашениями
  • Использование нативных API Symbian C ++ может выявить некоторые специфические для платформы особенности (исключения по сравнению с листьями, использование ловушек, активные планировщики и т. Д.)
  • Статические анализаторы для Symbian, такие как CodeScanner, предполагают стиль кода Symbian C ++ и могут генерировать ошибки / предупреждения, о которых вам действительно не нужно беспокоиться
...