[omniORB] Date: Wed, 25 Mar 1998 10:11:19 -0500

Dietmar May dcmay@object-workshops.com
Wed, 25 Mar 1998 13:31:09 -0500


Hi Fredrik,

>> I am having problems with omniORB 2.5 and "const" declarations.
>>
>> Unfortunately, since the header file declares these as !!! static !!!,
>> zero'd value constants are being inserted into each source file! and
>> there is no way to resolve the global const definition. This means that
>> code which uses these constants does not, of course, do what is expected.
>>
>> Suggestions? About where to look, where to patch the IDL generator?

>Which compiler are you using? Static const members can be
>initialized during declaration in the header, but, if not there has
>to be an initialization statement in one source file.

>My best bet, get a patch for your compiler :)

I see the problem. No,it's not a compiler bug. (By the way, I am using MSVC
5.0 on NT).

I have done a port from Orbix to omniORB. Orbix (and I believe CORBA in
general) allows a module to be closed and re-opened, so that it is possible
to have:

module X
{
  interface A;
  interface B;
};

module X
{
  interface C;
};

This maps cleanly in Orbix (and in the OMG CORBA spec, ch. 16) to:

namespace X
{
  class A;
  class B;
};

namespace X
{
  class C;
};

and since a namespace can be closed and re-opened, there is no problem.

However, in omniORB, this maps to:

class X
{
  class A;
  class B;
};

class X
{
  class C;
};

which is, of course, an error.

To circumvent this, I have created the following macros:

#if defined(OMNI_ORB)
 #undef  _CORBA_MODULE
 #define _CORBA_MODULE  namespace
 #undef  _CORBA_MODULE_PUBLIC
 #define _CORBA_MODULE_PUBLIC
 #define friend
#endif

defined before including the omniORB generated header, which (after
preprocessing) yields compilable code similar to Orbix. However, now static
const members of a class are no longer in a class: they are in a namespace;
and hence, must be initialized within the header or cannot be static.

The natural question is, why split the IDL into separate module
declarations? In brief, the answer is compile time. By carefully segmenting
forward declarations, exceptions, and a few common structures into a single
module, and then putting the bulk of the other interfaces and structures
into other modules, we can take a 55 minute per file compile time and cut it
down to 3 minutes (200 MHz Pentium Pro, 128 MB RAM). Given 30 or so C++
files, without this and some other related code, it would literally take
over a day to compile and link our product once. (In terms of compile time,
given the complexity of our IDL interfaces, compiling files generated by
Orbix is pretty bad - over 30 minutes per file - but on large files,
compiling files generated by omniORB is even worse - almost twice as slow!
omniORB files do compile faster on small files, though).

Using the class mechanism as generated by omniORB is not acceptable for our
implementation; and changing the _CORBA_MODULE to a namespace does not (as
yet) seem to have any other undesirable side effects. So, it looks like the
only "cross-compatible" option is to:

use a #define name like _STATIC_CONST when declaring the IDL const value in
the C++ file. Then, when using #define _CORBA_MODULE class (the standard
omniORB setting), the corresponding definition would be #define
_STATIC_CONST static const. Conversely, when using #define _CORBA_MODULE
namespace (the CORBA preferred setting), the corresponding definition would
be #define _STATIC_CONST extern const.

This still requires some changes to the IDL compiler, and at this point, I'm
not sure where to look in the source.

Any ideas?

Regards,
Dietmar