[omniORB] VisiBroker x Omni: Modules and Tie implementations

[Brenneis, Steve]

It looks like VisiBroker didn't want to give up their class mapping. I had
understood that the version 4.x VisiBroker IDL compiler was now mapping
module to namespace, but maybe this doesn't apply to tie implementations (VB
calls them class templates). Chapter 15 of the VB 4 Programmers reference
dodges the question altogether by avoiding a module declaration in their
example IDL. It looks like they are generating the tie implementation in the
global namespace and the extra value in the class name is to avoid
collisions. They might also be doing this in an attempt to peacefully
coexist with Microsoft VC 5 and 6 since both of those compilers have some
lookup problems with namespaces, especially in templates and nested classes.
I haven't ever run into a case using omniORB and Visual C++, though, where
that was a problem. The only version of VB 4 I have at the moment is for
Java, so I can't give you a more intelligent answer, someone else on the
list might be able to do better.

As for the specs, they understandably avoid requiring implementations to
support the namespace mapping since there are still a surprising number of
C++ compilers out there that do not support namespaces.

HTH
Steve Brenneis
Developer-II
AT&T Wireless
Desk: (336) 286-1783
Cell: (336) 456-3290
Fax: (336) 286-1880
Steve.Brenneis@attws.com


-----Original Message-----
From: Philippe de M. Sevestre [mailto:phil@dedalus.net]
Sent: Monday, November 06, 2000 3:28 PM
To: omniorb-list@uk.research.att.com
Subject: [omniORB] VisiBroker x Omni: Modules and Tie implementations


Hi,

I'm developing an online banking application unsing both omniORB (3.x) and
VisiBroker C++ (4.0) (please don't ask the reasoning behind this...) and
there are porting issues from one ORB to the other that look bit odd. From
these issues, the idl compiler names generated for tie implementations is
the one the most intrigating for me. It goes like this:

Given the following IDL:

module A {

	interface A1 {

		....
	};

};

module B {
	interface B1 : public A::A1 {
		....
	};
};


For omniORB, one can declare use the generated tie for I_B like that:

POA_B::B1_tie< B1_implementation> myB1;


Using VisiBroker, myI_B must be declared as:

POA_B1_B_tie< B1_implementation> myB1;


OmniORB's way makes more sense to me, but, reading the specs, I couldn't
find a good reason that would support an statement saying that VB is wrong.

My code now is using a lot of typedef's, but I think that the whole point
of using POAs would be the 'P' on it, right ? Anyone has a similar
experience with this kind os cross-orb problems ?


TYA,

Philippe.