Итак, у меня есть приложение, которое прекрасно компилируется для Windows, Linux и нескольких вариаций Unix. Недавно я решил портировать его на OSX, когда натолкнулся на препятствие.
У меня есть шаблон, который выглядит следующим образом:
template<int (&F)(int)>
int safe_ctype(unsigned char c) { return F(c); }
идея состоит в том, чтобы предотвратить расширение знака от сбоя определенных реализаций при заданных значениях ввода выше 0x7f
. Обычно он используется так:
safe_ctype<std::isspace>(ch);
К сожалению, это не работает в OSX (используется gcc 4.2). Ошибка связана с std :: isspace
не имеет внешней связи и поэтому не применим для шаблонов. Оказывается, в OSX заголовок ctype.h
имеет все функции (через макросы), помеченные как static inline
.
Вот мой вопрос:
Разрешено ли это любым соответствующий стандарт для функций в стандартной библиотеке C ++ (в данном случае это части, унаследованные от C), чтобы не было внешней связи?
РЕДАКТИРОВАТЬ:
Я слышал от apple. Очевидно, у них есть макрос для управления этим поведением. Определение _DONT_USE_CTYPE_INLINE_
предотвращает статические функции функции ctype.
C++03 §17.4.2.2/1 говорит:
Сущности в стандартной библиотеке C++ имеют внешнюю связь.
То же самое верно и в C: C99 §7.1.2/6 гласит:
Любое объявление библиотечной функции должно иметь внешнюю связь.
Как насчет использования «cctype» (я имею в виду в угловых скобках) вместо «ctype.h». В любом случае, я думаю, это будет заголовок в старом стиле.
Заголовок OS X
защищает нестандартные встроенные версии проверкой того, что вы не компилируете в стандартном режиме.
Если вы не сообщите компилятору, что хотите соответствия, вы не получите соответствия. Это верно почти для всех платформ, хотя и по-разному.
Если вам нужны все тонкости расширений, а что нет, и поэтому вы не хотите требовать строгого соответствия, вы можете определить _DONT_USE_CTYPE_INLINE_
перед включением заголовка, и вы получите неинлайновые версии функции с внешней связью.