Như bạn đã thấy trong các khu vực khác của chương này, con trỏ có thể trình bày vấn đề cho cả hai nhà phát triển Visual Basic và C #. Tuy nhiên, đây là một trong những khu vực nơi các nhà phát triển C # có một lợi thế quyết định và bạn có thể thấy rằng nó tốt hơn để sử dụng C #, | Working with Pointers Working with Pointers As you ve already seen in other areas of this chapter pointers can present problems for both Visual Basic and C developers. However this is one area where C developers have a decided advantage and you might find that it s better to use C whenever you have a lot of pointers to work with. Even if Visual Basic is the main language for your application you can write a wrapper DLL in C to meet the requirements of the Win32 API call portion of the code. Generally anywhere you need to use a UInt value or an odd pointer you ll also need to use C . The IntPtr is the developer s best friend when it comes to pointers. However remember that an IntPtr contains a void not the specialized pointers that Win32 API calls rely on. As shown in Listing the use of a void normally means some type of data conversion later in the process. The whole concept of a void is to represent a pointer of an unknown type. In sum an IntPtr enables you to create generic pointers but not specific pointers. C developers also have access to standard C-like pointers. However to use this feature you must declare the affected method as unsafe. As discussed in the Understanding the Effects of Unsafe Code section of Chapter 1 you want to minimize unsafe code sections for a number of reasons. The most important reason is that unsafe code sections don t receive the same level of error checking that normal code sections do which means that your code is more likely to contain hidden and difficult to debug errors. Here are some general rules for using normal pointers. Use an IntPtr whenever possible. Keep sections with standard pointers small. Perform more error checking than normal. Include range checks of all data to ensure that it remains within limits. Isolate unsafe code sections from the main application whenever possible. Consider using Visual C for large numbers of pointers. Avoid using pointers by substituting managed alternatives. Working with Enumerations .
