There were two constuctors offering essentially the same functionality.
One taking the QStatic*Data<N> struct, the other what essentially
amounts to a pointer wrapper of that struct. The former was dropped and
the latter untemplatized and kept, as that is the most generic and
widely applicable. The template parameter in the wrapper was not very
useful as it essentially duplicated information that already maintained
in the struct, and there were no consistency checks to ensure they were
in sync.
In this case, using a wrapper is preferred over the use of naked
pointers both as a way to make explicit the transfer of ownership as
well as to avoid unintended conversions. By using the reference count
(even if only by calling deref() in the destructor), QByteArray and
QString must own their Data pointers.
Const qualification was dropped from the member variable in these
wrappers as it causes some compilers to emit warnings on the lack of
constructors, and because it isn't needed there.
To otherwise reduce noise, QStatic*Data<N> gained a member function to
directly access the const_cast'ed naked pointer. This plays nicely with
the above constructor. Its use also allows us to do further changes in
the QStatic*Data structs with fewer changes in remaining code. The
function has an assert on isStatic(), to ensure it is not inadvertently
used with data that requires ref-count operations.
With this change, the need for the private constructor taking a naked
Q*Data pointer is obviated and that was dropped too.
In updating QStringBuilder's QConcatenable specializations I noticed
they were broken (using data, instead of data()), so a test was added to
avoid this happening again in the future.
An unnecessary ref-count increment in QByteArray::clear was also
dropped.
Change-Id: I9b92fbaae726ab9807837e83d0d19812bf7db5ab
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
a959f34d71