[reSIProcate] Really Strange compiler behaviour

Fri Apr 21 19:03:38 CDT 2006

You might find the only things that can be seen in memory
are those items explicitly initialized in the class constructor
initializer list or
in the body of the constructor itself.  Not sure on the exact wording of
the ANSI
standard on this but anything not explicitly stated in the standard
related to
the construction process will be left to the compiler implementer, and
of
course ends up being optimized, good for some, faster code, bad for
others,
something you have unfortunately inherited.

I have a feeling that unless something like a class factory is added you
will be
left with the difficulty, to 'reverse engineer' the exact behavior of
the generated 
asembler code the compiler push's out to see if you can workaround the
problem. 

Have you tried scattering volatiles around.  Maybe that can 'force' the
compiler to
generate different/inefficent asm  ? Along those lines take a look at
SFENCE, 
possibly dropping one in will cause the processor to stall clearing
everything 
out as well, very very bad bad for performance but if its the only
choice ?  Of 
course even with these your only disguising a design issue and someone
else
will see it possibly I imagine Intel C++ 9.0 and later will also barf ?

Thanks
Karl

Pushes again for boost. Boost Boost I love Boost I am one with the
Boost.  Boosty Boost use Boost !

Another fav is when people do "delete(*this);" in a method.

  _____  

From: Matthias Moetje - TERASENS GmbH [mailto:moetje at terasens.com] 
Sent: Friday, April 21, 2006 4:33 PM
To: Karl Mutch; resiprocate-devel at list.sipfoundry.org
Subject: AW: [reSIProcate] Really Strange compiler behaviour

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