[reSIProcate] Really Strange compiler behaviour

[Karl Mutch]

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 at list.sipfoundry.org [mailto:resiprocate-devel-bounces at list.sipfoundry.org] On Behalf Of Matthias Moetje - TERASENS GmbH
			Sent: Friday, April 21, 2006 6: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/20060421/d4a348be/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 2937 bytes
Desc: image001.jpg
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20060421/d4a348be/attachment.jpg>