Порядок инициализации глобальных объектов

[Dimka]

Как-то я об этом не задумывался. Жили-были себе спокойно несколько синглетонов. Объявлены они были статически как глобальные переменные внутри cpp файлов. Причём одни (обёртки) обращаются к другим прямо во время создания.

Код: (C++)

MyClass singletonInstance;

Сделано было так специально, чтобы не заводить динамически создаваемые объекты - для них при завершении работы программы не вызываются деструкторы, да и память не чистится.

И вот в один прекрасный день - сегодня - вдруг всё сломалось. При инициализации вдруг обёртки стали находить другие объекты ещё не созданными.

По стандарту вроде бы порядок инициализации неопределённый. Т.е. до сих пор мне просто везло.

Ну первое, что приходит в голову - ленивая инициализация по первому запросу + умный указатель.

Какие ещё могут быть решения?

P.S. Важно, что всё это в один модуль не собрать.

[RXL]

А вызов инициализаторов нельзя в кучку собрать? Даже можно сделать это динамически, через мейкфайл, при некоторых правилах именования файлов и переменных. Сформировать на основе списка файлов cpp-модуль, содержащий некоторую заранее известную функцию, динамически наполненную вызовами инициализаторов. Правда, если хочется определенный порядок инициализации, то лучше и надежнее будет сделать это руками. Например, у нас в проекте несколько серверов разного назначения, использующие общие модули: в индивидуальных файлах этих серверов прописано, какие модули и в каком порядке загружаются.

[sss]

Я вот так использую точно инициализированный глобальный объект. Это исключение из правил...
Зато работаем на этапе создания статических объектов.

Код:

CMemoryManager*        g_MM = NULL; 
CMemoryManager& __GlobalMM()
{
  if ( g_MM == NULL) g_MM = new CMemoryManager();
  return *g_MM;
}

PVOID CMemoryManager::__MemAlloc( size_t stBytesCount) throw ( ELowResources*)


#define MemAlloc        __GlobalMM().__MemAlloc

И потом пишу

Код:

 p = MemAlloc(10);

[Вад]

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

[Dimka]

Вад, так и я тоже. Дело ж не в этом, а в порядке срабатывания конструкторов этих синглетонов.

sss, слабо понял, зачем этот наворот. И ко всему прочему непонятна судьба объекта в куче при завершении работы программы. Если судьба его "потерялся - и фиг с ним", мне это категорически не подходит, мне в деструкторе системные ресурсы освобождать надо.


Сделал на умном указателе ленивую инициализацию - по первому обращению. Ну типа:

Код: (C++)

class MyClass
{
private:
  /* ... */
  static std::auto_ptr<MyClass> instance;
  MyClass() { /* ... */ }
  MyClass(const MyClass &copy) { /* ... */ }
public:
  MyClass *Instance()
  {
    MyClass *obj = MyClass::instance.get();
    if(obj == NULL)
    {
      obj = new MyClass();
      MyClass::instance.reset(obj);
    }
    return obj;
  }
  /* ... */
};
std::auto_ptr<MyClass> MyClass::instance;

[sss]

sss, слабо понял, зачем этот наворот. И ко всему прочему непонятна судьба объекта в куче при завершении работы программы. Если судьба его "потерялся - и фиг с ним", мне это категорически не подходит, мне в деструкторе системные ресурсы освобождать надо.

Блин удалить можно внутри освобождения последней ссылки на объект MemFree(p). Наворот нужен для того, что бы быть уверенным что объект создан при первом обращении к нему 
при этом реализация скрыта.

[Вад]

Вад, так и я тоже. Дело ж не в этом, а в порядке срабатывания конструкторов этих синглетонов.

Ты написал, что у тебя глобальные статические переменные.
У меня локальные Я делаю что-то вроде

Код: (C++)

MyClass * Instance()
{
    static MyClass instance(/*params*/);
    return &instance;
}

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

[Dimka]

Вад, это мысль интересная и плодотворная.