[omniORB] A bug in MSVC++ 6 SP5 and a possible workaround

[Vladimir Panov]

Hi.
MSVC++ 6 SP5 has a code generation bug, which affects code generated
from omniidl. I'll first describe the bug in a simple situation.
Consider the following code example:

#include <iostream>
using namespace std;

namespace A
{
  class ClassA
  {
  public:
    virtual void f(void)
    {
      cerr << "::A::ClassA::f" << endl;
    }
  };
}

namespace B
{
  typedef ::A::ClassA A_ClassA;
  class ClassA : public virtual A_ClassA
  {
  public:
    virtual void f(void)
    {
      A_ClassA::f();
      cerr << "::B::ClassB::f" << endl;
    }
  };
}

int main(int argc, char* argv[])
{
  ::A::ClassA *b = new ::B::ClassA;
  b->f();
  return 0;
}

This should output:
::A::ClassA::f
::B::ClassB::f
and then quit. But it generates a stack overflow, since ::B::ClassB::f
does not call ::A::ClassB::f, but itself.
This bug can be worked around this way:

namespace A
{
  class ClassA
  {
  public:
    virtual void f(void)
    {
      cerr << "::A::ClassA::f" << endl;
    }
  };
}

namespace B
{
  class A_ClassA : public virtual ::A::ClassA
  {
  };
  class ClassA : public virtual A_ClassA
  {
  public:
    virtual void f(void)
    {
      A_ClassA::f();
      cerr << "::B::ClassB::f" << endl;
    }
  };
}


Consider the following IDL example:

module A
{
  interface ClassA
  {
    void f();
  };
};

module B
{
  interface ClassA : A::ClassA
  {
  };
};

The bug first shows itself here:
CORBA::Boolean B::_impl_ClassA::_dispatch(GIOP_S& giop_s);

I suggest changing these typedef's:

typedef A::ClassA _A_ClassA;
typedef A::_impl_ClassA _A__impl_ClassA;
typedef A::_objref_ClassA _A__objref_ClassA;

to:

class _A_ClassA : public virtual A::ClassA
{
};
class _A__impl_ClassA : public virtual A::_impl_ClassA
{
};
class _A__objref_ClassA : public virtual A::_objref_ClassA
{
};

and, of course, moving them to the header.

I tried to do this myself, but I got stuck with Python (never seen it
before). If you feel this patch is needed, please, make it.
Many, many 10x :-)

Gbr


P.S. This problem gave me the idea of porting omniORB's makefiles to the
free (of charge) Borland C++ 5.5 coimpiler. Well, it ain't easy :-) The
makefiles are too MSVC specific. If I succeed to do this some day, I'll
send you the patches. Meanwhile, I'm using Intel's C++ compiler (plugged
into MSVC IDE) to build my project for Win32.