[omniORB] Structs in omniorb

[Steven W. Brenneis]

andrew.brown@bt.com wrote:
> 
> Hi,
> 
> If anyone has experience of using structs with omniorb could you please see
> if you can answer the following questions :
> 
> 1) What are the pros and cons and implications of having the struct
> definition inside the interface
> definition as opposed to outside it?

The main impact in placement of the IDL definition of a struct within or
without an interface is scoping in the implementation.  This also
depends on whether you make your interface and struct definitions inside
a module.  With a struct nested in an interface which is defined in a
module, scoping can be somewhat cumbersome.  However, defining structs
with identical names within different interfaces, especially interfaces
with common inheritances can provide useful opportunities for
templatization and simpler class hierarchies in the C++ implementation.

> 
> 2) What are the pros and cons of using the "any" type for return values
> and parameters?
> 

My experience with Any is that it can be very useful in keeping the
interface separated from the implementation.  It is a far more
satisfying solution than discriminated unions.  Any's can carry a
sizeable amout of overhead, however.  Remember that a schema of the
Any's content has to be serialized with the data.  If your application
uses large data structures with a number of variants, this overhead can
become somewhat prohibitive.

> 3) How can we be more specific on the valid struct(s) that an "any"
> definition can take in?
> 

Limiting the types an Any can receive sort of defeats the purpose of the
Any.  The contained types are managed by the Any and it is unecessary to
perform application-level management.  Futhermore, the most useful
aspect of the Any is the elimination of the need to define particular
use types in the interface.

> 4) If we have the struct definition outside the interface, can we simply
> provide that in a separate
> IDL?
> 

The simple answer is yes.  If you look back in the archives, there is a
discussion of IDL #include'd definitions.  One of my applications
involves about 20 IDL's.  Many of these are nothing more than struct
definitions.  Your build system will need to be smart enough to handle
dependencies for the IDL compiler well when you use this method.  I
usually try to keep struct definitions inside modules to prevent global
namespace pollution problems.

> Thanks for any information supplied.
> 
> Andy Brown.

You're welcome!