还是自己写的东西比较放心
2004-06-26 21:56
330 查看
最近不知道各位有没有到MS的网站上面看,在VS的页面里面有一个.NET的十个必用工具的Post。这个Post里面介绍的好几个工具都确实非常有用,比如说Reflector、NUnit、Regulator等等。
说起来真巧,这里面介绍的Reflector最近就被我检查出一个Bug,这个Bug在查看Microsoft.WindowsCE.Forms.dll里面的_SIPWnProc函数,翻译出来的C#代码竟然是:
internal PAL_ERROR _SIPWnProc(IntPtr hwnThis, WM wm, int wParam, int lParam)
{
if (this.EnabledChanged == null)
{
return PAL_ERROR.Handled;
}
this.EnabledChanged.Invoke(null, EventArgs.Empty);
}
竟然有可能没有返回值,这个Bug出现在4.0.7.0的版本。在反馈的email发出之后,作者跟我联系了,说最新的4.0.7.0版本没有这个问题。我但是不知道我用的已经是4.0.7.0了,还say sorry了。然后我立刻就发现这个问题,马上又给他发了一封信,后来没过多久就出现了4.0.8.0的版本了。
其实有时候还是直接用ILDasm比较让人放心,至少不会有很多逻辑性的错误。(我还试过用Reflector看Terrarium的程序的时候崩溃掉了,看的是一个import dll的函数,也不知道目前是否有修正。)
另外一个Regulator就更让我觉得还是自己写东西比较安全。虽然说这个东西好像挺好的,但是实际上我还是觉得他没有脱离写正则表达式的繁琐和重复性的工作。而让我感到更加吃惊的是,我的一个工作得非常好的正则表达式,竟然在他那里出错了,不知道为什么。这个正则表达式就是我上一次提供的.NET CF程序源代码级优化器的第一阶段的表达式,主要就是去除代码里面的注解、字符串等可能会引起错误理解的部分。这个表达式如下:
(?>/(?>/(?:[^\n])*|\*(?>\*(?![^/])|[^*])*\*/)|(?=[@""'])(?>@(?>\s|/(?>/(?:[^\n])*|\*(?>\*(?![^/])|[^*])*\*/))*""(?>""""|[^""])*""|""(?>\\.|[^""])*""|'(?>\\.|[^'])*')|(?<Catchable>(?:(?>\\.|[^@""'/#]|/(?![*/])))+)|(?>(?<Catchable>#endif(?>\s)*//(?>\s)*NACC|#if(?>\s)+ACC(?>\s)+(?>/(?>/(?:[^\n])*|\*(?>\*(?![^/])|[^*])*\*/)|(?=[@""'])(?>@(?>\s|/(?>/(?:[^\n])*|\*(?>\*(?![^/])|[^*])*\*/))*""(?>""""|[^""])*""|""(?>\\.|[^""])*""|'(?>\\.|[^'])*')|[^#]|#(?!else(?>\s)*//NACC))+#else(?>\s)*//(?>\s)*NACC)|(?<Catchable>#)))+
……很夸张吧?我不知道像这种级别的东西如果用Regulator怎么才能够设计出来,反正我用的是另外一种技术来做的,这个技术以及我所用的软件我下一次再介绍。大家可以试一下,这个表达式在Regulator里面会出现什么样的情况?输入可以是任何C#源代码,输出里面的Catchable组里面的所有内容拼起来之后就是已经去掉了注释和字符串的内容(还去掉了#if ACC到#else //NACC之间的内容)。可是在Regulator里面却出错了,出错的信息说")"这个符号不足,我也不知道这个问题到底是我用错了呢,还是Regulator有问题。关于这个问题,我也给Regulator的support去信了,给了一个FeedBack,不知道是否在最新的版本里面有所修正呢?我所使用的是2.0.3.0的版本。(最让我感到搞笑的是,FeedBack里面检测到的引用竟然是.NET CF的版本,而不是.NET Framework的版本。到处都是1.0.5000、1.0.3333,好好玩哦,不知道是不是他发现我用.NET CF比较多呢?)
写到这里,我就觉得正则表达式的构造还是用我自己写的那个软件比较放心,而且能够比较轻松的构造出比较复杂的内容。上面的那个还不是最长的,至少加速器里面的第二步骤所用到的正则表达式就有783个字符(上面那一个有516个字符)。像这么复杂的东西,如果要用Regulator这样的工具去创造(注意是创造,而不是有人指点你怎么去做),真是不可想象的一件事情。
不知道有没有人想知道我的那个正则表达式的编写器有什么“优点”呢?这个东西和上面的The Regulator相比较有什么最大的区别的?这个就恕我留下来卖个关子了。
说起来真巧,这里面介绍的Reflector最近就被我检查出一个Bug,这个Bug在查看Microsoft.WindowsCE.Forms.dll里面的_SIPWnProc函数,翻译出来的C#代码竟然是:
internal PAL_ERROR _SIPWnProc(IntPtr hwnThis, WM wm, int wParam, int lParam)
{
if (this.EnabledChanged == null)
{
return PAL_ERROR.Handled;
}
this.EnabledChanged.Invoke(null, EventArgs.Empty);
}
竟然有可能没有返回值,这个Bug出现在4.0.7.0的版本。在反馈的email发出之后,作者跟我联系了,说最新的4.0.7.0版本没有这个问题。我但是不知道我用的已经是4.0.7.0了,还say sorry了。然后我立刻就发现这个问题,马上又给他发了一封信,后来没过多久就出现了4.0.8.0的版本了。
其实有时候还是直接用ILDasm比较让人放心,至少不会有很多逻辑性的错误。(我还试过用Reflector看Terrarium的程序的时候崩溃掉了,看的是一个import dll的函数,也不知道目前是否有修正。)
另外一个Regulator就更让我觉得还是自己写东西比较安全。虽然说这个东西好像挺好的,但是实际上我还是觉得他没有脱离写正则表达式的繁琐和重复性的工作。而让我感到更加吃惊的是,我的一个工作得非常好的正则表达式,竟然在他那里出错了,不知道为什么。这个正则表达式就是我上一次提供的.NET CF程序源代码级优化器的第一阶段的表达式,主要就是去除代码里面的注解、字符串等可能会引起错误理解的部分。这个表达式如下:
(?>/(?>/(?:[^\n])*|\*(?>\*(?![^/])|[^*])*\*/)|(?=[@""'])(?>@(?>\s|/(?>/(?:[^\n])*|\*(?>\*(?![^/])|[^*])*\*/))*""(?>""""|[^""])*""|""(?>\\.|[^""])*""|'(?>\\.|[^'])*')|(?<Catchable>(?:(?>\\.|[^@""'/#]|/(?![*/])))+)|(?>(?<Catchable>#endif(?>\s)*//(?>\s)*NACC|#if(?>\s)+ACC(?>\s)+(?>/(?>/(?:[^\n])*|\*(?>\*(?![^/])|[^*])*\*/)|(?=[@""'])(?>@(?>\s|/(?>/(?:[^\n])*|\*(?>\*(?![^/])|[^*])*\*/))*""(?>""""|[^""])*""|""(?>\\.|[^""])*""|'(?>\\.|[^'])*')|[^#]|#(?!else(?>\s)*//NACC))+#else(?>\s)*//(?>\s)*NACC)|(?<Catchable>#)))+
……很夸张吧?我不知道像这种级别的东西如果用Regulator怎么才能够设计出来,反正我用的是另外一种技术来做的,这个技术以及我所用的软件我下一次再介绍。大家可以试一下,这个表达式在Regulator里面会出现什么样的情况?输入可以是任何C#源代码,输出里面的Catchable组里面的所有内容拼起来之后就是已经去掉了注释和字符串的内容(还去掉了#if ACC到#else //NACC之间的内容)。可是在Regulator里面却出错了,出错的信息说")"这个符号不足,我也不知道这个问题到底是我用错了呢,还是Regulator有问题。关于这个问题,我也给Regulator的support去信了,给了一个FeedBack,不知道是否在最新的版本里面有所修正呢?我所使用的是2.0.3.0的版本。(最让我感到搞笑的是,FeedBack里面检测到的引用竟然是.NET CF的版本,而不是.NET Framework的版本。到处都是1.0.5000、1.0.3333,好好玩哦,不知道是不是他发现我用.NET CF比较多呢?)
写到这里,我就觉得正则表达式的构造还是用我自己写的那个软件比较放心,而且能够比较轻松的构造出比较复杂的内容。上面的那个还不是最长的,至少加速器里面的第二步骤所用到的正则表达式就有783个字符(上面那一个有516个字符)。像这么复杂的东西,如果要用Regulator这样的工具去创造(注意是创造,而不是有人指点你怎么去做),真是不可想象的一件事情。
不知道有没有人想知道我的那个正则表达式的编写器有什么“优点”呢?这个东西和上面的The Regulator相比较有什么最大的区别的?这个就恕我留下来卖个关子了。
相关文章推荐
- 还是自己写的东西比较放心
- 关于内心的矛盾 打工还是自己干点东西 如果不想打工了,就看看吧
- Win32关于GDI 的API (Win32的API函数是微软自己的东西,可以直接在C#中直接调用,在做WinForm时还是很有帮助的。有时候我们之直接调用Win32 的API,可以很高效的实现想要)
- 有很多东西只要勤于思考,还是能够自己悟出一些道理的
- 腾讯云cdn流量会多统计,还是自己搭比较靠谱
- Windows下的命令行指令使用方法,有些东西还是比较有意思的,以前没有注意
- DOS命令还是比较有用的东西-用DOS命令批量加CVS用户
- 看来对于c提供的库函数,自己要看了才行,不然用着还是有些不放心。
- 不要神话创业,什么东西都可以自己做,损失就是不拿工资。如果吃不上饭了,那还是不要创业。服务器很便宜
- 发现自己对socket还是比较熟悉的
- 周鸿祎,高司令 2010-09-28 00:41 27469人阅读 评论(185) 收藏 举报 还是感到有必要将自己的一些想法快速记下来。 首先是对周鸿祎新员工演讲的看法。 就说实话这一点来说,周鸿祎比很多人强。所以我比较喜欢引用他的话,确实比较实在,不装逼。 至于一个公司招人的风格,是公司自己定的,别人也无权评价。有人说周是画大饼,忽悠员工卖命。废话,难道新员工讲话还有别的目的吗? 但我不认为周的选人思路在别的公司可以通行。原因是这样的:近十几年来,我们听到很多人有类似的说法,比如我们公司不要
- 系统的时间调不错,就是界面躁动太多,要是允许话还是在自己的界面中加入比较薄, 不过这个很方便。
- 自己写了一个js,但是最终不能控制住最后后的提交,前面的还是比较完美,大家看到后,能帮我解决一下吗?
- 书到用时方恨少 做项目的时候才知道自己懂的东西少了,有时候会因为无知,导致比较重的后果。所以平时不断地学习,看论文啊,或者看别人的设计方案了
- 还是把自己的东西搬到csdn吧
- 我还是自己的东西多,别人的东西都是很少的
- 自己总结出来的东西还是得谨慎
- tabhost先简单记一下,以后再改(即使一样的,还是自己写的代码比较亲)
- 想想还是用自己的博客写东西比较好
- 开学就要读博了,心理上还是比较有压力!祝福自己吧!