[Interest] C'tor member initialisation with 'this'

2014-01-10 Thread Frank Hemer
Hi,

when looking at the code of the qt solutions (from git), I realized following 
snippet:

class QT_QTSOAP_EXPORT QtSoapHttpTransport : public QObject
{
   ...
private:
QNetworkAccessManager networkMgr;
   ...
};

QtSoapHttpTransport::QtSoapHttpTransport(QObject *parent)
: QObject(parent), networkMgr(this)
{
   ...
}

Is there any reason why the QNetworkAccessManager needs to be initialized with 
the 'this' reference?
Seems like a wrong approach to me - maybe because it used to be a pointer at 
some point in time?

I found this when analyzing some weird and not really reproducible stack 
traces ...

Frank
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest


Re: [Interest] C'tor member initialisation with 'this'

2014-01-10 Thread Constantin Makshin
Everything is OK unless QNetworkAccessManager's constructor (or anything
further in the call chain) tries to use that pointer for anything beyond
copying it somewhere else. What exactly is looking suspicious to you?
On Jan 10, 2014 5:32 PM, Frank Hemer fr...@hemer.org wrote:

 Hi,

 when looking at the code of the qt solutions (from git), I realized
 following
 snippet:

 class QT_QTSOAP_EXPORT QtSoapHttpTransport : public QObject
 {
...
 private:
 QNetworkAccessManager networkMgr;
...
 };

 QtSoapHttpTransport::QtSoapHttpTransport(QObject *parent)
 : QObject(parent), networkMgr(this)
 {
...
 }

 Is there any reason why the QNetworkAccessManager needs to be initialized
 with
 the 'this' reference?
 Seems like a wrong approach to me - maybe because it used to be a pointer
 at
 some point in time?

 I found this when analyzing some weird and not really reproducible stack
 traces ...

 Frank
 ___
 Interest mailing list
 Interest@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/interest

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest


Re: [Interest] C'tor member initialisation with 'this'

2014-01-10 Thread Frank Hemer
On Friday 10 January 2014 20:51:35 Constantin Makshin wrote:
 Everything is OK unless QNetworkAccessManager's constructor (or anything
 further in the call chain) tries to use that pointer for anything beyond
 copying it somewhere else. What exactly is looking suspicious to you?

When the transports parent object gets deleted, it will delete the transport.
Thus I wonder whether it could cause a duplicate delete ('this' gets deleted 
and will subsequently delete the networkMgr but it is a member var and thus 
will be deleted twice?

Frank

 On Jan 10, 2014 5:32 PM, Frank Hemer fr...@hemer.org wrote:
  Hi,
  
  when looking at the code of the qt solutions (from git), I realized
  following
  snippet:
  
  class QT_QTSOAP_EXPORT QtSoapHttpTransport : public QObject
  {
  
 ...
  
  private:
  QNetworkAccessManager networkMgr;
 
 ...
  
  };
  
  QtSoapHttpTransport::QtSoapHttpTransport(QObject *parent)
  
  : QObject(parent), networkMgr(this)
  
  {
  
 ...
  
  }
  
  Is there any reason why the QNetworkAccessManager needs to be initialized
  with
  the 'this' reference?
  Seems like a wrong approach to me - maybe because it used to be a pointer
  at
  some point in time?
  
  I found this when analyzing some weird and not really reproducible stack
  traces ...
  
  Frank
  ___
  Interest mailing list
  Interest@qt-project.org
  http://lists.qt-project.org/mailman/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest


Re: [Interest] C'tor member initialisation with 'this'

2014-01-10 Thread Constantin Makshin
No, it won't. 'this' is just a pointer and copying it anywhere (except a
free-memory-in-destructor kind of smartpointer, of course, but using these
to store a pointer to the parent object is a weird idea anyway) doesn't
affect the object's lifetime in any way; neither does the object's
destructor gets called when a pointer to it is destroyed by going out of
scope or any other means.
On Jan 10, 2014 9:42 PM, Frank Hemer fr...@hemer.org wrote:

 On Friday 10 January 2014 20:51:35 Constantin Makshin wrote:
  Everything is OK unless QNetworkAccessManager's constructor (or anything
  further in the call chain) tries to use that pointer for anything beyond
  copying it somewhere else. What exactly is looking suspicious to you?

 When the transports parent object gets deleted, it will delete the
 transport.
 Thus I wonder whether it could cause a duplicate delete ('this' gets
 deleted
 and will subsequently delete the networkMgr but it is a member var and thus
 will be deleted twice?

 Frank

  On Jan 10, 2014 5:32 PM, Frank Hemer fr...@hemer.org wrote:
   Hi,
  
   when looking at the code of the qt solutions (from git), I realized
   following
   snippet:
  
   class QT_QTSOAP_EXPORT QtSoapHttpTransport : public QObject
   {
  
  ...
  
   private:
   QNetworkAccessManager networkMgr;
  
  ...
  
   };
  
   QtSoapHttpTransport::QtSoapHttpTransport(QObject *parent)
  
   : QObject(parent), networkMgr(this)
  
   {
  
  ...
  
   }
  
   Is there any reason why the QNetworkAccessManager needs to be
 initialized
   with
   the 'this' reference?
   Seems like a wrong approach to me - maybe because it used to be a
 pointer
   at
   some point in time?
  
   I found this when analyzing some weird and not really reproducible
 stack
   traces ...
  
   Frank
   ___
   Interest mailing list
   Interest@qt-project.org
   http://lists.qt-project.org/mailman/listinfo/interest
 ___
 Interest mailing list
 Interest@qt-project.org
 http://lists.qt-project.org/mailman/listinfo/interest

___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest


Re: [Interest] C'tor member initialisation with 'this'

2014-01-10 Thread Frank Hemer
On Friday 10 January 2014 21:58:13 Constantin Makshin wrote:
 No, it won't. 'this' is just a pointer and copying it anywhere (except a
 free-memory-in-destructor kind of smartpointer, of course, but using these
 to store a pointer to the parent object is a weird idea anyway) doesn't
 affect the object's lifetime in any way; neither does the object's
 destructor gets called when a pointer to it is destroyed by going out of
 scope or any other means.

