MSDN Magazine - January 2008 - (Page 22)

As previously discussed, only reference types have two levels of indirection when passing by reference (there are a few exceptions, however, such as “[MarshalAs(UnmanagedType.LPStruct)]ref Guid”), so only the pointer or reference to a reference type can be changed, as shown in Figure 8. You don’t need to worry about memory ownership for an inplace change because the caller has allocated memory for the callee and the caller owns the memory. Let’s take “[OutAttribute] StringBuilder” as an example here. The corresponding native type is char * (assuming ANSI), since we are not passing by reference. Data is marshaled out, not in. Memory is allocated by the caller (in this case the CLR). The size of the memory is determined by the capacity of the StringBuilder object. The callee doesn’t need to concern itself with the memory. To change the string, the callee will make the change directly to the memory itself. However, when making a reference change, it is critical to recognize who owns which memory, otherwise any number of unexpected outcomes can occur. Regarding ownership issues, the CLR follows COM-style conventions: •Memory passed as [in] is owned by the caller and should be both allocated by the caller and freed by the caller. The callee should not try to free or modify that memory. •Memory allocated by the callee and passed as [out] or returned is owned by the caller and should be freed by the caller. •The callee can free memory passed as [in, out] from the caller, allocate new memory for it, and overwrite the old pointer value, thereby passing it out. The new memory is owned by the caller. This requires two levels of indirection, such as char In the interop world, caller/callee becomes CLR/native code. The rules above imply that in the unpinned case, if when in native code you receive a pointer to a block of memory passed to you as [out] from the CLR, you need to free it. On the other hand, if the CLR receives a pointer that is passed as [out] from native code, the CLR needs to free it. Clearly, in the first case, native code needs to do the de-allocation and in the second case, managed code needs to do de-allocation. Since this involves memory allocation and de-allocation, the biggest problem is what function to use. There are many to choose from: HeapAlloc/HeapFree, malloc/free, new/delete, and so on. However, since the CLR uses CoTaskMemAlloc/CoTaskMemFree in the non-BSTR case and SysStringAlloc/SysStringAllocByteLen/ SysStringFree in the BSTR case, you’ll have to use those functions. Otherwise, it is likely that you’ll get a memory leak or a crash in certain versions of Windows®. We have seen cases where malloc’d memory was passed to the CLR and the program didn’t crash in Windows XP but did crash in Windows Vista®. Besides those functions, a system-implemented IMalloc interface returned from CoGetMalloc also works fine because internally they are using the same heap. However, it is best to always stick with CoTaskMemAlloc/CoTaskMemFree and SysStringAlloc/ 22 msdnmagazine CLR Inside Out http://msdn.primalscript.com http://msdn.primalscript.com

Table of Contents Feed for the Digital Edition of MSDN Magazine - January 2008

MSDN Magazine - January 2008 Contents Toolbox CLR Inside Out Data Points Advanced Basics Cutting Edge IIS 7.0 - Enhance Your Apps with the Integrated ASP.NET Pipeline World Ready - Around the World with ASP.NET AJAX Applications WCF Syndication - HTTP Programming with WCF and the .NET Framework 3.5 Wicked Code Foundations Extreme ASP.NET {End Bracket}

MSDN Magazine - January 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.