AW: [reSIProcate] Really Strange compiler behaviour

[Matthias Moetje - TERASENS GmbH]

Karl,
 
you are right, that didn't help. But making the TargetCommand::Target
non-abstract didn't work either: Casting the IncomingTarget pointer to a Target
pointer returned NULL.
 
Maybe this is because the IncomingTarget class is declared private in
DialogUsageManager? Or should I try to put IncomingTarget or Target
as separate classes (out of their containing classes)?
 
Since I have no idea what's going on here i can only try things... :-(
 
Do you have a better idea?
 
Thanks very much,
 
Matthias

________________________________

Von: Karl Mutch [mailto:kmutch at sonimtech.com]
Gesendet: Fr 21.04.2006 21:28
An: Matthias Moetje - TERASENS GmbH; resiprocate-devel at list.sipfoundry.org
Betreff: RE: [reSIProcate] Really Strange compiler behaviour


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 at terasens.com] 
Sent: Friday, April 21, 2006 10:19 AM
To: Karl Mutch; Scott Godin; Alexander Altshuler; resiprocate-devel at list.sipfoundry.org
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
 
 


________________________________

	From: Karl Mutch [mailto:kmutch at sonimtech.com] 
	Sent: Friday, April 21, 2006 6:26 PM
	To: Matthias Moetje - TERASENS GmbH; Scott Godin; Alexander Altshuler; resiprocate-devel at list.sipfoundry.org
	Subject: RE: [reSIProcate] Really Strange compiler behaviour
	
	
	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/20060422/6307b06f/attachment.htm>