I don't see it as a programming error at all. In my opinion, a .DLL should
be a "black box" for all intents and purposes. The memory that the .DLL
allocates, it should be able to free, and you should call a .DLL provided
function to free that memory. After all, who's to say that the allocation
occurred with a new() or a malloc()? Who's to say that the .DLL didn't use
it's own kind of sub-allocation scheme? Even though this isn't the case
here, what happens if the .DLL were a C Dll and were written in one
compiler, and the application program were written using another compiler?
I believe there should be a wall between the Application and the .DLL.
BTW, I agree with you on the bandwidth issue, and this will be the last post
I'll make on the subject. If anyone responds to me, I'll e-mail them
directly.
May the force be with you all.
----- Original Message -----
From: "Jesse Pelton" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, April 20, 2001 12:41 PM
Subject: RE: Deleting char* returned from DOMString.transcode() in VC++ 6. 0
> 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.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
