| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Reviewed-by: Trust Me
|
| |
|
|
|
|
| |
We cannot create too many threads on Windows CE.
Reviewed-By: thartman
|
| |
|
|
|
|
| |
There's no time() on Windows CE.
Reviewed-by: Daniel Molkentin
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With the previous commit, you could create a QWeakPointer from any
QObject-derived object. It's possible because QObject now has a
pointer to the QWeakPointer's d-pointer.
However, if you did:
QSharedPointer<QObject> obj(new QObject);
QWeakPointer<QObject> weak1(obj);
QWeakPointer<QObject> weak2(obj.data());
Then weak1 would shared d-pointers with QSharedPointer, but weak2
wouldn't. Also, weak1.toStrongRef() would work, but
weak2.toStrongRef() wouldn't.
This change makes QObject know where the d-pointer created by
QSharedPointer is, so weak2 would get the same d-pointer.
As a nice side-effect, you can check if a given QObject is shared by
trying to promote its QWeakPointer to QSharedPointer.
Reviewed-by: Bradley T. Hughes
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The problem with QPointer is that it's a simple QObject*. So the only
way for QPointer to do what it's supposed to do is if the object it's
pointing to clears all QPointers when getting deleted. That means the
QObject must know each and every QPointer pointing to it. To make
matters worse, QPointers can be deleted while the object they're
pointing to also gets deleted. So deleting QObjects must do locking.
The solution to the QPointer problem is that both QObject and the
"QPointer" reference something outside the QObject. This way,
QObject doesn't have to lock anything to destroy itself: it's simply
setting a volatile integer to zero when it gets deleted. Since the
integer is outside the QObject, the integer is also refcounted. It's also
O(1), so there's no problem having as many "QPointer".
The two-atomic-ints structure is exactly what QSharedPointer and
QWeakPointer use internally. We just abuse this structure for QObject
needs, setting the strong reference count to -1 to indicate that it's
a QObject that cannot be managed by a QSharedPointer. But QWeakPointer
can still work and replace QPointer neatly.
Reviewed-by: Bradley T. Hughes
Reviewed-by: Jarek Kobus
|
| |
|
|
|
|
| |
Also add some thread stress tests to try and detect doing it wrong.
Reviewed-By: Bradley T. Hughes
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, if you create a QSharedPointer in code with
pointer-tracking, you must ensure it gets deleted in code with
pointer-tracking, otherwise the internal safety tracker will be
"leaking" objects. The pointers would never get removed.
And if any new pointer happened to have the same pointer address
(which happens quite often), the tracker code would promptly abort the
application.
With this change, the untracking of the pointer is scheduled by the
same code that creates the tracking. This is done by "abusing" the
custom deleter code:
- for the QSharedPointer that used ExternalRefCountWithDestroyFn
already, we intercept the call to the destroy function and call the
untracking function
- for a normal QSharedPointer, we use the "normalDeleter" function as
custom deleter and chain up above
Note: the autotest only *really* works in release mode. Otherwise
functions don't get inlined and do get merged by the linker.
Reviewed-By: Bradley T. Hughes
|
| |
|
|
|
|
| |
Destructors have to be run for the subobjects we initialise.
Reviewed-By: Bradley T. Hughes
|
| |
|
|
|
|
|
| |
That way, this code can be compiled with an earlier version of Qt and
should still work in new ones.
Reviewed-by: Trust Me
|
| |
|
|
|
| |
In the future, it would be nice to split the autotest in multiple
functions at every check().
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
src/corelib/tools/qsharedpointer.cpp
src/corelib/tools/qsharedpointer_impl.h
src/gui/dialogs/qcolordialog.cpp
src/gui/painting/qwindowsurface_raster.cpp
src/network/access/qnetworkaccessmanager.cpp
tests/auto/qsharedpointer/externaltests.cpp
|
| | |
| |
| |
| |
| |
| |
| | |
The functionality these tests tested was broken in 4.5 and has been
disabled. Therefore, these tests simply cannot pass.
It's fixed in 4.6.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
If the user forgot to end their headers with a newline, the
compilation would fail because the next line is #include
<QtCore/QtCore>.
Reviewed-by: Jesper Thomschütz
|
| | |
| |
| |
| |
| |
| | |
No wonder QT_SHAREDPOINTER_TRACK_POINTERS was having no effect:
there was an #include <QtCore/QtCore> before it.
(cherry picked from commit 4c12010fac555bce0a6c8d69a267a56f4c15087f)
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
I added this test because I thought that the compiler would find the
forward-declarations due to the "one definition" rule. In hindsight,
it's not a good idea.
Sun CC warns about this, gcc doesn't. With Sun CC, the code leaks,
with gcc it doesn't.
|
| | |
| |
| |
| |
| | |
No wonder QT_SHAREDPOINTER_TRACK_POINTERS was having no effect:
there was an #include <QtCore/QtCore> before it.
|
| | |
| |
| |
| | |
This requires modifying slightl QProcess on Unix to forward stdin too.
|
| | |
| |
| |
| |
| |
| |
| | |
structure in QSharedPointer""
This restores the original implementation of the creating
function. The next commit will make it suitable for use.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
-developer-build, part 2.
Some autotests use private (unexported) code, either because they're
testing private classes or because that's the easiest way to test
the public classes. Configuring Qt with `-developer-build' is needed
for these tests.
This commit fixes the tests so configuring without `-developer-build'
only builds the tests which strictly use public API.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
QSharedPointer"
This reverts commit fb51a10ee0451274a430227566ae26efb2ac4474.
Sorry, it didn't work. I can fix the MSVC error, but the problem is
that older GCC versions (4.2) fail with the following code:
template<typename T> struct Buffer
{
char buffer[128] __attribute__((aligned(__alignof__(T))));
};
The same works fine in GCC 4.4.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
are declared in this file.
The one-definition rule allows the forward declaration appearing below to
apply to code that was earlier. Therefore, if the compiler finds out
how to delete the object, we can allow a QSharedPointer of a forward-
declared-type.
This means the actual problem is just a warning with g++. To catch the
error, we need a separate .cpp file and I'd rather run this as an
external test.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
one go.
This avoids one memory allocation. Currently, we only support calling
the default constructors. I will *NOT* implement argument passing for
C++03. I will implement it with rvalue references for C++0x-capable
compilers.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
This obviously only works for classes that derive from QObject. And
you must remember that QSharedPointer controls the QObject's lifetime,
not the QObject parent-child relationship.
Reviewed-by: dt
Reviewed-by: Bradley T. Hughes
|
| |/
|
|
| |
Reviewed-by: TrustMe
|
| |
|
|
|
|
|
|
|
| |
enabled.
This allows mixing of debug and non-debug code (possible on Unix
systems) without causing assertion failures.
Reviewed-by: Bradley T. Hughes <bradley.hughes@nokia.com>
|
| |
|
|
| |
Reviewed-by: Trust Me
|
| |
|
|
|
|
|
|
|
|
|
|
| |
It's wrong to assume that static_cast<> is allowed everywhere where
dynamic_cast<> is allowed. For example, if class C derives from both A
and B, then you can dynamic_cast<B *>(ptr_to_A), but you can't
static_cast.
So introduce a helper for dynamic casts that doesn't do
static_cast.
Reviewed-by: Olivier Goffart
|
| |
|
