This is going to sound like somewhat of a rant, but its based on sound
rantworthy experiences...
This is a slippery slope that we don't want to go down. There is no way to
insure such things get done consistently if you use global objects.
Basically, global objects are considered extremely dangerous in C++ and we
don't support their use. Just patching up specific instances of problems as
you find them isn't a reasonable approach because everyone out there can do
something slightly different and cause some problem, either now or later in
the field when circumstances change slightly. And because there is no real
guaranteed order of initialization on some systems, no matter what you do,
you'll get screwed somewhere and somehow if you use globals.
If the premature calls are being caused by our code, tell us where it is
and we'll fix it. If its being caused by code you are writing, I would
suggest that you take a lazy evaluation approach, because that's the only
safe way to do it in the end. Good lazy evaluation technique is usually
easy and can be made relatively painless.
On such systems where there is some way to insure evaluation, the client
code can use a global object which he/she insures will construct first, and
that object can kick off the initialization. However, what happens if
something goes wrong with the initialization? Exceptions in global objects
just cause the program to fall over with no explanation of how or why it
did so. If the global kicker object catches the exception and uses some
user based error reporting system, what if its not been initialized yet?
And so on and so on. Its such a morass that even trying to explain it to a
user is not worth it. Its best to just say, don't use global objects or
lazy init them if you do.
Given my extensive talks with Andy H on this subject both in the context of
the XML code and back at Taligent, I'm sure that I speak for him here as
well.
----------------------------------------
Dean Roddey
Software Weenie
IBM Center for Java Technology - Silicon Valley
[EMAIL PROTECTED]
[EMAIL PROTECTED] on 01/11/2000 11:27:22 AM
Please respond to [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
cc:
Subject: xalan-c Problem with Xerces initialization
forwarded from the Xalan list.
-Rob
-----------------------------
Jack Donohue wrote:
When working with Xalan-c on Linux, I found that even if the
XMLPlatformUtils::Initialize() method is called directly from the main
program, there is still the possibility of making calls to getDOMConverter
when creating statically initialized variables, long before main starts
execution.
I managed to get around this by adding a call to
XMLPlatformUtils::Initialize() in the getDOMConverter method in
DOMString.cpp:
XMLLCPTranscoder* getDomConverter()
{
static XMLLCPTranscoder* gDomConverter = 0;
if (!gDomConverter)
{
// Make sure we've been initialized
XMLPlatformUtils::Initialize();
XMLLCPTranscoder* transcoder =
XMLPlatformUtils::fgTransService->makeNewLCPTranscoder();
if (!transcoder)
XMLPlatformUtils::panic(XMLPlatformUtils::Panic_NoDefTranscoder
);
if (XMLPlatformUtils::compareAndSwap((void **)&gDomConverter,
transcoder, 0) != 0)
delete gDomConverter;
}
return gDomConverter;
};
If the DOM converter has already been called, then this code will not be
executed again, and if the Initialize method had already been called, it
just returns, so this has minimal overhead. I'd like to suggest that this
patch be incorporated into Xerces.
Jack Donohue
