Only re-use the existing reference if
it is large enough to hold all the new data.
If it isn't then throw it away to avoid
copying its current contents during
the resize().
Call when appropriate (putFrom(), copyIn(), and replace()).
Not called by swap(), take(), reuse(), or shareData().
Users of the second set of methods are expected to call
one of the methods in the first set, or call postPut() directly.
Document when postPut is (not) called.
* In PVScalarArray
Add methods assign, getAs/putFrom, and copyOut/copyIn to allow get/put
with implicit convert.
assign() copys on PVScalarArray to another converting as necessary.
If the types do not match then an allocate and convert is done.
getAs/putFrom work with shared_vector<T> and can avoid a allocate
and convert operation if the types match.
copyOut/copyIn use plain C arrays will do either a copy if the types
match, and a convert otherwise. No allocation is performed.
* In PVValueArray<T>
All array operations re-implemented in terms of
two virtual methods
virtual const shared_vector<T>& viewUnsafe() const;
virtual void swap(shared_vector<T>&);
Some convienence methods are also included:
shared_vector<const T> view() const
shared_vector<T> take()
shared_vector<T> reuse()
Deprecate get(...), put(...), and shareData(...)
Remove getVector() and getSharedVector()
Adjust DefaultPVArray accordingly
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<>
