Синглтон-паттерн: различное поведение auto_ptr и unique_ptr
При реализации фабричного класса я столкнулся с поведением std::auto_ptr что я не могу понять. Я сократил проблему до следующей маленькой программы, так что … начнем.
Рассмотрим следующий синглтон-класс:
singleton.h
#ifndef SINGLETON_H_
#define SINGLETON_H_
#include<iostream>
#include<memory>
class singleton {
public:
static singleton* get() {
std::cout << "singleton::get()" << std::endl;
if ( !ptr_.get() ) {
std::cout << &ptr_ << std::endl;
ptr_.reset( new singleton );
std::cout << "CREATED" << std::endl;
}
return ptr_.get();
}
~singleton(){
std::cout << "DELETED" << std::endl;
}
private:
singleton() {}
singleton(const singleton&){}
static std::auto_ptr< singleton > ptr_;
//static std::unique_ptr< singleton > ptr_;
};
#endif
singleton.cpp
#include<singleton.h>o
std::auto_ptr< singleton > singleton::ptr_(0);
//std::unique_ptr< singleton > singleton::ptr_;
Здесь использование умного указателя для управления ресурсом в основном продиктовано необходимостью избежать утечек при выходе из программы. Я использую этот код в следующей программе:
хиджры
#ifndef A_H_
#define A_H_
int foo();
#endif
a.cpp
#include<singleton.h>
namespace {
singleton * dummy( singleton::get() );
}
int foo() {
singleton * pt = singleton::get();
return 0;
}
main.cpp
#include<a.h>
int main() {
int a = foo();
return 0;
}
Теперь смешной часть. Я собираю три источника отдельно:
$ g++ -I./ singleton.cpp -c
$ g++ -I./ a.cpp -c
$ g++ -I./ main.cpp -c
Если я свяжу их явно в следующем порядке:
$ g++ main.o singleton.o a.o
все работает, как я ожидаю, и я получаю следующее в stdout:
singleton::get()
0x804a0d4
CREATED
singleton::get()
DELETED
Если вместо этого я свяжу источники, используя этот порядок:
$ g++ a.o main.o singleton.o
Я получаю этот вывод:
singleton::get()
0x804a0dc
CREATED
singleton::get()
0x804a0dc
CREATED
DELETED
Я пробовал разные марки компиляторов (Intel и GNU) и версии, и это поведение соответствует между ними. Во всяком случае, я не могу увидеть код, поведение которого зависит от порядка ссылки.
Кроме того, если auto_ptr заменяется unique_ptr поведение ВСЕГДА соответствует тому, что я ожидаю, чтобы быть правильным.
Это подводит меня к вопросу: Кто-нибудь знает, что здесь происходит?
Решение
Порядок, в котором dummy а также std::auto_ptr< singleton > singleton::ptr_(0) построен не определено.
Для auto_ptr случай, если вы строите dummy затем singleton::ptr_(0), значение, созданное в dummy вызов стирается конструктором ptr_(0),
Я бы добавил трекинг для строительства ptr_ с помощью ptr_(([](){ std::cout << "made ptr_\n"; }(),0)); или что-то типа того.
Тот факт, что это работает с unique_ptr является случайным, и, возможно, из-за оптимизации unique_ptr(0) могу выяснить это обнуляется, так как ничего не делает (static данные обнуляются до начала строительства, поэтому, если компилятор может выяснить, что unique_ptr(0) просто обнуляет память, это может легально пропустить конструктор, что означает, что вы больше не обнуляете память).
Один из способов исправить это — использовать метод, который гарантирует конструкцию перед использованием, такой как:
static std::auto_ptr< singleton >& get_ptr() {
static std::auto_ptr< singleton > ptr_(0);
return ptr_;
}
и заменить ссылки на ptr_ с get_ptr(),
Другие решения
Порядок построения объектов области файла, определенных в разных единицах перевода, не указан. Однако, как правило, объекты, определенные в модуле перевода, который связан до того, как другой модуль перевода создан, прежде чем объекты, определенные во втором модуле перевода. Разница здесь в том, в каком порядке a.o а также singleton.o связаны. когда singleton.o связан прежде a.o, singleton::ptr_ инициализируется раньше dummy и все хорошо. когда a.o связан первым, dummy сначала инициализируется, что создает синглтон; затем singleton::ptr_ инициализируется в 0, выбрасывая указатель на оригинальную копию singleton, Затем в вызове fooПризыв к singleton::get() строит синглтон снова.