Re: [libxml++] MS Visual 2005 - Return object across DLL boundary? (Was: Another issue)



After looking at the code, it seems to me the fix is to have libxml++ 
specify an allocator object when constructing all container-based 
objects that are returned to the calling code. Not sure how that would 
need to be implemented but that would enable the vector to maintain info 
on how to deallocate its internal data.

Eric


Eric Beyeler wrote on 10/9/2006, 11:53 AM:

 > Is there are known workaround, or proposed fix?
 >
 > Thanks,
 > Eric
 >
 > ----Original Message----
 >   On Wed, 2006-07-19 at 13:34 -0400, Robert S. Grimes wrote:
 >   [snip]
 >   > This seems to say the object was created on another heap (libxml++
 > DLL's
 >   > heap?) and being deleted by my code (using the main heap?).  It
 > seems the
 >   > "return value optimization" has been applied, and it perhaps
 > shouldn't have
 >   > been.  Does this make any sense?  If so, what do I do about it?
 > Or am I
 >   > missing something even more obvious?
 >
 >   This looks the annoying MSVC++ requirement that memory is
 > deallocated in
 >   the same library (DLL) in which it was allocated. So, if a library
 > gives
 >   you a newly allocated object, you can't delete it yourself. You have to
 >   tell the library to delete it.  libsigc++ used to have this same
 >   problem.
 >
 >   You can usually fix this by making sure that, though the deletion is
 >   initiated in the caller, the actual deletion happens in some
 > function in
 >   the library. Which would require a patch.
 >






[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]