[Insight-users] Re: itkLightObject question

[Paul Richards]

>From my experience in Win32 using VC6 and up, I'm sure it's perfectly
legal to allocate memory in one module and free it in another.

(This may require that all code is compiled using the DLL version of
the C runtime instead of statically linking against it; but here we
compile all code using the DLL version of the CRT, so I don't know for
sure if statically linking the CRT would cause problems.)




On 02/08/07, Brad King <brad.king at kitware.com> wrote:
> Paul Richards wrote:
> > PS. I'm emailing you about this since the CVS blame tool points me to
> > you.  If you were not the original author of the code, do you know who
> > was?
>
> Questions like this should be sent to the mailing list anyway so that
> responses are stored for public record.  Anyway, this code was derived
> from earlier code in VTK.  The idea is that memory allocated by code
> running in one DLL cannot be freed by code running in another DLL, or at
> least this was true at one time.  Since the implementations of these
> methods are in the .cxx file they are always in the same DLL.  No matter
> who calls them the actual memory allocation and free is done by the same
> code in one DLL.
>
> FYI, I never investigated this and just took the word of the original
> author of the VTK code.  I do not know if it is necessary anymore.
>
> -Brad
>
> > On 02/08/07, Paul Richards <paul.richards at gmail.com> wrote:
> >> Hi,
> >> I note in itkLightObject.h there is a block of code to overload the
> >> new and delete operators:
> >>
> >> #ifdef _WIN32
> >>   /** Used to avoid dll boundary problems.  */
> >>   void* operator new(size_t);
> >>   void* operator new[](size_t);
> >>   void operator delete(void*);
> >>   void operator delete[](void*, size_t);
> >> #endif
> >>
> >> Can you explain what dll boundary problems exist without this code,
> >> and why this code fixes them?
> >>
> >>
> >> The implementation simply uses "new char[]", which AFAIK allocates the
> >> memory out of the same process wide heap no matter which module (DLL
> >> or EXE) calls it...  Perhaps I am wrong..
> >>
> >>
> >> --
> >> Paul Richards
> >>
> >
> >
>
>


-- 
Paul Richards