summaryrefslogtreecommitdiff
path: root/indra/llcommon/llsafehandle.h
AgeCommit message (Collapse)Author
2017-05-03DRTVWR-418: Add dtor to LLSafeHandle<T>::NullInstanceHolderNat Goodspeed
to suppress fatal warnings in Visual Studio.
2017-05-03DRTVWR-418: Add big deprecation notice to llsafehandle.h.Nat Goodspeed
2017-04-27DRTVWR-418: Use (protected) LLSingleton to store "null instance"Nat Goodspeed
of LLSafeHandle's referenced type. Using LLSingleton gives us a well-defined time at which the "null instance" is deleted: LLSingletonBase::deleteAll().
2017-03-30DRTVWR-418: Xcode 8.3 complains about LLSafeHandle<T> implementation.Nat Goodspeed
The previous LLSafeHandle<T> implementation declares a static data member of the template class but provides no (generic) definition, relying on particular specializations to provide the definition. The data member is a function pointer, which is called in one of the methods to produce a pointer to a "null" T instance: that is, a dummy instance to be dereferenced in case the wrapped T* is null. Xcode 8.3's version of clang is bothered by the call, in a generic method, through this (usually) uninitialized pointer. It happens that the only specializations of LLSafeHandle do both provide definitions. I don't know whether that's formally valid C++03 or not; but I agree with the compiler: I don't like it. Instead of declaring a public static function pointer which each specialization is required to define, add a protected static method to the template class. This protected static method simply returns a pointer to a function-static T instance. This is functionally similar to a static LLPointer<T> set on demand (as in the two specializations), including lazy instantiation. Unlike the previous implementation, this approach prohibits a given specialization from customizing the "null" instance function. Although there exist reasonable ways to support that (e.g. a related traits template), I decided not to complicate the LLSafeHandle implementation to make it more generally useful. I don't really approve of LLSafeHandle, and don't want to see it proliferate. It's not clear that unconditionally dereferencing LLSafeHandle<T> is in any way better than conditionally dereferencing LLPointer<T>. It doesn't even skip the runtime conditional test; it simply obscures it. (There exist hints in the code that at one time it might have immediately replaced any wrapped null pointer value with the pointer to the "null" instance, obviating the test at dereference time, but this is not the current functionality. Perhaps it was only ever wishful thinking.) Remove the corresponding functions and static LLPointers from the two classes that use LLSafeHandle.
2015-11-10remove execute permission from many files that should not have itOz Linden
2013-08-09second phase summer cleaningRichard Linden
replace llinfos, lldebugs, etc with new LL_INFOS(), LL_DEBUGS(), etc.
2013-03-29Update Mac and Windows breakpad builds to latestGraham Madarasz
2010-08-13Change license from GPL to LGPL (version 2.1)Oz Linden
2009-10-03Merge inspectors UI project, gooey-4, into viewer-2 trunk. Added new ↵James Cook
tooltips to 3D avatars, 2D avatar names, and 3D objects. Refactors tooltips and text boxes, line editors, and text editors. Breaks LLExpandableTextBox, but a fix is coming. Resolved conflicts in lltexteditor.cpp, llchatitemscontainerctrl.cpp, llchatmsgbox.cpp, llfloaterbuycurrency.cpp, llnearbychat.cpp, floater_buy_currency.xml, and ru/strings.xml Merging revisions 134925-135157 of svn+ssh://svn.lindenlab.com/svn/linden/branches/gooey/gooey-4 into C:\source\viewer-2.0.0-3, respecting ancestry
2009-06-21merge -r 122421-124917 viewer-2.0.0-2 -> viewer-2.0.0-3Steven Bennetts
ignore-dead-branch