Well, I was confused by the QObject d'tor doc stating:

Warning: All child objects are deleted. If any of these objects are on the 
stack or global, sooner or later your program will crash. We do not recommend 
holding pointers to child objects from outside the parent. If you still do, 
the destroyed() signal gives you an opportunity to detect when an object is 
destroyed.

And the networkMgr is on the stack.

Frank


 On Jan 10, 2014 9:42 PM, Frank Hemer fr...@hemer.org wrote:
  On Friday 10 January 2014 20:51:35 Constantin Makshin wrote:
   Everything is OK unless QNetworkAccessManager's constructor (or anything
   further in the call chain) tries to use that pointer for anything beyond
   copying it somewhere else. What exactly is looking suspicious to you?
  
  When the transports parent object gets deleted, it will delete the
  transport.
  Thus I wonder whether it could cause a duplicate delete ('this' gets
  deleted
  and will subsequently delete the networkMgr but it is a member var and
  thus
  will be deleted twice?
  
  Frank
  
   On Jan 10, 2014 5:32 PM, Frank Hemer fr...@hemer.org wrote:
Hi,

when looking at the code of the qt solutions (from git), I realized
following
snippet:

class QT_QTSOAP_EXPORT QtSoapHttpTransport : public QObject
{

   ...

private:
QNetworkAccessManager networkMgr;
   
   ...

};

QtSoapHttpTransport::QtSoapHttpTransport(QObject *parent)

: QObject(parent), networkMgr(this)

{

   ...

}

Is there any reason why the QNetworkAccessManager needs to be
  
  initialized
  
with
the 'this' reference?
Seems like a wrong approach to me - maybe because it used to be a
  
  pointer
  
at
some point in time?

I found this when analyzing some weird and not really reproducible
  
  stack
  
traces ...

Frank
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
  
  ___
  Interest mailing list
  Interest@qt-project.org
  http://lists.qt-project.org/mailman/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest


Re: [Interest] C'tor member initialisation with 'this'

2014-01-10 Thread Giuseppe D'Angelo
On 10 January 2014 19:09, Frank Hemer fr...@hemer.org wrote:
 On Friday 10 January 2014 21:58:13 Constantin Makshin wrote:
 No, it won't. 'this' is just a pointer and copying it anywhere (except a
 free-memory-in-destructor kind of smartpointer, of course, but using these
 to store a pointer to the parent object is a weird idea anyway) doesn't
 affect the object's lifetime in any way; neither does the object's
 destructor gets called when a pointer to it is destroyed by going out of
 scope or any other means.

 Well, I was confused by the QObject d'tor doc stating:

 Warning: All child objects are deleted. If any of these objects are on the
 stack or global, sooner or later your program will crash. We do not recommend
 holding pointers to child objects from outside the parent. If you still do,
 the destroyed() signal gives you an opportunity to detect when an object is
 destroyed.

 And the networkMgr is on the stack.

It's not on the stack; it's a member. This means it will be properly
destroyed at the end of the QtSoapHttpTransport's destructor, which
will run before QObject's destructor. The destruction code of QNAM
(actually, of its QObject subobject) will remove it from the parent
children list. So when the QObject destructor (for the QObject
sub-object of QtSoapHttpTransport), it won't double delete anything.

-- 
Giuseppe D'Angelo
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest


Re: [Interest] C'tor member initialisation with 'this'

2014-01-10 Thread Jan Kundrát
The C++'s order of destruction is, in this case:

1) ~QtSoapHttpTransport(), which does more or less nothing. By the time it 
returns, the object is no longer a QSHT (which is the reason why you must 
not call virtual methods from destructors).

2) Any member variables are destroyed. In this case, one if them is a QNAM 
which derives from QObject, so at some point the ~QObject() of the QNAM 
runs, and at that time the QNAM is removed from the list of children of its 
parent QObject, which is the former QSHT. This is safe, because 
QSHT::~QObject has not run yet, so the former QSHT is still an QObject.

3) QSHT::~QObject runs, finally. It checks the list of its children, but 
that list does not include the already destroyed QNAM, so the former QNAM 
is not deleted twice and everything is OK.

Yup, took me some time to understand this as well -- thanks for ab 
excellent question.

Cheers,
Jan

-- 
Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest


Re: [Interest] C'tor member initialisation with 'this'

2014-01-10 Thread Frank Hemer
On Friday 10 January 2014 20:35:56 Jan Kundrát wrote:
 The C++'s order of destruction is, in this case:
 
 1) ~QtSoapHttpTransport(), which does more or less nothing. By the time it
 returns, the object is no longer a QSHT (which is the reason why you must
 not call virtual methods from destructors).
 
 2) Any member variables are destroyed. In this case, one if them is a QNAM
 which derives from QObject, so at some point the ~QObject() of the QNAM
 runs, and at that time the QNAM is removed from the list of children of its
 parent QObject, which is the former QSHT. This is safe, because
 QSHT::~QObject has not run yet, so the former QSHT is still an QObject.
 
 3) QSHT::~QObject runs, finally. It checks the list of its children, but
 that list does not include the already destroyed QNAM, so the former QNAM
 is not deleted twice and everything is OK.
 
 Yup, took me some time to understand this as well -- thanks for an
 excellent question.

Thanks for the comprehensive explanation:-)

@Thiago: Good hint - never thought of that.

Frank
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest