重新认识C#: 玩转指针

  1. 云栖社区>
  2. 博客>
  3. 正文

重新认识C#: 玩转指针

最美的回忆 2017-01-20 15:46:00 浏览808
展开阅读全文

    许多文章并不鼓励在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之间的对应关系见下图:

image 

    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#模板开发技巧,编写代码,有:

ImageClassHelper_Template.cs

 

    这样一来,就提供了ForEach扩展方法,可以通过指针直接访问具体的像素。同时,我也顺便实现了Count和Where两个扩展方法。Count和Where两个扩展方法同时提供了指针版本和非指针版本。

    然后,编写类 Rgb24ImageClassHelper:

Rgb24ImageClassHelper.cs

 

    编译之后,就可以通过Lambda表达式通过指针来访问 UnmanagedImage<Rgb24> 实例中的像素。例子&性能测试为:

例子与性能测试代码

 

    测试结果:

测试结果

 

    可见:使用Lambda表达式通过指针来访问像素比使用指针直接访问像素慢,大概速度是后者的 1/2 - 1/3 。而使用Lambda表达式通过值来访问像素比使用Lambda表达式通过指针来访问像素要慢。大概速度是后者的1/2。虽然速度慢下来了,但对于性能不攸关的地方,这样处理还是值得的——使用Lambda表达式可以让代码更简洁更优雅!

    好了,现在,类C,OO,泛型/模板,Lambda表达式就全揉在一起了,至于具体怎么用,就看具体情况下的权衡取舍了。如果再玩玩Dynamic,大概会有更有趣的玩法。

    现在看来,C#真是太NB了!通吃啊!

本文转自xiaotie博客园博客,原文链接http://www.cnblogs.com/xiaotie/archive/2010/04/10/1708746.html如需转载请自行联系原作者


xiaotie 集异璧实验室(GEBLAB)

网友评论

登录后评论
0/500
评论
最美的回忆
+ 关注