There've been extensive discussions about this. I think the consensus is
that it doesn't make sense to add code to work around (and hide) a
programming error (however common) that surfaces on one of the many
supported platforms.
On the other hand, I'm not sure it makes any more sense for the long-term
subscribers to this list to have to deal with this question every day. (At
least it feels like every day.) So far, no effective solution to this
problem has been found, as evidenced by the ongoing posts. As far as I
recall at the moment, the following have been tried or suggested:
- A FAQ topic. People either don't read it, or don't understand it.
- Various changes to the method of allocating and deallocating memory. No
proposal has been accepted.
- Modify the transcode() documentation to discuss the problem. Again, this
hasn't been implemented, on the basis that the problem is platform-specific.
I think we need to find some way to address this problem. I fear that the
quantity of posts on this subject may qualify as annoying noise for some
subscribers, causing them to unsubscribe, resulting in a smaller pool of
people to help out. At the moment, I'm inclined to prefer the approach Sean
proposes, not because I find it especially appealing, but because it seems
most likely to solve the problem of static on the list with a minimum of
effort.
-----Original Message-----
From: Earthlink Mail [mailto:[EMAIL PROTECTED]]
Sent: Friday, April 20, 2001 1:13 PM
To: [EMAIL PROTECTED]
Subject: Re: Deleting char* returned from DOMString.transcode() in VC++6. 0
It seems as though the cleaner way to solve this problem is to provide a
function from within the .DLL which de-allocates the memory allocated by the
.DLL. This gets rid of compiler run-time errors such as threading,
debugging, statically dynamically built libraries, etc.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
