重新认识C#: 玩转指针
许多文章并不鼓励在C#下使用指针开发，不过，本文偏偏要这样做。在大量尝试C#下使用指针开发之后，你会对C#有更深的认识。
在说C#下的指针之前，需要提一下C++/CLI。C++/CLI 我们可以把它看作两部分：Native C++和 Managed C++，两者可以无缝结合。对C#，我们也可以把它看作两部分：Managed C# 和 Unmanaged C#。Managed C# 和 Unmanaged C# 是我杜撰的两个词，前者就是我们通常的C#，后者就是使用指针、Struct和非托管内存的C#。事实证明，Unmanaged C#也可以玩的十分优雅——它具有C语言的大部分特性，却比C语言好用的多。 C# 与 C++/CLI之间的对应关系见下图：
C++/CLI默认是 Native C++，而C# 默认是 Managed C# 。除了不能内嵌汇编以及编译方式不同之外，C++/CLI和C#两者在层面上几乎是等价的。其中，C++/CLI略微偏底层一点，C#略微偏高层一点。尽管略微偏高层一点，C#仍然可以当成准系统语言来玩。你可以将Unmanaged C# 当作 mini c 来玩，区别只是，C 语言一般是编译执行的，而 Unmanaged C# 是先编译成 IL ，再使用Ngen编译成机器码或在运行时编译成机器码执行。
在C#下不鼓励使用指针，这是因为C#的定位是应用级的开发，如果我们把它定位为低一级别的开发，那么，就需要大量的使用指针了。大量使用指针进行Unmanaged C#开发，“本质”上就是使用 C 语言。只是因为目前 JIT 技术发展年代仍不够久远，导致 Unmamaged C# 的性能较 C 语言 略低。
下面，画张图，描述一下当下的C#语言。
当下的C#包含了五种编程范式：类C、OO、泛型、Lambda、Dynamic。关于 OO、泛型、Lambda、Dynamic已经有很多文章介绍和总结了，关于类C这一块却很少有人写文章详细介绍。就像Ajax重新发现了javascript一样，我们也应该去重新发现C#中的Unmanaged 成分。
回看程序设计语言的发展史。C语言是一直的王者。但是由于抽象能力不足，在C的基础上出现了C++，后来又出现了帮你管家的保姆Java，于是，在系统层开发使用C/C++，在应用层开发使用Java成为一种常见的分工方式。有没有一种语言同时具备Java的快速开发优势和C/C++的高性能且能直接访问内存这两个优点呢？D语言就是奔着这个目标设计的。许多人对D语言报以厚望。可问题是，D语言看起来很美，但太草根了，各方面都不成熟。C#诞生之后，人们认为它和Java的定位是类似的，我也一直这样认为。同时，我还在寻找能够快速开发、自己管理内存、拥有庞大的类库的另一种语言，来进行高性能开发及实时开发。我看过D语言，看过Haskell语言，都不是我想要的，转一圈回来，发现，原来答案已在自己的手中，那就是已经用了很多年的C#——C#的Unmanaged部分。
开发过一个软实时系统，每秒钟有数百万对象生灭，是使用C++开发的。C++开发效率低下，我想寻找一个替代品。最先找到的是Java，由于GC的存在，在Java下开发软实时系统比较困难，以至于出现了专门的Java实时规范和实时Java虚拟机。当时接触C#不久，想，为什么C#下没人研究实时系统？现在知道了答案：那就是开发实时性应用，相对于Java，C#具有非常大的优势——由于Unmanaged 部分的存在，不需要专门的C#实时虚拟机。C# 中，GC 是无法直接插手非托管内存的，如果只有寥寥无几的对象在托管内存中，每一次GC时间十分短暂，可以忽略不计。
这两年开始进行图像处理方面的程序开发。图像处理开发，C/C++是王道。不过，C/C++开发效率低下是个大问题，同样需要寻找替代品。最开始我使用的是C++/CLI，使用后发现，C++/CLI 不好用，它继承了C++的所有缺点，最不能忍受的是狂慢的编译速度。C++/CLI的CLI部分虽然可以使用.Net的庞大的类库，但是没有C#自然。有没有一种更好的方式平衡开发效率和运行效率？有！那就是打开unsafe之后的C#：优雅的语法、快速的编译、庞大的类库、完美的IDE、想托管内存就托管内存，不想托管就不托管——犀利！非常的犀利！无比的犀利！。
在《编写高效的C#图像处理程序——我的实验》和《编写高效的C#图像处理程序——我的实验（续）》两篇文章中，我使用指针，得到了近似C语言的性能。因此，不必担心C#的性能。
C#目前包括的五种编程范式：类C、OO、泛型、Lambda、Dynamic，这五种编程范式几乎可以无缝的结合，熟练使用这些编程范式，可以把C#下的指针玩的天花乱坠：
（1）Class和Struct中可以直接包含指针成员，这样，我们可以设计一套自己的继承体系（当然，得在托管内存中。不过，可以将性能攸关部分放在非托管内存中，然后，将它的指针放到Class中，遵循Disposable模式来管理，避免内存泄漏。）
（2）C#下的泛型不支持泛型Class的指针，于是，我在《C#模板编程(1):有了泛型，为什么还需要模板？》和《C#模板编程(2): 编写C#预处理器，让模板来的再自然一点》这两篇文章中编写了C#的预处理器，再结合using关键字和partial关键字实现了对C++模板的模拟，用以Unmanaged C#代码的强类型复用。
这样处理，就写出了几个纯C#开发的高性能C#图像处理基本类，见博文《发布我的高性能纯C#图像处理基本类，顺便也挑战一下极限。:)》。
这些基本类可以通过指针访问图像的像素，也可以通过索引器来访问像素，也可以通过迭代器来访问像素。通过指针访问速度最快，但比较麻烦。通过索引器和迭代器访问比较慢，但比较方便。不过，通过索引器和迭代器来访问像素很容易误用，比如说，假设图像是A。A[1,2]可以获得图像的第1行(首行为第0行)，第2列（首列为第0列）的像素。假设想更改这个像素的Red值为5，这样写是无效的：A[1,2].Red = 5。因为，A[1,2]是一个Struct实例，它是坐标为（1,2）的像素值的“快照”，对A[1,2]的修改无法写入到图像像素中去，需要这样写才能实现真正的修改：Rgb24 item = A[1,2];item.Red = 5; A[1,2]=item。同理，通过迭代器访问，也无法修改像素具体值。
这样处理既不优雅，又容易误用。怎么办呢？思来想去，我决定取消它！改用另一种方式提供对图像像素的便捷访问。什么办法呢？Lambda表达式！可是，问题来了，C#下的泛型不支持具体的指针类型作为泛型类型，好在关上了一扇门，C#又打开了另一扇门——delegate 支持指针类型！于是，使用《C#模板编程(1):有了泛型，为什么还需要模板？》和《C#模板编程(2): 编写C#预处理器，让模板来的再自然一点》这两篇文章中提出的C#模板开发技巧，编写代码，有：
这样一来，就提供了ForEach扩展方法，可以通过指针直接访问具体的像素。同时，我也顺便实现了Count和Where两个扩展方法。Count和Where两个扩展方法同时提供了指针版本和非指针版本。
然后，编写类 Rgb24ImageClassHelper：
编译之后，就可以通过Lambda表达式通过指针来访问 UnmanagedImage<Rgb24> 实例中的像素。例子&性能测试为：