tie or no_tie: What about tie and no_tie ?

tie or no_tie: What about tie and no_tie ?

Post by Sebastien MAR » Thu, 27 Aug 1998 04:00:00

Using the skeleton inheritance (no_tie) to implement the interfaces is
quite straightforward. All we have to do is to implement the pure virtual
functions defined in the skeleton.
Since it is straightforward, i'm not surprised to see that most of the
projects are using the skeleton inheritance approach (or at least begin
with it).

Problems begin when you have an interface inheriting from an other.
interface A


interface B


Using the no_tie approach you'll have something like that, generated by the
IDL compiler:
class _sk_A
a() =0;
b() = 0;


class _sk_B
a() = 0;
b() = 0;
c() = 0;
d() = 0;


The side effect is when you implement you class B, you have to re-implement
a() and b()! :
class BImpl: public _sk_B
// all four function have to be implemented since they are all pure virtual
in the skeleton


Of course this is not acceptable.
You could try:
class BImpl: public _sk_B, public AImpl
// ...code ....


But then you end-up with the dreaded inheritance diamond shape and some
ambiguities since the same functions a() and b() are defined in AImpl and
_sk_B.... We're stuck (unless i miss something.).

Then the tie approach begins to be particularly attractive since it allows
us transform the inheritance relation (between the skeleton and the
implementation) into a composition relation. Inheriting the implementations
begins to be possible.
Using the tie approach, the IDL compiler will generate something like this:

template <class T>
class _tie_A
_tie_A(T& r) {ref_=r;};
a() {return _ref.a();};
b() {return _ref.b();};
T& _ref;


template <class T>
class _tie_B
a() {return _ref.a();};
b() {return _ref.b();};
c() {return _ref.c();};
d() {return _ref.d();};
T& _ref;


To implemant A, we just have to create the following class:
class AImpl
a() {// some code};
b() {// some  other code};


In the server code we'll have:
AImpl theAImplementation;
_tie_A serverObject(theAImplementation);
// register the new object to the basic object adapter.

Then, to implement B we could just inherit from A:
class BImpl:public AImpl
c() {//some code};
d() {//some code};


And we achieve implementation inheritance.

I'm using Visibroker. One approach OR the other works fine, but i'd like to
use BOTH at the same time. I want to continue using the skeleton
inheritance approach where i have standalone interfaces, while using the
tie approach while i have inheritance in the interfaces. I don't see any
mean to do it in Visibroker since the flag to use tie or no_tie is given to
the IDL compiler and does not seems to be able to be overridden during the
compilation of the IDL file. Does anybody has ever use both approaches in
the same project ?.

Thanks for any comment.

Sebastien MARC
Project Leader
Sailfish systems (REUTERS)
44 Wall Street
10005 New-York
(212) 607 3013


1. TIE or BOA?


I sent this message yesterday, and it looks as it did not reach the
Forgive me if you get this twice.


We have a server written in C++ and clients in Java.

Our CORBA vendor is currently Iona, although it is possible we will
move to VisiBroker. The server is planed to run on a SPARC machine
running Solaris (compiler: SparcCompiler for C++), and the clients
are planed for WinNT (JBuilder).

Our current quandary is whether to use the TIE approach, or the
BOAImpl approach, while implementing our server.

We wonder which will run faster, which will result in a smaller
executable, and which is easier to implement and debug. Another
consideration is the future upgrading to the POA approach. Which one
will be easier to convert?


Amit and Gera
Amit Cohen
Orckit Communications Ltd.
Tel: 972-3-6966992 Ext. 112

2. Visit the truth

3. _deref() in a TIE implementation object

4. Datagrid

5. Tie mechanism the context of Visibroker

6. mac cgi scripts

7. tie implementation question

8. datetimepicker null value

9. Does USB tie up system?

10. Advice on Whole House lighting tied to H/A

11. disconnect tied to 8250 uart???

12. Ties in formula results