[omniORB] MSVC 6.0
David Riddoch
djr@uk.research.att.com
Wed, 22 Sep 1999 12:52:12 +0100 (GMT)
On Wed, 22 Sep 1999, Renzo Tomaselli wrote:
> Hi all,
> I wonder if anybody tried to port OmniORB2 *applications* from
> MSVC 5.0 to 6.0; all messages on this list refer almost to 5.0. Well, I
> tried with a few bad surprises. I wrote a number of dlls based on
> OmniORB 2.6 and MSVC 5.0; they used to run fine for almost one year. Now
> I moved all to 2.71 and MSVC 6.0. A simple code line such as:
>
> static const CORBA::TypeCode_ptr Tp = Foo::_tc_Block;
>
> doesn't work anymore, it compiles ok but the run fails. OmniORB is ok
> here, but it seems MSVC changed initialization order so Tp is always
> null, while it was ok with 5.0. It appears that the _tc_Block
> constructor in fooDynSK.cpp is called *after* Tp is initialized. This
> trouble occurs only across namespaces when different files are involved
> (actually, my foo_i.cpp and fooDynSK.cpp; if the overall code sequence
> is put into the same source file, it works fine).
You should never rely on the order of static initialisation -- compilers
are free to do it in any order they like. In fact, you shouldn't even
rely on those TypeCode constants be initialised at all until after you
have called ORB_init().
> A workaround might be replacing the line through "const
> CORBA::TypeCode_ptr & Tp = Foo::_tc_Block;" .
Yes, this will work. Note that you should not use 'Tp' until after you
have called ORB_init(). It is quite likely that in a future version of
omniORB we will not be initialising these constants until ORB_init() is
called. They will probably also be cleaned up when ORB::shutdown() is
called.
> Then a minor point in CORBA_sysdep.h: the test for const data member
> initialization (_init_in_cldecl_ etc.) fails since _MSC_VER now is 1200
> and nothing changed from 5.0 about this concern. This affects stubs from
> idls containing interfaces with embedded constants; they don't compile
> anymore with 6.0.
This has been fixed in the latest version. See:
http://www.uk.research.att.com/omniORB/bugs/54.html
for more info and a patch.
Cheers,
David