[reSIProcate] Really Strange compiler behaviour

[Matthias Moetje - TERASENS GmbH]

OK, I have finally fixed it. This has really cost me hours and 
I still don't know WHY the problem existed.
 
In the end it was that crazy that even the following code did 
not work:
 
void* test = (void*)mIncomingTarget;
 
After this line, test was 0 while I could verify in the debugger's
watch window that mIncomingTarget was a valid object
and I could browse its members. Really weird, isn't it?
 
The solution was to move the implementation code for
dumIncomingTarget and dumOutgoingTarget from the 
header file to the cxx file. I've already checked in the change.
 
Best regards,

Matthias Moetje


________________________________

	From: resiprocate-devel-bounces at list.sipfoundry.org
[mailto:resiprocate-devel-bounces at list.sipfoundry.org] On Behalf Of
Matthias Moetje - TERASENS GmbH
	Sent: Friday, April 21, 2006 4:31 AM
	To: resiprocate-devel at list.sipfoundry.org
	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

	 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20060423/639200a9/attachment.htm>