[reSIProcate] Really Strange compiler behaviour

[Karl Mutch]

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/20060421/cfdc69f0/attachment.htm>