[reSIProcate] Really Strange compiler behaviour

Fri Apr 21 10:18:57 CDT 2006

Scott,

are you using a ServerAuthManager? For me everything
worked fine until I implemented server authentication.
Even this worked as long as there is no OK message
sent (for auth success). Only in this case the problem
occurs because the target of the dum command is an 
invalid object.

I now have an idea why the target command is not 
traversed in the ServerAuthManager's constructor:

I use the following to construct my ServerAuthManager:

MyServerAuthManager::MyServerAuthManager(CTSPILineConnection* pLine, CTSPIAddressInfo* pAddr) :

ServerAuthManager(*pLine->GetDum(),pLine->GetDum()->dumIncomingTarget())

{

m_pLine = pLine; 

m_pAddr = pAddr;

}

The problem might be that dum->dumIncomingTarget() returns an
object that is actually an abstract class i.e. it can't exist as an
object but only as a pointer. 

When I try the following:

resip::DialogUsageManager::IncomingTarget mTarget(mDum->dumIncomingTarget());

I get an error as well (cannot instantiate abstract class). So if this
fails, I think it's no wonder that it fails in the constructor, too. In fact
if I debug the dumIncomingTarget() function I can see that it 
returns an invalid object, so I think this is where the problem really 
lies. 

I am not sure if the following is valid anyway:
IncomingTarget* mIncomingTarget;

TargetCommand::Target& dumIncomingTarget() 

{

        return *mIncomingTarget;

}

So this function actually returns IncomingTarget& but not Target&.
Can we expect that this is automatically casted correctly?
It seems not, because this function does not return anything valid,
at least not with VS 2005.

I would tend to change this stuff to use pointers, but this would surely
break some applications (e.g. repro). Or rather try to make 
TargetCommand::Target non-abstract, could this help. What do you think?

Matthias

________________________________

	From: Scott Godin [mailto:slgodin at icescape.com] 
	Sent: Friday, April 21, 2006 4:40 PM
	To: Matthias Moetje - TERASENS GmbH; Alexander Altshuler; resiprocate-devel at list.sipfoundry.org
	Subject: RE: [reSIProcate] Really Strange compiler behaviour

	I'm using VS.NET 2005 and don't have these problems - I have no idea why you are seeing this.  Have you tried to eliminate your application / settings from the picture and see if BasicCall behaves the same way?

	Scott

________________________________

	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 10:11 AM
	To: Alexander Altshuler; resiprocate-devel at list.sipfoundry.org
	Subject: RE: [reSIProcate] Really Strange compiler behaviour

	Alex,

	thanks for the tip, but this didn't solve the problem.

	I have now converted the TargetCommand class to 

	use a pointer to dum instead of passing it by value

	and now it works. 

	Seems that VS 2005 is a bit more restrictive with 

	passing objects by value (or it just has a bug..?). 

	At least it is said to be more standards conformant 

	than all previous versions.

	Unfortunately this is not all. A similar problem occurs

	in the constructor of ServerAuthManager when it 

	should be initialized with dumIncomingTarget().

	I suspect all this might be due to the fact that the 

	IncomingTarget and Outgoing target classes are

	declared privately within DialogUsageManager?

	I will now try to move these outside of the dum 

	class...

	Best regards,

	Matthias Moetje

TERASENS GmbH
Augustenstraße 24
80333 Munich
GERMANY

Phone:
Fax:
e-mail:
Web:

+49.89.143370-0
+49.89.143370-22
info at terasens.com <mailto:info at terasens.com> 
www.terasens.com <http://www.terasens.com/> 

________________________________

		From: resiprocate-devel-bounces at list.sipfoundry.org [mailto:resiprocate-devel-bounces at list.sipfoundry.org] On Behalf Of Alexander Altshuler
		Sent: Friday, April 21, 2006 8:45 AM
		To: resiprocate-devel at list.sipfoundry.org
		Subject: RE: [reSIProcate] Really Strange compiler behaviour

		Delete all files (.obj, .pdb etc) in Debug directory by hand.

		Recompile the project.

		Sometimes it works.

		Alex

		-----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/701e15b0/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/701e15b0/attachment.jpg>