Addison essential C# 4.0 Visual Studio_10

Tham khảo tài liệu addison essential c# 4.0 visual studio_10, công nghệ thông tin, kỹ thuật lập trình phục vụ nhu cầu học tập, nghiên cứu và làm việc hiệu quả
Nội dung trích xuất từ tài liệu:
Addison essential C# 4.0 Visual Studio_10 835 P ointers and AddressesIf the data is an unmanaged variable type but is not fixed, then use thefixed statement to fix a moveable variable.Fixing DataTo retrieve the address of a moveable data item, it is necessary to fix, orpin, the data, as demonstrated in Listing 20.14.Listing 20.14: Fixed Statement byte[] bytes = new byte[24]; fixed (byte* pData = &bytes[0]) // pData = bytes also allowed { // ... } Within the code block of a fixed statement, the assigned data will notmove. In this example, bytes will remain at the same address, at least untilthe end of the fixed statement. The fixed statement requires the declaration of the pointer variablewithin its scope. This avoids accessing the variable outside the fixed state-ment, when the data is no longer fixed. However, it is the programmer’sresponsibility to ensure that he doesn’t assign the pointer to another vari-able that survives beyond the scope of the fixed statement—possibly in anAPI call, for example. Similarly, using ref or out parameters will be prob-lematic for data that will not survive beyond the method call. Since a string is an invalid referent type, it would appear invalid todefine pointers to strings. However, as in C++, internally a string is apointer to the first character of an array of characters, and it is possible todeclare pointers to characters using char*. Therefore, C# allows declar-ing a pointer of type char* and assigning it to a string within a fixedstatement. The fixed statement prevents the movement of the string dur -ing the life of the pointer. Similarly, it allows any moveable type that sup -ports an implicit conversion to a pointer of another type, given a fixedstatement. You can replace the verbose assignment of &bytes[0] with the abbrevi-ated bytes, as shown in Listing 20.15. From the Library of Wow! eBook836 C hapter 20: Platform Interoperability and Unsafe Code Listing 20.15: Fixed Statement without Address or Array Indexer byte[] bytes = new byte[24]; fixed (byte* pData = bytes) { // ... } Depending on the frequency and time to execute, fixed statements have the potential to cause fragmentation in the heap because the garbage col- lector cannot compact fixed objects. To reduce this problem, the best practice is to pin blocks early in the execution and to pin fewer large blocks rather than many small blocks. Unfortunately, this has to be tempered with pinning as little as possible for as short a time as possible, to minimize the chance that a collection will happen during the time that the data is pinned. To some extent, .NET 2.0 reduces the problem, due to some addi- tional fragmentation-aware code. Allocating on the Stack You should use the fixed statement on an array to prevent the garbage col- lector from moving the data. However, an alternative is to allocate the array on the call stack. Stack allocated data is not subject to garbage collec- tion or to the finalizer patterns that accompany it. Like referent types, the requirement is that the stackalloc data is an array of unmanaged types. For example, instead of allocating an array of bytes on the heap, you can place it onto the call stack, as shown in Listing 20.16. Listing 20.16: Allocating Data on the Call Stack byte* bytes = stackalloc byte[42];} Because the data type is an array of unmanaged types, it is possible for the runtime to allocate a fixed buffer size for the array and then to restore that buffer once the pointer goes out of scope. Specifically, it allocates sizeof(T) * E, where E is the array size and T is the referent type. Given the requirement of using stackalloc only on an array of unmanaged types, the runtime restores the buffer back to the system simply by unwinding the stack, eliminating the complexities of iterating over the f-reachable queue (see Garbage Collection and Finalization in Chapter 9) and compacting reachable data. Therefore, there is no way to explicitly free stackalloc data. From the Library of Wow! eBook 837 P ointers and Addresses Note that the stack is a precious resource and, although small, running outof stack space will result in a program crashing; every effort should be takento avoid running out. If a program does run out of stack space, the b ...