[omniORB] omniInitialRefLister
Ji-Yong D. Chung
virtualcyber@erols.com
Fri, 16 Jul 1999 00:00:43 -0400
This is a multi-part message in MIME format.
------=_NextPart_000_0004_01BECF1E.3F8A0150
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
>> .
>> If I remember correctly, static objects are supposed to be destroyed=20
>> in the reverse order=20
>> that the static objects were originally created.=20
>> (at least that is what is supposed to happen under ANSI C++ =
standard).=20
>>=20
>This is true only within each (singular) translation unit. There is no=20
>guarantee between translation units. If you have a singleton in another =
>translation unit that depends (directly or indirectly) on this you may=20
>be out of luck.=20
I suppose this is rather nitpicking, but the order of destruction
of objects must be the reverse of their construction, even =20
across multiple translation units. What is not guaranteed across
translation units is that the objects will be constructed in particular =
order.
=20
Now I think of it, since the construction order is not known across
multiple translation units, I suppose, the destruction order cannot be =
known=20
either -- so, in effect, you are right.
>> The point here is that if omniORB properly orchestrates the=20
>> static object creation, the destruction of those objects also should =
be=20
>> orderly=20
>> (in the "reverse" order). If the destruction is not done in the =
proper=20
>> order even=20
>> though the creation of those objects is orderly, then the problem may =
>> lie with the compiler/linker.=20
>=20
>Actually, I have often wondered about this. The advice I've most often=20
>seen is to prefer function scope static over file, class or namespace=20
>scope for singletons.=20
>I seem to recall that there was a comment in one of the .cc files in =
the=20
>omniORB2 library implementation that indicated that this approach =
(using=20
>function scope static for singletons) was found to be problematic on=20
>some platforms (it was a long time ago and I may be reading more into =
it=20
>than was intended). Is this correct?=20
How does function scope thing work? I have seen methods that =
basically
use global static pointer variables as a flag. If the pointer value is =
non-nil, one knows
that the initialization has been done, and so one can proceed on other =
object
creation that depends on the initialization. If it is nil, then, one =
must invoke=20
proper global method to initialize the object before trying to create =
other objects
that depends on the initialization.
>Bruce=20
------=_NextPart_000_0004_01BECF1E.3F8A0150
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>
<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type>
<META content=3D'"MSHTML 4.72.3110.7"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV> </DIV>
<DIV><FONT color=3D#000000=20
size=3D2>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D<BR>>>=20
.<BR>>> If I remember correctly, static objects are supposed to be =
destroyed <BR>>> in the reverse order <BR>>> that the static =
objects=20
were originally created. <BR>>> (at least that is what is supposed =
to=20
happen under ANSI C++ standard). <BR>>> </FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
<DIV><FONT color=3D#000000 size=3D2>>This is true only within each =
(singular)=20
translation unit. There is no <BR>>guarantee between translation =
units. If=20
you have a singleton in another <BR>>translation unit that depends =
(directly=20
or indirectly) on this you may <BR>>be out of luck. </FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>
<DIV><FONT color=3D#000000 size=3D2> <FONT =
color=3D#000000>I suppose=20
this is rather nitpicking, but the order of =
destruction</FONT></FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2><FONT =
color=3D#000000></FONT></FONT><FONT=20
size=3D2>of objects must be the reverse of their construction, =
even =20
</FONT></DIV>
<DIV><FONT size=3D2>across multiple translation units. What is not =
guaranteed across</FONT></DIV>
<DIV><FONT size=3D2>translation units is that the objects will be =
constructed in=20
particular order.</FONT></DIV>
<DIV><FONT size=3D2></FONT><FONT size=3D2></FONT> </DIV>
<DIV><FONT size=3D2> Now I think of it, since the =
construction=20
order is not known across</FONT></DIV>
<DIV><FONT size=3D2>multiple translation units, I suppose, </FONT><FONT =
size=3D2>the=20
destruction order cannot be known </FONT></DIV>
<DIV><FONT size=3D2>either -- so, in effect, you are </FONT><FONT=20
size=3D2>right.</FONT></DIV>
<DIV><FONT size=3D2></FONT> </DIV></DIV>
<DIV><FONT color=3D#000000 size=3D2>>> The point here is that if =
omniORB=20
properly orchestrates the <BR>>> static object creation, the =
destruction=20
of those objects also should be <BR>>> orderly <BR>>> (in =
the=20
"reverse" order). If the destruction is not done in the proper =
<BR>>> order even <BR>>> though the creation of those =
objects is=20
orderly, then the problem may <BR>>> lie with the compiler/linker. =
<BR>> </FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
<DIV><FONT color=3D#000000 size=3D2>>Actually, I have often wondered =
about this.=20
The advice I've most often <BR>>seen is to prefer function scope =
static over=20
file, class or namespace <BR>>scope for singletons. </FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
<DIV><FONT color=3D#000000 size=3D2>>I seem to recall that there was =
a comment in=20
one of the .cc files in the <BR>>omniORB2 library implementation that =
indicated that this approach (using <BR>>function scope static for=20
singletons) was found to be problematic on <BR>>some platforms (it =
was a long=20
time ago and I may be reading more into it <BR>>than was intended). =
Is this=20
correct? </FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT> </DIV>
<DIV><FONT color=3D#000000 size=3D2> How does function =
scope thing=20
work? I have seen methods that basically</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT><FONT size=3D2>use global =
static pointer=20
variables as a flag. If the pointer value is non-nil, one=20
knows</FONT></DIV>
<DIV><FONT size=3D2>that the initialization has been done, and so one =
can proceed=20
on other object</FONT></DIV>
<DIV><FONT size=3D2></FONT><FONT size=3D2>creation that depends on the=20
initialization. </FONT><FONT size=3D2>If it is nil, then, one must =
invoke=20
</FONT></DIV>
<DIV><FONT size=3D2>proper global method to initialize the object before =
trying to=20
create other objects</FONT></DIV>
<DIV><FONT size=3D2>that depends on the initialization.</FONT></DIV>
<DIV> </DIV>
<DIV><FONT color=3D#000000 size=3D2>>Bruce =
</FONT></DIV></BODY></HTML>
------=_NextPart_000_0004_01BECF1E.3F8A0150--