|
Point taken on the code etc ... One of the things that
could be happening is that as
the MSVC compiler matures it could be revealing
problems areas of code that in the
past worked as a result of a less aggressive compiler
etc.
Even using pointers I think there will still be a
partially constructed object.
Thanks
Karl
From: Matthias Moetje -
TERASENS GmbH [mailto:moetje@xxxxxxxxxxxx]
Sent: Friday, April 21,
2006 10:19 AM
To: Karl Mutch; Scott Godin; Alexander Altshuler;
resiprocate-devel@xxxxxxxxxxxxxxxxxxx
Subject: RE: [reSIProcate]
Really Strange compiler behaviour
Karl,
thanks very much for your comments. I need to note that
this
is not my code, it's the code that already existed and
probably it has worked on some compilers/platforms and on
others (e.g. VS 2005) perhaps no one has actually been using
the
feature that makes this error relevant.
To
me it seems that using pointers would be the best solution
to
fix this, even if it breaks existing applications (but
actually
it
won't be much more than replacing the & with a * in a
derived ServerAuthManager and maybe deleting some *
operators.
Best,
Matthias
I believe the problem you are having is that you are using the this
pointer of a
partially constructed object.and passing it into another
constructor. If this does
work then it is purely by chance/side effect etc, especially if you are
using this
code in a release build with MSVC. In any event I dont think this
is really legal ?
Boost provides a means for controlling the order of member
initialization that may
help your chicken and egg situation, which leads me to a rant about why
are we
not using boost, memory leaks et al, but I will restrain myself
;-)
Thanks
Karl
-----Original
Message-----
From:
resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx
[mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Matthias Moetje -
TERASENS GmbH
Sent:
Friday, April 21, 2006 6:31 AM
To:
resiprocate-devel@xxxxxxxxxxxxxxxxxxx
Subject: [reSIProcate] Really
Strange compiler behaviour
I am
experiencing some really strange behaviour on the
following lines in the
constructor of DialogUsageManager:
mIncomingTarget = new IncomingTarget(*this);
mOutgoingTarget = new OutgoingTarget(*this);
Actually the objects are
created through _nh_malloc_dbg
when I debug through the generic
runtime implementation
of the new operator; afterwards the
constructors of
the object and the inherited objects are called.
Though,
in the end the result from the new operator is not
assigned
to the pointer variable i.e. in the end the pointer
variable
is NULL.
But if I note the pointer
from the operator new implementation
and assign it to the variable(s)
manually in the debugger, everything
is fine!
Seems very strange to me!
I'm using VS.NET 2005. All I could
think of here is probably the way
the dum object itself is
passed into the constructor
(*this)..?
Does anyone have an idea
why this happens? I thought of
passing dum as a pointer instead, but
that would require a
change to dum itself...
I would be very thankful
for any hints on this, I have no other
idea about
that...
Best
regards,
Matthias
Moetje
|