博客园_Gear.Turbo

解析命令行的正则表达式

2011-08-29T03:12:00Z

问题

最近在做一个控制台的程序，程序提供给用户几个命令。每个命令都可以接受多个参数，参数可以有值也可以没值。另外，如若参数中有空格则可用双引号（“”）把参数括起来以表示是一个整体。一些简单的命令例子如下：

regularCommand argument /a: value /b: value2 /argument: value3
regularCommand argument /a: value /b: value2 /argument: value3 /argumentWithouValue
regularCommand /a:value /b:value2 anotherArgument /argument:value3
commandWithSpaces "c:\Program files\application" /a: value /b:valu2 /c:"c:\windows\some folder"
commandWithSingleQuote "this is a 'test string' with 'single quote'" /a:"%&*^@special arguments" /b:value2

解决方法

对于命令行字符的处理中，关键的一个问题是如何正确解析命令的名字，以及命令的每一个参数和值。对于这个任务，正则表达式能很好的完成，从而省去程序员大量的手动code解析的工作，而且手动code解析比较容易出错。经过长时间的分析及测试，我得出如下表达式：

/\s*(".+?"|[^:\s])+((\s*:\s*(".+?"|[^\s])+)|)|(".+?"|[^"\s])+

对前述示例命令行的测试结果如下（测试工具RegExr）：

从图片中可以看出，命令名和各参数块都被正确的识别出。

接下来的一个重要任务是如何解析各参数名字和参数的值。首先，解析参数名字。这个相对比较简单，因为参数都是以“/”开头的，因此表达式如下：

/\s*(".+?"|[^:\s])+(?=[:\s])

对前述示例命令的测试结果如下:

从图片中看出，各参数的名字都被正确解析出。

有了参数的名字，则剩余部分为参数的值（注意，需要去掉分隔符“：”）。

结论

处理（查找，匹配，替换等）复杂字符串时，正则表达式有其无可替代的优势。在应用程序中正确的应用正则表达式可以减少代码量并减少错误发生的几率。

本文链接

你是如何让函数返回IEnumerable<T>的

2011-08-28T11:54:00Z

为什么让接口返回IEnumerable<T>

关于这个问题不需要过多的解释，且不是本文讨论的重点。简单来说，遵循接口最小原则，返回用户最少的行为即可。因此，能返回IEnumerable<T>则不返回List<T>或Collection<T>。

接口的实现函数如何返回IEnumerable<T>

一个最简单的方法，也是程序代码中经常见同事的做法是在函数中创建一个List<T>，然后对其进行赋值，最后作为函数返回值来返回。

这种做法完全正确，而且List<T>太好用了，以至于我们可以用它来解决大部分问题，一个简单而典型的例子如下（例子本身没有啥意思，仅作演示之用）：

IEnumerable<string> GetStrings()
{
List<string> list = new List<string>();
for (int i = 0; i < 10; i++)
{
list.Add(i.ToString());
}

return list;
}

然而，在任意创建一个List<T> 之前，或许存在某种更简单或更优雅的方法。

yield return 生成IEnumerable<T>

yield return 是C#的一个关键字，两者必须结合在一起使用，表示生成IEnumerable<T>的一个元素。因此，很多情况下yield return可以让我们减少新创建List<T>的几率。基于yield return，前面的例子可以修改如下：

IEnumerable<string> GetStrings()
{
for (int i = 0; i < 10; i++)
{
yield return i.ToString();
}
}

如此，程序则“优雅”许多。

如何生成一个空的IEnumerable<T>

经常见到的一些例子是生成一个空的List<T> 然后返回之。举例如下：

IEnumerable<string> GetStrings()
{
return new List<string>();
}

代码没任何问题，但总有那么点别扭：一个空的List<T>似乎生成的没必要。事实上，C#也为这种情况作了“优雅”的设计：

IEnumerable<string> GetStrings()
{
yield break;
}

对，没错！就是yield break，一个简单的关键字让程序“优雅”。事实上，yield return 和yield break结合起来可以处理复杂的逻辑，从而轻松的让函数返回IEnumerable<T>而尽量减少不必要的List<T>的中间变量。

一点观点

不要对语法糖抱有太多的成见，只要好用，为什么不去用呢？糖放在那儿，有谁不喜欢吃呢？

本文链接

对C#和C++0x中Lamda表达式的简略对比

2011-06-23T16:15:00Z

Lambda表达式起源于函数式编程语言，后来逐渐被面向对象的编程语言所采纳。本文所讨论的不是Lamda表达式的使用方法，而是通过对比Lamda表达式在C#和C++0x中的不同实现而找出其中的区别。

C#中Lamda表达式

基本的语法结构是()=>{}; 其中()是参数列表部分，用来定义函数的输入参数。定义参数时，用户并不需要定义参数的类型，编译器会根据函数体来“推演”参数的类型。=>部分读作goes to, 意思是函数有如下的函数体。{}部分便是函数的主体部分。一个求2个整数和的例子如下：

(a, b) => a + b;

当函数体只有一条语句的时候，{}符号和return关键字可以省略。

在Lambda函数体中，除了Lamda函数所定义的参数可以被使用外，Lamda函数体还可以使用外部变量，如下例：

void HostingFunction()
{
int c = 1;
Func<int, int, int> f = (a, b) => a + b + c;
}

注意被Lamda表达式所捕获的变量是与Lamda表达式是同步的，也就是说任何对原变量值的修改都会影响到Lamda表达式本身，即使对原变量值的修改发生在Lamda表达式生成之后。

C++0x中Lamda表达式

基本语法结构是[](){}; 其中[]是变量捕获列表，用来声明需要捕获的外部变量；()是参数列表部分，其功能等同于C# Lamda对应部分；{}是函数体部分，其功能等同于C#Lamda对应部分。一个简单的求2个整数和的例子如下：

[](int a, int b){ return a + b; };

可以看出，不同于C#的声明，C++0x Lamda表达式的参数列表中参数需要声明类型；函数体不能省略{}符号和return关键字；即使单条语句时也不能省略。

C++0x Lamda需要显式声明需要捕获的外部变量，如下例所示：

void HostingFunction()
{
int c = 1;
auto f = [c](int a, int b){ return a + b + c };
}

代码中声明了需要捕获外部变量c，则函数体中即可引用变量c，否则不能引用。不同于C# Lamda表达式，上述例子中对变量c的改变并不能影响f的行为，因为捕获的c是以值类型捕获的，也即是一份拷贝。如果对变量c采取按引用的方式捕获，则变量c的改变会影响f的行为。如下例：

void HostingFunction()
{
int c = 1;
auto f = [&c](int a, int b){ return a + b + c };
}

对比

通过对二者的简要对比可得如下几点结论：

C# Lamda不需要变量捕获列表而C++0x Lamda则需要，所以C#捕获外部变量的方式更简洁。
C++0x Lamda可以以按值或按引用两种方式来捕获变量，这是C++0x Lamda的最大优点；而C#只能以按引用的方式来捕获变量。
C# Lamda的参数列表不需要定义类型；而C++0x则需要。C#通过类型推演来避免定义参数类型，这是一个非常吸引人的功能。
C++ox 可以用auto关键字来声明Lamda；而C#则不能用var来声明Lamda
总的来讲，C# Lamda表达式更简洁优雅；而C++0x Lamda表达式则更功能强大。

本文链接

对C++和C#中多态及类型转换的理解（二）

2010-01-30T15:33:00Z

上一篇主要讲述了C++中的类型转换，本篇讲述的是C#中的类型转换。不同于复杂的C++，C#语言相对简单，其类型转换规则也比较少，主要有两种：as运算符类型转换和cast运算符类型转换。as运算符的方式不会抛出异常，转换失败返回null值，这也决定了as运算符不能用在值类型上；cast则是强制类型转换，用户可以定义自己的隐式或显式类型转换符。cast运算符在转换失败时会抛出异常。因此基于转换安全...

对C++和C#中多态及类型转换的理解（一）

2010-01-28T14:06:00Z

多态是面向对象理论的一个重要概念，类型转换是程序开发中不可避免的行为，两者总是贯穿在我们程序开发中，对开发者来说并不陌生。然而，就是这么熟悉的内容，我还是犯过一些错误，因此有必要对其主要内容做一整理来加深理解。本文的重点是总结C++和C#中有关类型转换的一些基本原理，之所以提到多态是因为类型转换后多态函数的执行是比较容易被误解的一点。基于这些出发点，本文并不是一篇介绍多态的详细文章。希望本文能给对...

查看C#代码的低版本实现

2010-01-26T15:08:00Z

本文是介绍实用工具Reflector的一个小应用的：查看C#代码的低版本实现。为什么要查看？语言发展的越来越高级，越来越抽象，抽象的语言势必包装隐藏了一些细节。而有时却有必要查看细节是如何，比如lambada表达、LINQ表达式等是如何实现的？IL是一个选择，但我比较讨厌不管问题大小，动辄就拿IL说事的做法，其实大多数问题不必要看IL。另一个角度，比如说明书，假若有10万言的和300字的两个...

Closure中关于递归的一点补充

2010-01-25T16:52:00Z

在对Closure的再思考里面我提到了说网上有观点认为用lambda表达式声明的“递归”实际上并不是真正的递归。本文针对这个观点做专门的研究。传统的递归所谓传统的递归，是指一直来我们所经常使用的经典结构的递归。以n的阶乘来作为例子说吧，“传统”的递归结构可以用如下的代码表示： public static int FacRecursive(int n){ if (n <= 1) retu...

对Closure的再思考

2010-01-24T14:30:00Z

前些日子我对Closure做了初步的思考, 却总觉得意犹未尽，感觉Closure还没有进入到我心里去，还没有真正地、完全地理解。好吧，就把近日来杂乱的思考整理一下写出来吧。为了便于理解，就让我从一些废话开始吧。众所周知，在C#中有两种类型——值类型和引用类型。就从引用类型谈起吧。引用类型的回顾对于下面的代码： object obj = new object();object A = ...

Tools in Visual Studio 2010

2010-01-23T06:23:00Z

一直以来受到"工具只是工具"类似观点的影响，工具在我的思想中便不被重视。然而，在很多方面由对这个观点的错误理解造成了我对好多优秀工具的疏忽，从而多做了好多不必要的工作。当然，我并不是否认"工具只是工具"这个观点，毕竟其本意是指导我们不要看不见事物的本质。另一个方面，"工欲善其事，必先利其器"这个观点也是响当当的，是告诉我们好的工具是可以省去我们很多没必要的劳动的。话题回归到Visual Studi...

旋转的女郎

2010-01-18T15:55:00Z

本来在开心网上对这幅图做了一个解释的，昨天想翻出来，无奈无论如何也找不到了，于是有必要写下来记录一下了。网上流传的关于这副图的"功能"想必不再需要我赘述。总之流言很多，"耶鲁大学最新研究发现"的说法就更有损耶鲁大学的名声了，无非是此小游戏作者为了对其伟大的想法加上一定的"砝码"而杜撰的，然而是否属实也无法考证，在此我也只是推测。首先，让我们来澄清一下"顺时针"和"逆时针"的概念。这两个概念和"左"...