summaryrefslogtreecommitdiff
path: root/indra/llcommon/llregistry.h
AgeCommit message (Collapse)Author
2023-01-07Cleanup for loops in llcommon to use C++11 range based for loopsFawrsk
2016-09-15MAINT-5232: Normalize LLSingleton subclasses.Nat Goodspeed
A shocking number of LLSingleton subclasses had public constructors -- and in several instances, were being explicitly instantiated independently of the LLSingleton machinery. This breaks the new LLSingleton dependency-tracking machinery. It seems only fair that if you say you want an LLSingleton, there should only be ONE INSTANCE! Introduce LLSINGLETON() and LLSINGLETON_EMPTY_CTOR() macros. These handle the friend class LLSingleton<whatevah>; and explicitly declare a private nullary constructor. To try to enforce the LLSINGLETON() convention, introduce a new pure virtual LLSingleton method you_must_use_LLSINGLETON_macro() which is, as you might suspect, defined by the macro. If you declare an LLSingleton subclass without using LLSINGLETON() or LLSINGLETON_EMPTY_CTOR() in the class body, you can't instantiate the subclass for lack of a you_must_use_LLSINGLETON_macro() implementation -- which will hopefully remind the coder. Trawl through ALL LLSingleton subclass definitions, sprinkling in LLSINGLETON() or LLSINGLETON_EMPTY_CTOR() as appropriate. Remove all explicit constructor declarations, public or private, along with relevant 'friend class LLSingleton<myself>' declarations. Where destructors are declared, move them into private section as well. Where the constructor was inline but nontrivial, move out of class body. Fix several LLSingleton abuses revealed by making ctors/dtors private: LLGlobalEconomy was both an LLSingleton and the base class for LLRegionEconomy, a non-LLSingleton. (Therefore every LLRegionEconomy instance contained another instance of the LLGlobalEconomy "singleton.") Extract LLBaseEconomy; LLGlobalEconomy is now a trivial subclass of that. LLRegionEconomy, as you might suspect, now derives from LLBaseEconomy. LLToolGrab, an LLSingleton, was also explicitly instantiated by LLToolCompGun's constructor. Extract LLToolGrabBase, explicitly instantiated, with trivial subclass LLToolGrab, the LLSingleton instance. (WARNING: LLToolGrabBase methods have an unnerving tendency to go after LLToolGrab::getInstance(). I DO NOT KNOW what should be the relationship between the instance in LLToolCompGun and the LLToolGrab singleton instance.) LLGridManager declared a variant constructor accepting (const std::string&), with the comment: // initialize with an explicity grid file for testing. As there is no evidence of this being called from anywhere, delete it. LLChicletBar's constructor accepted an optional (const LLSD&). As the LLSD parameter wasn't used, and as there is no evidence of it being passed from anywhere, delete the parameter. LLViewerWindow::shutdownViews() was checking LLNavigationBar:: instanceExists(), then deleting its getInstance() pointer -- leaving a dangling LLSingleton instance pointer, a land mine if any subsequent code should attempt to reference it. Use deleteSingleton() instead. ~LLAppViewer() was calling LLViewerEventRecorder::instance() and then explicitly calling ~LLViewerEventRecorder() on that instance -- leaving the LLSingleton instance pointer pointing to an allocated-but-destroyed instance. Use deleteSingleton() instead.
2016-08-30Automated merge with ssh://bitbucket.org/lindenlab/viewer-releaseNat Goodspeed
2015-11-10remove execute permission from many files that should not have itOz Linden
2015-05-22MAINT-5232: Clean up some dubious LLSingleton methods.Nat Goodspeed
Remove evil getIfExists() method, used by no one. Remove evil destroyed() method, used in exactly three places -- one of which is a test. Replace with equally evil instanceExists() method, which is used EVERYWHERE -- sigh.
2013-08-09second phase summer cleaningRichard Linden
replace llinfos, lldebugs, etc with new LL_INFOS(), LL_DEBUGS(), etc.
2013-06-05merge with viewer-releaseRichard Linden
2013-05-05Spring cleaning: removed unused .cpp and.h files, and cleaned up header ↵Richard Linden
dependencies
2013-03-29Update Mac and Windows breakpad builds to latestGraham Madarasz
2012-08-09Pull and merge from ssh://hg@bitbucket.org/lindenlab/viewer-development.Todd Stinson
2012-07-27Pull and merge from ssh://hg@bitbucket.org/lindenlab/viewer-release.Todd Stinson
2012-07-18MAINT-1175: Ditch LLTypeInfoLookup, make map<const type_info*> work.Nat Goodspeed
Instead of forbidding std::map<const std::type_info*, ...> outright (which includes LLRegistry<const std::type_info*, ...> and LLRegistrySingleton<const std::type_info*, ...>), try to make it work by specializing std::less<const std::type_info*> to use std::type_info::before(). Make LLRegistryDefaultComparator<T> use std::less<T> so it can capitalize on that specialization.
2012-07-18MAINT-1175: merge backout LLRegistrySingleton<std::type_info::name()>Nat Goodspeed
2012-07-18Backed out changeset a25bfa87418d (using std::type_info::name())Nat Goodspeed
The changeset above touched every consumer of the two LLRegistrySingletons originally defined with std::type_info* as keys. Those two LLRegistrySingletons were changed to use const char* as keys, then all consumers were changed to pass std::type_info::name() instead of the plain std::type_info* pointer -- to deal with the observed fact that on Linux, a given type might produce different std::type_info* pointers in different load modules. Since then, Richard turned up the fascinating fact that at least some implementations of gcc's std::type_info::before() method already accommodate this peculiarity. It seems worth backing out the (dismayingly pervasive) change to see if properly using std::type_info::before() as the map comparator will work just as well, with conceptually simpler source code. This backout is transitional: we don't expect things to build/run properly until we've cherry-picked certain other pertinent changes.
2012-07-12MAINT-1175: Linux viewer built on TC is broken, built on dev box works.Nat Goodspeed
Try to diagnose the cause of the misbehavior with a BOOST_STATIC_ASSERT.
2012-07-11MAINT-1175: Properly pass LLRegistry's COMPARATOR to underlying map.Nat Goodspeed
Although LLRegistry and LLRegistrySingleton have always defined a COMPARATOR template parameter, it wasn't used for the underlying map. Therefore every type, including any pointer type, was being compared using std::less. This happens to work most of the time -- but is tripping us up now. Pass COMPARATOR to underlying std::map. Fix a couple minor bugs in LLRegistryDefaultComparator (never before used!). Specialize for const char*. Remove CompareTypeID and LLCompareTypeID because we now actively forbid using LLRegistry<std::type_info*, ...>; remove only known reference (LLWidgetNameRegistry definition).
2012-07-11MAINT-1175: Forbid LLRegistry[Singleton]<std::type_info*, ...>.Nat Goodspeed
Back out code that selects LLTypeInfoLookup for the underlying map implementation when KEY = [const] std::type_info*, because LLTypeInfoLookup's API is changing to become incompatible with std::map. Instead, fail with STATIC_ASSERT when LLRegistry's KEY is [const] std::type_info*. Fix all existing uses to use std::type_info::name() string instead.
2012-04-11Fix Linux UI issues introduced by moving llinitparam to llcommon.Nat Goodspeed
In a number of places, the viewer uses a lookup based on std::type_info*. We used to use std::map<std::type_info*, whatever>. But on Linux, &typeid(SomeType) can produce different pointer values, depending on the dynamic load module in which the code is executed. Introduce LLTypeInfoLookup<T>, with an API that deliberately mimics std::map<std::type_info*, T>. LLTypeInfoLookup::find() first tries an efficient search for the specified std::type_info*. But if that fails, it scans the underlying container for a match on the std::type_info::name() string. If found, it caches the new std::type_info* to optimize subsequent lookups with the same pointer. Use LLTypeInfoLookup instead of std::map<std::type_info*, ...> in llinitparam.h and llregistry.h. Introduce LLSortedVector<KEY, VALUE>, a std::vector<std::pair<KEY, VALUE>> maintained in sorted order with binary-search lookup. It presents a subset of the std::map<KEY, VALUE> API.
2012-01-20removed LLXUIXML libraryRichard Linden
moved LLInitParam, and LLRegistry to llcommon moved LLUIColor, LLTrans, and LLXUIParser to llui reviewed by Nat