Serializable -> SerializableArray
Serializable -> PVField
SerializableArray -> PVArray
PVField -> PVArray
Thus for PVArray the members of SerializeSerializable are reachable
by two paths. This means that The vtable for PVArray has two seperate
entries for serialize.
Correct resolution is to use virtual inheritance to avoid the
ambiguity.
The scalar and array value interface classes are largely
copy+paste so can easily be made templates PVScalarValue<>
and PVValueArray<>. Currently parametrized only by value
type.
Also the *ArrayData helpers become PVArrayData<>
Use auto_ptr<> for pImpl
Eliminate redundant ThreadListElement class. It just contains
a Thread* and a ThreadListNode which contains itself?
Make thread main function a static class function to avoid
problems with accessing private members of ThreadPvt.
In this context "private" means used by the implementation
class only.
update test baselines
rename showConstructDestruct.h to CDRMonitor.h
undercounting field
switch tests to CDRMonitor
switch remaining to use REFCOUNT macros
Use epicsThreadOnce for safe lazy initialization
replace ShowConstructDestruct with simpler CDRMonitor
executor: remove redundant allocations
lock: Partial implementation of Boost lock templates
Conflicts:
pvDataApp/misc/StatusCreateFactory.cpp
pvDataApp/misc/bitSet.cpp
Hold counters internally instead of exposing (and duplicating)
counting code in other compile units
Remove deleteFunc list. This should be handled by another mechanism.
CDRMonitor is debugging code.
Use internal singly linked list to avoid special handling of
LinkedList.
lock_guard - simple RAII for a mutex
unique_lock - Also allows release/re-acquire after
construction while ensuring that the mutex is
unlocked when the object is destructed.
