shads писал(а):avreal поясни пожалуйста, насчет применения static к функциям, народ чето разделился на
за и против.
Какие могут быть сюрпризы если пихать статик неглядя (а смысл есть, многие убедились, да и
я тоже)
Ну разбуянились… По поводу затащить меня ещё на один форум, так это не в агитаторах дело.
Я просто (часто безуспешно) стараюсь сокращать время, потраченное на форумы. На сахаре, наверное, уже с год не показывался. Где уж ещё куда-то ввязываться.
Теперь по основному вопросу.
Давайте сначала определимся, что называть «бездумно натыкивать куда попало». Где граница «бездумности»? Может, она вовсе безгранична?
А то ведь и long для AVR «бездумно напихивать» вредно -- код сильно раздуется. И uint8_t или там unsigned char «бездумно напихивать» не дело, информация пропасть может. Если постараться, то и комментарий можно так впихнуть, что «неизвестно, чем аукнется»
*)
Не «не глядя». Я четко ограничил область — функции, вызываемые только из той единицы трансляции (т.е. компилируемого файла со всеми его include), в которой они определены. Все внутренние, «служебные» функции модуля — первые кандидаты на static. Как кто-то привёл пример на том форуме — функция обмена одним битом в модуле поддержки 1-Wire. Применение static к таким функциям ничего не меняет в остальной программе.
Если же функция таки откуда-то ещё вызывается, то линкер ругнётся, программа не соберётся. Нужно будет подумать (во сюрприз!), почему это она вызывается, если начало казаться, что она внутренняя в модуле. И либо снять static, либо переопределить интерфейс к модулю.
В принципе, во включаемом файле могут быть и функции «с телами» и при включении в несколько других файлов вызываться они будут из разных единиц трансляции. Без static будет конфликт имён, линкер не даст собрать. Со static конфликта не будет, но это будут разые копии одной функции (на уровне объектного кода они будут иметь разные имена), что невыгодно по размеру.
Во вторых, пусть кто-то приведёт конкретный пример, когда применение static приведёт к «трудноуловимым глюкам» скомпилированной программы. Причём именно по вине слова static, а не по вине более ранних ошибок, заметённых под коврик отсутствием явного ограничения области видимости для функций, видимость которых и должна быть ограничена по сути проекта. А то сколько бы много я примеров не приводил — всегда можна будет сказать «а в x1 каком варианте при x2 каких условиях таки может x3 что получиться». А так — пусть приведут один пример.
С моей точки зрения, «не писать static, так как это
неизвестно чем аукнется» — это не
- не писать бездумно static
а
- бездумно не писать static
*) Кстати, когда-то была интересная задачка — определить во время выполнения программы, была при компиляции включена поддержка вложенных комментариев или нет (борландовские компиляторы имели вредный ключик -C для разрешения вложенных комментариев). Моё решение
Код: Выделить всё
printf("Nested comments is %s\n", */*/**/"*/"/*"/**/ == '*' ? "OFF" : "ON");
Во… Судя по получившейся раскраске, в php тоже вложенные комментарии не допускаются
