a959f34d71
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> |
||
---|---|---|
.. | ||
auto | ||
baselineserver | ||
benchmarks | ||
global | ||
manual | ||
shared | ||
README | ||
tests.pro |
This directory contains autotests and benchmarks based on QTestlib. In order to run the autotests reliably, you need to configure a desktop to match the test environment that these tests are written for. Linux X11: * The user must be logged in to an active desktop; you can't run the autotests without a valid DISPLAY that allows X11 connections. * The tests are run against a KDE3 or KDE4 desktop. * Window manager uses "click to focus", and not "focus follows mouse". Many tests move the mouse cursor around and expect this to not affect focus and activation. * Disable "click to activate", i.e., when a window is opened, the window manager should automatically activate it (give it input focus) and not wait for the user to click the window.