RE: [reSIProcate] Really Strange compiler behaviour

["Karl Mutch" <kmutch@xxxxxxxxxxxxx>]

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@xxxxxxxxxxxx]
Sent: Friday, April 21, 2006 4:33 PM
To: Karl Mutch; resiprocate-devel@xxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxx]
Gesendet: Fr 21.04.2006 21:28
An: Matthias Moetje - TERASENS GmbH; resiprocate-devel@xxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxx]
Sent: Friday, April 21, 2006 10:19 AM
To: Karl Mutch; Scott Godin; Alexander Altshuler; resiprocate-devel@xxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxx]
Sent: Friday, April 21, 2006 6:26 PM
To: Matthias Moetje - TERASENS GmbH; Scott Godin; Alexander Altshuler; resiprocate-devel@xxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxx [mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Matthias Moetje - TERASENS GmbH
Sent: Friday, April 21, 2006 6:31 AM
To: resiprocate-devel@xxxxxxxxxxxxxxxxxxx
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