blob: ca5c3f07de82213a097ea569fd2544abe1a6f2e8 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
|
/**
* @file llinitdestroyclass.h
* @author Nat Goodspeed
* @date 2015-05-27
* @brief LLInitClass / LLDestroyClass mechanism
*
* The LLInitClass template, extracted from llui.h, ensures that control will
* reach a static initClass() method. LLDestroyClass does the same for a
* static destroyClass() method.
*
* The distinguishing characteristics of these templates are:
*
* - All LLInitClass<T>::initClass() methods are triggered by an explicit call
* to LLInitClassList::instance().fireCallbacks(). Presumably this call
* happens sometime after all static objects in the program have been
* initialized. In other words, each LLInitClass<T>::initClass() method
* should be able to make some assumptions about global program state.
*
* - Similarly, LLDestroyClass<T>::destroyClass() methods are triggered by
* LLDestroyClassList::instance().fireCallbacks(). Again, presumably this
* happens at a well-defined moment in the program's shutdown sequence.
*
* - The initClass() calls happen in an unspecified sequence. You may not rely
* on the relative ordering of LLInitClass<T>::initClass() versus another
* LLInitClass<U>::initClass() method. If you need such a guarantee, use
* LLSingleton instead and make the dependency explicit.
*
* - Similarly, LLDestroyClass<T>::destroyClass() may happen either before or
* after LLDestroyClass<U>::destroyClass(). You cannot rely on that order.
*
* $LicenseInfo:firstyear=2015&license=viewerlgpl$
* Copyright (c) 2015, Linden Research, Inc.
* $/LicenseInfo$
*/
#if ! defined(LL_LLINITDESTROYCLASS_H)
#define LL_LLINITDESTROYCLASS_H
#include "llerror.h"
#include "llsingleton.h"
#include <boost/function.hpp>
#include <boost/signals2/signal.hpp>
#include <typeinfo>
class LLCallbackRegistry
{
public:
typedef boost::signals2::signal<void()> callback_signal_t;
void registerCallback(const callback_signal_t::slot_type& slot)
{
mCallbacks.connect(slot);
}
void fireCallbacks()
{
mCallbacks();
}
private:
callback_signal_t mCallbacks;
};
class LLInitClassList :
public LLCallbackRegistry,
public LLSingleton<LLInitClassList>
{
friend class LLSingleton<LLInitClassList>;
private:
LLInitClassList() {}
};
class LLDestroyClassList :
public LLCallbackRegistry,
public LLSingleton<LLDestroyClassList>
{
friend class LLSingleton<LLDestroyClassList>;
private:
LLDestroyClassList() {}
};
template<typename T>
class LLRegisterWith
{
public:
LLRegisterWith(boost::function<void ()> func)
{
T::instance().registerCallback(func);
}
// this avoids a MSVC bug where non-referenced static members are "optimized" away
// even if their constructors have side effects
S32 reference()
{
S32 dummy;
dummy = 0;
return dummy;
}
};
template<typename T>
class LLInitClass
{
public:
LLInitClass() { sRegister.reference(); }
static LLRegisterWith<LLInitClassList> sRegister;
private:
static void initClass()
{
LL_ERRS() << "No static initClass() method defined for " << typeid(T).name() << LL_ENDL;
}
};
template<typename T>
class LLDestroyClass
{
public:
LLDestroyClass() { sRegister.reference(); }
static LLRegisterWith<LLDestroyClassList> sRegister;
private:
static void destroyClass()
{
LL_ERRS() << "No static destroyClass() method defined for " << typeid(T).name() << LL_ENDL;
}
};
template <typename T> LLRegisterWith<LLInitClassList> LLInitClass<T>::sRegister(&T::initClass);
template <typename T> LLRegisterWith<LLDestroyClassList> LLDestroyClass<T>::sRegister(&T::destroyClass);
#endif /* ! defined(LL_LLINITDESTROYCLASS_H) */
|
