Alex,
thanks for the tip, but this didn't solve the
problem.
I
have now converted the TargetCommand class to
use
a pointer to dum instead of passing it by value
and
now it works.
Seems that VS 2005 is a bit more restrictive with
passing objects by value (or it just has
a bug..?).
At
least it is said to be more standards conformant
than
all previous versions.
Unfortunately this is not all. A similar
problem occurs
in the constructor of ServerAuthManager when
it
should be initialized with
dumIncomingTarget().
I suspect all this might be due to the fact
that the
IncomingTarget and Outgoing target classes
are
declared privately within
DialogUsageManager?
I will now try to move these outside of the
dum
class...
Best regards,
Matthias Moetje
|
TERASENS
GmbH Augustenstraße 24 80333 Munich GERMANY |
|
|
Delete all files
(.obj, .pdb etc) in Debug directory by hand.
Recompile the
project.
Sometimes it
works.
Alex
-----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
|