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

[<loi...@re...>]

> Is there are known workaround, or proposed fix?
>=20
> Thanks,
> Eric

Have you read my previous message on the subject ? I use libxml++ with =
several DLL on VC++2005, and have not encountered any problems.


To my understanding, there is another way to acheive this :

If you select the Multi-threaded DLL (/MD) options, all =
allocations/deallocations, either from the main program or from the DLL =
are delegated to yet another DLL (MSVCR80.DLL) (which must then  be =
delivered with the program), and thus happen in a unique place.

Of course, the main program and all its DLL should be compile with the =
same option.

--
Lo=EFc


>=20
> ----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=20
> (libxml++ DLL's
>   > heap?) and being deleted by my code (using the main=20
> heap?).  It seems the
>   > "return value optimization" has been applied, and it=20
> perhaps shouldn't have
>   > been.  Does this make any sense?  If so, what do I do=20
> about it?  Or am I
>   > missing something even more obvious?
>=20
>   This looks the annoying MSVC++ requirement that memory is=20
> deallocated in
>   the same library (DLL) in which it was allocated. So, if a=20
> library gives
>   you a newly allocated object, you can't delete it yourself.=20
> You have to
>   tell the library to delete it.  libsigc++ used to have this same
>   problem.
>=20
>   You can usually fix this by making sure that, though the deletion is
>   initiated in the caller, the actual deletion happens in=20
> some function in
>   the library. Which would require a patch.
>=20
>=20