< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index Next in Thread >

RE: [reSIProcate] Really Strange compiler behaviour


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
 
Phone:
Fax:
e-mail:
Web:
+49.89.143370-0
+49.89.143370-22
info@xxxxxxxxxxxx
www.terasens.com
 


From: resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx [mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Alexander Altshuler
Sent: Friday, April 21, 2006 8:45 AM
To: resiprocate-devel@xxxxxxxxxxxxxxxxxxx
Subject: RE: [reSIProcate] Really Strange compiler behaviour

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

 

Hi,

 

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