Вы бы использовали внутренние статические переменные в C?

Эта путаница обычно возникает из-за того, что ключевое слово static служит двум целям.

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

Для объектов, созданных на уровне файлов, уже определена их продолжительность в силу того факта, что они находятся на уровне файлов. Ключевое слово static тогда просто делает их невидимыми для компоновщика.

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

Обратите внимание, что технически статика уровня функции может не обязательно появляться до тех пор, пока функция не будет впервые вызвана (и это может иметь смысл для C ++ с его конструкторами), но каждая реализация C, которую я когда-либо использовал, создает свою статику уровня функции одновременно time как объекты файлового уровня.

Кроме того, хотя я использую слово «объект», я не имею в виду его в смысле объектов C ++ (поскольку это вопрос C). Просто потому, что static может применяться к переменным или функциям на уровне файла, и мне нужно всеобъемлющее слово, чтобы описать это.

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

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

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

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

Они используются для реализации таких инструментов, как strtok, и вызывают проблемы с повторным входом ...

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

Например, в C ++ он используется как один из способов получения одноэлементных данных.

SingletonObject& getInstance()
{
  static SingletonObject o;
  return o;
}

который используется для решения проблемы порядка инициализации (хотя и не является поточно-ориентированным).

Объявление "функция не должна находиться в отдельном файле"

Конечно, нет, это чепуха. Большая часть языков программирования заключается в том, чтобы облегчить изоляцию и, следовательно, повторное использование кода (локальные переменные, процедуры, структуры и т. Д. Все это делают), и это просто еще один способ сделать это.

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

Удобно для одноразовой отложенной инициализации:

int GetMagic()
{
   static int magicV= -1;

   if(-1 == magicV)
   {
      //do expensive, one-time initialization
      magicV = {something here}
   }
   return magicV;
}

Как говорили другие, это не потокобезопасно во время самого первого вызова, но иногда вам это может сойти с рук :)

Я думаю, что люди обычно избегают внутренних статических переменных. Я знаю, что strtok () использует одну или что-то в этом роде, и из-за этого, вероятно, это самая ненавистная функция в библиотеке C.

Другие языки, такие как C #, даже не поддерживают его. Я думаю, что раньше идея заключалась в том, чтобы обеспечить некое подобие инкапсуляции (если это можно так назвать) до времен объектно-ориентированных языков.

Наверное, не очень полезны в C, но они используются в C ++, чтобы гарантировать инициализацию статики в области имен. И в C, и в C ++ есть проблемы с их использованием в многопоточных приложениях.

Я бы не хотел, чтобы наличие статической переменной заставляло меня помещать функцию в отдельный файл. Что, если у меня есть несколько похожих функций, каждая со своим статическим счетчиком, которые я хотел бы поместить в один файл? Мы должны принять достаточно решений о том, где разместить вещи, без необходимости в еще одном ограничении.

Некоторые варианты использования статических переменных:

• вы можете использовать его для счетчиков, и вы не загрязните глобальное пространство имен.
• вы можете защитить переменные, используя функцию, которая получает значение в виде указателя и возвращает внутреннюю статику. Таким образом, вы можете контролировать присвоение значения. (используйте NULL, если вы просто хотите получить значение)

Я никогда не слышал, чтобы эта конкретная конструкция называлась «внутренней статической переменной». Полагаю, подходящий ярлык.

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

Он сохраняет переменную, объявленную в самой локальной области видимости, без необходимости создавать отдельный файл для функции. Это также предотвращает объявление глобальной переменной.

Например -

char *GetTempFileName()
{
  static int i;
  char *fileName = new char[1024];
  memset(fileName, 0x00, sizeof(char) * 1024);
  sprintf(fileName, "Temp%.05d.tmp\n", ++i);
  return fileName;
}

VB.NET поддерживает ту же конструкцию.

Public Function GetTempFileName() As String
  Static i As Integer = 0
  i += 1
  Return String.Format("Temp{0}", i.ToString("00000"))
End Function

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

Уже нет. Я видел или слышал результаты функции локальных статических переменных в многопоточной среде, и это не очень красиво.

При написании кода для микроконтроллера я бы использовал локальную статическую переменную для хранения значения подсостояния для конкретной функции. Например, если бы у меня был обработчик I2C, который вызывался каждый раз при запуске main (), у него было бы собственное внутреннее состояние, хранящееся в статической локальной переменной. Затем каждый раз, когда он вызывается, он проверяет, в каком состоянии он находится, и соответственно обрабатывает ввод-вывод (вставляет биты на выходные контакты, подтягивает линию и т. Д.).

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

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

void errorLog(...)
{
    static int reentrant = 0;
    if(reentrant)
    {
        // We somehow caused an error while logging a previous error.
        // Bail out immediately!
        hardwareReset();
    }

    // Leave ourselves a breadcrumb so we know we're already logging.
    reentrant = 1;

    // Format the error and put it in the log.
    ....

    // Error successfully logged, time to reset.
    hardwareReset();
}

Этот подход проверяет очень маловероятное событие, и он безопасен только потому, что прерывания отключены. Однако для встроенной цели действует правило «никогда не зависать». Такой подход гарантирует (в пределах разумного), что оборудование в конечном итоге будет перезагружено, так или иначе.

Простое использование этого состоит в том, что функция может знать, сколько раз она была вызвана.