Использование статических переменных и статическая линковка исполняемых модулей друг в друга

Всем доброго пятничного вечера!

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

Давайте представим ситуацию: есть некоторый класс, реализованный в статической библиотеке (lib). Эту библиотеку статически привязывает модуль реализации (dll). Далее эту dll также статически привязывает исполняемый модуль (exe). Кроме этого Exe-модуль статически линкует статическую библиотеку (lib).
Примерно так:

Например, здесь есть следующая логика: в lib’е реализован некоторый инструмент для чего-либо. В dll’е реализована некоторая функциональность на основе данного инструмента. В exe реализован тест на эту функциональность. Dll сама не экспортирует инструментальный класс (который находится в lib’e), поэтому тесту требуется статическая линковка lib’ы.
Пусть инструментальный класс содержит в себе статическую переменную. А в dll есть функция создания данного класса, причем объект возвращается по значению.
Вот дополненная схема:

Вот код на С++:

• lib
  
  ListAndIter.h

  #pragma once #include <list>  using namespace std;  class ListAndIter {    private:       std::list<int>::iterator iter;       static std::list<int> &getList();    public:       void foo();       ListAndIter();       ListAndIter(ListAndIter& rhs);       ~ListAndIter();       }; 

  ListAndIter.cpp

  #include "ListAndIter.h"  ListAndIter::ListAndIter() {     getList().push_front(0);     iter = getList().begin(); }  ListAndIter::ListAndIter(ListAndIter& rhs) {    this->iter = rhs.iter;    rhs.iter = getList().end(); }  std::list<int> & ListAndIter::getList() {    static std::list<int> MyList;    return MyList; }  ListAndIter::~ListAndIter() {    if (iter != getList().end())        getList().erase(iter); }  void ListAndIter::foo() {  } 

• dll
  
  GetStaticObj.h

  #pragma once  #include "ListAndIter.h"  #ifdef _DLL_EXPORTS    #define _DLL_EXP __declspec(dllexport) #else    #define _DLL_EXP __declspec(dllimport) #endif  _DLL_EXP ListAndIter GetStaticObj();  

  GetStaticObj.cpp

  #include "GetStaticObj.h"  ListAndIter GetStaticObj() {    ListAndIter obj;    obj.foo();    return obj; } 

• exe
  
  Main.cpp

  #include "GetStaticObj.h"  int main() {    ListAndIter obj = GetStaticObj();    obj.foo(); } 

Как видно из кода, есть специальная функция foo, которая служит для обхода RVO, чтобы вызывался конструктор копирования. Напомню, что и dll-модуль и exe-модуль собираются независимо друг от друга, поэтому они должны знать о существовании статической переменной в lib’е и поэтому создают их у себя.

Объект класса ListAndIter возвращается через конструктор копирования, поэтому при получении объекта на стороне exe-модуля, все ссылки на статическую переменную станут не валидными. По шагам это выглядит так:

1. *.exe: Вызов функции GetStaticObj().
2. Dll.dll: создание временного объекта класса ListAndIter. В список кладется ноль, итератор iter указывает на него. Причем в это время статическая переменная на стороне exe-модуля пустая, соответственно итератор не валидный.
3. *.exe: Вызывается конструктор копирования для объекта класса ListAndIter. У временного объекта итератор стал не валидным. У нового объекта итератор указывает на список из DLL.dll, хотя сам объект создается на стороне exe-модуля.
4. Dll.dll: Уничтожается временный объект класса ListAndIter. Так как итератор не валидный никаких действий не происходит.
5. *.exe: Вызывается деструктор для объекта obj. При попытке сравнения итератора с getList().end() вылезает виндовая ошибка: «Итераторы не совместимы». То есть итератор от «другого списка».

Попробуем исправить такую ситуацию, убрав зависимость exe-модуля от статической библиотеки. Тогда всю функциональность статической библиотеки нужно экспортировать через dll (см. код ниже):

Изменения в коде:

• Создал новый заголовочный файл shared.h. В нем описываем макросы экспорта. Разместил файл в lib’е:
  
  shared.h

  #pragma once  #ifdef _DLL_EXPORTS    #define _DLL_EXP __declspec(dllexport) #else    #define _DLL_EXP __declspec(dllimport) #endif 

• В ListAndIter.h добавил директивы экспорта:
  
  ListAndIter.h

  #pragma once #include <list> #include "shared.h"  using namespace std;  class ListAndIter {    private:       std::list<int>::iterator iter;       _DLL_EXP static std::list<int> &getList();    public:       _DLL_EXP void foo();       _DLL_EXP ListAndIter();       _DLL_EXP ListAndIter(ListAndIter& rhs);       _DLL_EXP ~ListAndIter(); }; 

• В dll соответственно убрал объявления макросов экспорта:
  
  GetStaticObj.h

  #pragma once  #include "ListAndIter.h" #include "shared.h"  _DLL_EXP ListAndIter GetStaticObj(); 

Теперь объект будет создаваться и удаляться только на стороне dll. В exe-модуле статической переменной не будет и такой код отработает успешно.

Теперь давайте предположим, что будет, если класс ListAndIter стал шаблонным:

Для каждой полной специализации шаблона и всех объектов таких классов должна быть своя статическая переменная.
Во-первых, мы обязаны реализацию шаблонного класса поместить в заголовочный файл, т.к. шаблоны раскрываются на этапе компиляции.
Если статическая переменная является членом класса, то чтобы успешно собрать наш проект, мы вынуждены явно проинициализировать эти переменные во всех используемых модулях. В таком случае мы ЯВНО создаем две статические переменные, что возвращает нас к 1-ому примеру.
Иначе, если статическая переменная не является членом класса, а создается через статический метод, то в этом случае она также создается, но уже неявно для нас. Ошибка повторяется вновь.

Для разрешения такой ситуации необходимо создавать промежуточную lib’у, в которой и размещать эту функциональность. То есть вместо dll делать lib. Тогда снова останется одна статическая переменная.

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

Иногда проблема не решается упрощением зависимостей. Например, класс реализован в статической библиотеке и у него есть некий статический счетчик экземпляров. Эта статическая библиотека линкуется в две разные dll, таким образом, в них создается два разных счетчика. В данном случае проблема решается путем превращения статической библиотеки в динамическую (dll). Соответственно две другие dll прилинковывают новую dll динамически. Тогда статическая переменная будет только в одной dll (в той, к которой реализован класс со счетчиком).

Весь код можно взять с github.

P.S. Много всего написал, возможно не идеально… буду рад советам и замечаниям.