Re: core dump on DOMString initialization

[Irving Reid <ir...@nevex.com>]

I had the same core dump in one of my early tries at using Xerces-C, 
and it was because I didn't call XMLPlatformUtils::Initialize() before 
creating the DOMString.

You can't do anything with strings until you initialize the library. 
One of the things that XMLPlatformUtils::Initialize() does is set up 
the default transcoding.

 - irving -

>      How do I know what is the transcoding setup on my system? I am not
>  compiling with any other libraries apart from xerces.
>  
>  TIA,
>  Sudheer

 - irving -

Re: core dump on DOMString initialization

[Dean Roddey <dr...@charmedquark.com>]

We could not guarantee that this would construct before your objects
construct. There is no way around this problem, because C++ does not
guarantee the order of construction. If you linked it in statically, it
would get even worse. Basically, global objects are evil and should be
avoided always. You should fault in your static/global data or you will get
into lots of trouble. IT becomes quite difficult over time to keep up with
the possible ways that one global object might use another global object,
and to insure that they construct correctly.

One thing you can do is to put all of those objects inside a singleton
global object of your own. Make a simple class that will do the XML init,
and put it first in the list of members. C++ will always construct members
of a class in the order that they are declared in the header, so you can
globally construct your own object (which does nothing but insure that
others are constructed) and that will insure that the member objects (which
are not static!!) will construct in the right order and by putting the init
object first, it will insure that our stuff gets constructed first.

However, this has its problems as well, because if something goes wrong,
there is nothing there to catch the exception. Better still is to have the
global object do nothing but construct. Have getter methods which provide
access to the other objects, and which lazily fault them in (and insure our
stuff is initialized as well) upon access to them. So the global object just
has a set of pointer members which it initializes to zero. When one of the
getter methods is called, it checks to see if the pointer is still zero. If
so, it creates the object at that point and returns a reference. It uses a
flag to remember if its initialized the XML parser yet, and does that first
if its not already done.

Anyway, this is C++ related stuff, not XML related stuff, so I'll leave it
at that. There are lots of books which cover these issues.

--------------------------
Dean Roddey
The CIDLib Class Libraries
Charmed Quark Software
droddey@charmedquark.com
http://www.charmedquark.com

"Give me immortality, or give me death"

----- Original Message -----
From: "Sudheer Tumuluru" <st...@real.com>
To: "Irving Reid" <ir...@nevex.com>
Cc: <xe...@xml.apache.org>
Sent: Sunday, May 14, 2000 8:51 PM
Subject: Re: core dump on DOMString initialization


>         I think that's exactly the problem. I had a bunch of "const static
> DOMString" variables and I was initializing them and that gave the error.
> The problem here is that the before the execution can get to
> XMLPlatformUtils::Initialize(), it executes the initialization of the
"const
> static" variables. I guess I cannot declare DOMStrings that way then.
>
>         I will circumvent this by declaring them non-constant or
something.
> But probably there should be provision in the library for automatic
> initialization. How about declaring an obscure int variable "const static"
> and initialize it with the return value of XMLPlatformUtils::Initialize().
> This should solve the problem.
>
> -Sudheer
>
> Irving Reid wrote:
>
> > I had the same core dump in one of my early tries at using Xerces-C,
> > and it was because I didn't call XMLPlatformUtils::Initialize() before
> > creating the DOMString.
> >
> > You can't do anything with strings until you initialize the library.
> > One of the things that XMLPlatformUtils::Initialize() does is set up
> > the default transcoding.
> >
> >  - irving -
> >
> > >      How do I know what is the transcoding setup on my system? I am
not
> > >  compiling with any other libraries apart from xerces.
> > >
> > >  TIA,
> > >  Sudheer
> >
> >  - irving -
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: xerces-c-dev-help@xml.apache.org
>

Re: core dump on DOMString initialization

[Sudheer Tumuluru <st...@real.com>]

        I think that's exactly the problem. I had a bunch of "const static
DOMString" variables and I was initializing them and that gave the error.
The problem here is that the before the execution can get to
XMLPlatformUtils::Initialize(), it executes the initialization of the "const
static" variables. I guess I cannot declare DOMStrings that way then.

        I will circumvent this by declaring them non-constant or something.
But probably there should be provision in the library for automatic
initialization. How about declaring an obscure int variable "const static"
and initialize it with the return value of XMLPlatformUtils::Initialize().
This should solve the problem.

-Sudheer

Irving Reid wrote:

> I had the same core dump in one of my early tries at using Xerces-C,
> and it was because I didn't call XMLPlatformUtils::Initialize() before
> creating the DOMString.
>
> You can't do anything with strings until you initialize the library.
> One of the things that XMLPlatformUtils::Initialize() does is set up
> the default transcoding.
>
>  - irving -
>
> >      How do I know what is the transcoding setup on my system? I am not
> >  compiling with any other libraries apart from xerces.
> >
> >  TIA,
> >  Sudheer
>
>  - irving -