1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"
"http://www.w3.org/TR/REC-html40/loose.dtd">
<HTML>
<HEAD>
<META http-equiv="Content-Type" content="text/html; charset=US-ASCII">
<META name="GENERATOR" content="hevea 1.10">
<LINK rel="stylesheet" type="text/css" href="omniORB.css">
<TITLE>C++ language mapping</TITLE>
</HEAD>
<BODY >
<A HREF="omniORB002.html"><IMG SRC="previous_motif.gif" ALT="Previous"></A>
<A HREF="index.html"><IMG SRC="contents_motif.gif" ALT="Up"></A>
<A HREF="omniORB004.html"><IMG SRC="next_motif.gif" ALT="Next"></A>
<HR>
<H1 CLASS="chapter"><A NAME="htoc40">Chapter 3</A>  C++ language mapping</H1><P>Now that you are familiar with the basics, it is important to
familiarise yourself with the standard IDL to C++ language mapping.
The mapping is described in detail in [<A HREF="omniORB014.html#cxxmapping">OMG03</A>]. If you have
not done so, you should obtain a copy of the document and use that as
the programming guide to omniORB.</P><P>The specification is not an easy read. The alternative is to use one
of the books on CORBA programming that has begun to appear. For
instance, Henning and Vinoski’s ‘Advanced CORBA Programming with
C++’ [<A HREF="omniORB014.html#henning1999">HV99</A>] includes many example code bits to illustrate
how to use the C++ mapping.</P><H2 CLASS="section"><A NAME="toc16"></A><A NAME="htoc41">3.1</A>  omniORB 2 BOA compatibility</H2><P>
<A NAME="sec:BOAcompat"></A></P><P>If you use the <TT>-WbBOA</TT> option to omniidl, it will generate
skeleton code with the same interface as the old omniORB 2 BOA
mapping, as well as code to be used with the POA. Note that since the
major problem with the BOA specification was that server code was not
portable between ORBs, it is unlikely that omniORB 4.1’s BOA
compatibility will help you much if you are moving from a different
BOA-based ORB.</P><P>The BOA compatibility permits the majority of BOA code to compile
without difficulty. However, there are a number of constructs which
relied on omniORB 2 implementation details which no longer work.</P><UL CLASS="itemize"><LI CLASS="li-itemize">omniORB 2 did not use distinct types for object references and
servants, and often accepted a pointer to a servant when the CORBA
specification says it should only accept an object reference. Such
code will not compile under omniORB 4.1.</LI><LI CLASS="li-itemize">The reverse is true for <TT>BOA::obj_is_ready()</TT>. It now only
works when passed a pointer to a servant object, not an object
reference. The more commonly used mechanism of calling
<TT>_obj_is_ready(boa)</TT> on the servant object still works as
expected.</LI><LI CLASS="li-itemize">It used to be the case that the skeleton class for interface
<TT>I</TT> (<TT>_sk_I</TT>) was derived from class <TT>I</TT>. This meant
that the names of any types declared in the interface were available
in the scope of the skeleton class. This is no longer true. If you
have an interface:<DIV CLASS="lstlisting"><B>interface</B> I {
<B>struct</B> S {
<B>long</B> a,b;
};
S op();
};</DIV><P>then where before the implementation code might have been:</P><DIV CLASS="lstlisting"><B>class</B> I_impl : <B>public</B> <B>virtual</B> _sk_I {
S op(); <I>// _sk_I is derived from I</I>
};
I::S I_impl::op() {
S ret;
<I>// ...</I>
}</DIV><P>it is now necessary to fully qualify all uses of <TT>S</TT>:</P><DIV CLASS="lstlisting"><B>class</B> I_impl : <B>public</B> <B>virtual</B> _sk_I {
I::S op(); <I>// _sk_I is not derived from I</I>
};
I::S I_impl::op() {
I::S ret;
<I>// ...</I>
}</DIV></LI><LI CLASS="li-itemize">The proprietary omniORB 2 LifeCycle extensions are no longer
supported. All of the facilities it offered can be implemented with
the POA interfaces, and the <TT>omniORB::LOCATION_FORWARD</TT>
exception (see section <A HREF="omniORB004.html#sec:locationForward">4.8</A>). Code which used the
old interfaces will have to be rewritten.</LI></UL><H2 CLASS="section"><A NAME="toc17"></A><A NAME="htoc42">3.2</A>  omniORB 3.0 compatibility</H2><P>omniORB 4.1 is almost completely source-code compatible with omniORB
3.0. There are two main cases where code may have to change. The first
is code that uses the omniORB API, some aspects of which have
changed. The omniORB configuration file also has a new format. See the
next chapter for details of the new API and configuration file.</P><P>The second case of code that may have to change is code using the
Dynamic Any interfaces. The standard changed quite significantly
between CORBA 2.2 and CORBA 2.3; omniORB 3.0 supported the old CORBA
2.2 interfaces; omniORB 4.1 uses the new mapping. The changes are
largely syntax changes, rather than semantic differences.</P><H2 CLASS="section"><A NAME="toc18"></A><A NAME="htoc43">3.3</A>  omniORB 4.0 compatibility</H2><P>omniORB 4.1 is source-code compatible with omniORB 4.0, with four
exceptions:</P><OL CLASS="enumerate" type=1><LI CLASS="li-enumerate">As required by the 1.1 version of the CORBA C++ mapping
specification, the <TT>RefCountServantBase</TT> class has been
deprecated, and the reference counting functionality moved into
<TT>ServantBase</TT>. For backwards compatibility,
<TT>RefCountServantBase</TT> still exists, but is now defined as an
empty struct. Most code will continue to work unchanged, but code
that explicitly calls <TT>RefCountServantBase::_add_ref()</TT> or
<TT>_remove_ref()</TT> will no longer compile.</LI><LI CLASS="li-enumerate">omniORB 4.0 had an option for Any extraction semantics that was
compatible with omniORB 2.7, where ownership of extracted values was
not maintained by the Any. That option is no longer available.</LI><LI CLASS="li-enumerate">The members of the <TT>clientSendRequest</TT> interceptor have
been changed, replacing all the separate variables with a single
member of type <TT>GIOP_C</TT>. All the values previously available
can be accessed through the <TT>GIOP_C</TT> instance.</LI><LI CLASS="li-enumerate">The C++ mapping contains Any insertion operators for sequence
types that are passed by pointer, which cause the Any to take
ownership of the inserted sequence. In omniORB 4.0 and earlier, the
sequence was immediately marshalled into the Any’s internal buffer,
and the sequence was deleted. In omniORB 4.1, the sequence pointer
is stored by the Any, and the sequence is deleted later when the Any
is destroyed.<P>For most uses, this change is not visible to application code.
However, if a sequence is constructed using an application-supplied
buffer with the release flag set to false (meaning that the
application continues to own the buffer), it is now important that
the buffer is not deleted or modified while the Any exists, since
the Any continues to refer to the buffer contents. This change
means that code that worked with omniORB 4.0 may now fail with 4.1,
with the Any seeing modified data or the process crashing due to
accessing deleted data. To avoid this situation, use the alternative
Any insertion operator using a const reference, which copies the
sequence.</P></LI></OL><HR>
<A HREF="omniORB002.html"><IMG SRC="previous_motif.gif" ALT="Previous"></A>
<A HREF="index.html"><IMG SRC="contents_motif.gif" ALT="Up"></A>
<A HREF="omniORB004.html"><IMG SRC="next_motif.gif" ALT="Next"></A>
</BODY>
</HTML>
|
