OK, I'll get something done along these lines and submit a patch,
hopefully by mid next week. My comments on your comments (so to speak)
are:
> First, this approach uses a linked list, where the current XMLDeleter
> model uses a RefVector. A linked list seems likely to be simple and
efficient,
> but maybe there's a compelling reason to use a vector that I'm unaware
of.
I don't see a compelling reason to use a vector over a linked list - can
anyone clarify?
> Second, I think that the XMLRegisterCleanup objects should be dynamic
rather than static.
> The XMLDeleter model makes sense to me: when you perform some
> initialization (presumably lazy initialization of global data), you
create
> and register the corresponding cleanup object. Terminate() then does the
> cleanup and deletes each cleanup object.
I agree with this, it will make the code neater. Presumably the reason
for the lazy initialisation is that the objects may never be used, in
which case you don't pay for them - so why pay for the cleanup object?
The disadvantage is the problem of what to do on lack of memory - you
never get this with static objects. It would be possible to mix the two,
which would be my preferred solution: you create a static object, which
contains a pointer to the next list object, and a pointer to your cleanup
function and then call something like XMLCleanup::RegisterCleanup()
manually for your object. This fixes up the "next" pointer for you, so
that your cleanup function will be called at Terminate() time. It neatly
sidesteps the need to allocate memory, and prevents you from paying for
the cost of that dynamic allocation. On the down side, you slightly
increase the size of the data segment, but since this is going to be by 2
pointers per potential cleanup, and I counted about 8 cleanups required,
then this isn't by very much.
> The main advantage to this is that
> you call only the required cleanup functions, which can assume that the
> corresponding initialization has occurred. Using the static list, all
> cleanup functions will always be called, even if the corresponding
> initialization never took place.
Yes, agreed.
> Furthermore, there may be construction
> order problems with the static list. The outlined code assumes that
> gXMLCleanupList is initialized to NULL somewhere before the
> XMLRegisterCleanup constructor is called for the first time. I'm not
sure
> you can guarantee this happens in the required order.
I believe that you can. The gXMLCleanupList object will be put in the BSS
data segment, i.e. it is initialised to NULL at program load time. The
process goes something like:
* Load application, including BSS & DATA segments. BSS is all initialised
to NULL, and DATA is pre-initialised (contains strings and such like).
* Call constructors of global objects
Now there is a construction order problem between modules, but we don't
have that since the list head pointer doesn't need an actual constructor
to initialise it.
Does this seem OK?
Mark
> -----Original Message-----
> From: Jesse Pelton [mailto:[EMAIL PROTECTED]]
> Sent: 21 September 2001 14:38
> To: '[EMAIL PROTECTED]'
> Subject: RE: using differnt instances of the parser causes ACCESS
> Violation
>
>
> I don't think anyone has contributed code to address the
> Initialize/Terminate/Initialize problem. Casey Schmit mentioned in
> http://marc.theaimsgroup.com/?l=xerces-c-dev&m=99990073514869&w=2 that
his
> company had implemented a fix for themselves, but I don't think it's
been
> contributed back to Xerces. I thought you (Mark) were headed in the
right
> direction (subject to my comments in
> http://marc.theaimsgroup.com/?l=xerces-c-dev&m=99987878404358&w=2), and
if
> you've got the resources, I'd encourage you to follow through
> with a robust
> solution that's part of the Xerces code base. At present, I think that
> various developers have implemented their own solutions, but I think it
> would be in everyone's interest to have code known to be robust
> and general
> built in.
>
> -jesse-
>
> -----Original Message-----
> From: Mark Weaver [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, September 20, 2001 8:42 PM
> To: [EMAIL PROTECTED]
> Subject: RE: using differnt instances of the parser causes ACCESS
> Violation
>
>
> I sent a mail about this a while ago. I've implemented a fix for
myself,
> but somebody said that they'd already fixed it - presumably this isn't
in
> the main source tree yet?
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
smime.p7s
