[omniORB] "// some compilers get upset" in objectRef.cc

[Bruce Visscher]

Mikhail Soukhanov wrote:

> Hello!
>
> I have found the following comment at the end of objectRef.cc file:
>
> class ProxyObjectTableCleaner {
> public: // some compilers get upset     <<<
>   ~ProxyObjectTableCleaner();
>   static ProxyObjectTableCleaner theInstance;
> };
> ProxyObjectTableCleaner ProxyObjectTableCleaner::theInstance;
>
> Borland C++Builder certainly *do* get upset by hanging when compiling
> this source.
>
> The place is not clear to me. Why the instance inside its class? Is the
> following construct equivalent to the above as a workaround:
>
> class ProxyObjectTableCleaner {
> public: // some compilers get upset
>   ~ProxyObjectTableCleaner();
> };
> static ProxyObjectTableCleaner theInstance;
>

That might work on some platforms.  Be aware, though that a smart compiler
could optimize the instance away as you've declared it since it's probably
not really "used" anywhere.  If you do this, you should #ifdef it for
Borland (and make sure the destructor really runs).

My take is that the comment (and this is really a WAG) is referring to the
public access specifier.  Logically, if you're only creating a single
instance declared within the class that just performs some cleanup, you
wouldn't need the destructor to be public.  But, some compilers (Microsoft,
I think) get upset about declaring a class with a private destructor even
though the one and only static instance is declared within class scope.
I'm pretty sure these compilers are wrong.

Another WAG is that Borland is going into recursion because of the static
member (BTW, what BCB version is it?  I hope not BCB 4.  I was hoping
Borland was getting better.).  I could understand this if it were a
non-static member (which of course is not allowed).

Bruce