The updater is required to survive beyond termination of the viewer that
launched it so it can launch the next installer, or a replacement viewer.
Having the old viewer forcibly terminate it on shutdown would be counter-
productive.
Introduce a third LLLeap::create() overload taking LLProcess::Params, which
gives access to autokill, cwd and other options previously unsupported by
LLLeap. Reimplement the existing create() overloads in terms of this new one,
since LLLeapImpl::LLLeapImpl() is already based on LLProcess::Params anyway.
Use LLProcess::Params in LLAppViewer::init() to specify the updater process,
setting autokill=false.
Refactoring LLLeapImpl() apparently involved engaging an LLInitParam::Block
feature never before used: had to drag operator() into Multiple from its base
class TypedParam (as has been done in other TypedParam subclasses).
A particular LLInitParam::TypeValuesHelper specialization is derived from a
different TypeValuesHelper specialization. The subclass constructor
TypeValuesHelper(...) has previously forwarded the call to its base-class
constructor with:
TypeValuesHelper(val): TypeValuesHelper(val) {}
This is the first time I've looked at that; I'm a bit surprised that previous
compilers blithely accept it, and apparently understand the intent. gcc 4.7
complains that we would need to turn on -std=c++11 to support delegating
constructors; obviously the second TypeValuesHelper is now assumed to be the
class being defined, rather than its base class.
Fortunately the class already has typedefs for both specializations, fully
qualified with all template parameters, so I simply replaced the second
TypeValuesHelper reference with base_t.
cleaning up build
moved most includes of windows.h to llwin32headers.h to disable min/max macros, etc
streamlined Time class and consolidated functionality in BlockTimer class
llfasttimer is no longer included via llstring.h, so had to add it manually in several places
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.
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).
Per discussion with Richard, accept the type key for insert() and find() as a
template parameter rather than as std::type_info*. This permits (e.g.) some
sort of compile-time prehashing for common types, without changing the API.
Eliminate iterators from the API altogether, thus avoiding costs associated
with transform_iterator.
Fix existing references in llinitparam.h.
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.
Ansariel Hiller