- ...[#corba2spec##1#]
- Most of the 2.3 features have been
implemented. The features still missing in this release is listed
in 1.1.4. Where possible, backward compatibility has been
maintained up to specification 2.0.
- ...1999
- More information can be found at
http://www.opengroup.org/press/7jun99_b.htm
- ...code
- The stub code
is the C++ code that provides the object mapping as defined in the CORBA 2.0
specification.
- ...defined
- In omniORB2, all object
reference variable types are instantiated from the template type
_CORBA_ObjRef_Var.
- ...castings
- However, the implementation of the type conversion operator()
between Echo_var and Echo_ptr varies slightly among different C++
compilers, you may need to do an explicit casting when the compiler
complains about the conversion being ambiguous.
- ...Adaptor
- The interface of a BOA is described in chapter 8 of the
CORBA specification.
- ...)
- A conversion operator() of CORBA::String_var converts a
CORBA::String_var to a char*.
- ...string
- Please refer to the CORBA
specification 16.7 for the details of the String_var mapping. Other T_var
types are also covered in chapter 16.
- ...argument
- The 1st argument is a pointer to the
implementation definition and is always ignored by omniORB2.
- ...argument
- The CORBA specification does not specify
when impl_is_ready should return. Many ORB vendors choose to
implement impl_is_ready as blocking until a certain time-out value
is exceeded. In a single threaded implementation this is necessary to give
the ORB the time to serve incoming requests.
- ...reference
- Object references held by clients in other address
spaces will not prevent the object implementation from being disposed
of. If these clients invoke on the object after it is disposed, the system
exception INV_OBJREF is raised.
- ...space
- Notice that the
object key is not globally unique across address spaces.
- ...condition
- If a system
exception is not caught, the C++ runtime will call the terminate
function. This function is defaulted to abort the whole process and on some
system will cause a core file to be produced.
- ...RTTI
- Run Time
Type Identification
- ...RTTI
- A noticeable exception is the GNU C++
compiler (version 2.7.2). It doesn't support RTTI unless the
compilation flag -frtti is specified. The omniORB2 runtime is not compiled
with the -frtti flag. It is said that RTTI will be properly supported in
the upcoming version 2.8.
- ...Echo''
- A pathname, or in the Naming Service's
terminology- a compound name, is a sequence of textual names. Each
name component except the last one is bound to a naming context. A naming
context is analogous to a directory in a filing system, it can contain
names of object references or other naming contexts. The last name
component is bound to an object reference. Note: '/' is purely a notation
to separate two components in the pathname. It does not appear in the
compound name that is registered with the Naming Service.
- ...``omniORB''
- omniORB is a class name if the
C++ compiler does not support the namespace keyword.
- ...interface
- This interface is
first defined by Sun's NEO and is in used in Sun's JavaIDL
- ...Format
- For further details
of the repository ID formats, see section 6.6 in the CORBA
specification.
- ...purpose
- In pre-omniORB 2.8.0 releases, omniORB2 performs an
equality test and will ignore any alias TypeCodes ( tk_alias) when
making this comparison. The semantics is similar to the equivalent() test
in the TypeCode interface of CORBA 2.3.
- ...reference
- Testing a nil DynAny object with CORBA::is_nil()
returns TRUE(1). The CORBA 2.2 specification does not specify what is the
return value of this function when the current component pointer is
invalid. To ensure portability, it is best to avoid calling
current_component() under this condition.
- ...exception
- The CORBA 2.2
specification does not define the behavior of this error condition. To
ensure portability, it is best to avoid calling the get operations when the
current component pointer is known to be invalid.
- ...exception
- The
CORBA 2.2 specification does not define the behavior of this error
condition. To ensure portability, it is best to avoid calling the insert
operations when the current component pointer is known to be invalid.
- ...union
- In the CORBA 2.2 specification, the
DynFixed interface is defined to handle the fixed data type. This is not
supported in this implementation.
- ...usage
- This interface is
currently an open issue with the ORB revision task force.
- ...CORBA::release()
- if not managed by a _var type.
- ...CORBA::NVList
- obtained by calling
CORBA::ORB::create_list()
Sai Lai Lo
Wed Sep 22 19:28:07 BST 1999