[omniORB] using namespace

[Sai-Lai Lo]

Thanks for the clarification. It wasn't clear to me that you are changing 
omniORB 2.5 to use namespace.

Thanks to Steven Brenneis and Bruce Visscher, this has been done. I've got
their patch and was doing the merge early this week before I got
side-tracked by the egcs bug.

If you hold your guns for a few days, I can release a snapshot next week to
provide proper namespace support.

Sai-Lai



>>>>> Dietmar May writes:

>>> 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.


> 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?