我说了决定了，是不会随便更改的。尽管这里看的人很多，但是我有我的考虑，基本上该讲的已经讲完了。有人说，“你不是走了么？怎么又回来发一篇文章？”我怀疑我这么发文章，那些这么怀疑我的人是否会看到。一句话解...- Linq那一页说的是错的，那不是Linq，只不过是Enumerable的扩展加上匿名方法而已。是Linq的实现基础，不是Linq。
- 我说了决定了，是不会随便更改的。尽管这里看的人很多，但是我有我的考虑，基本上该讲的已经讲完了。有人说，“你不是走了么？怎么又回来发一篇文章？”我怀疑我这么发文章，那些这么怀疑我的人是否会看到。一句话解...
- 我说了决定了，是不会随便更改的。尽管这里看的人很多，但是我有我的考虑，基本上该讲的已经讲完了。有人说，“你不是走了么？怎么又回来发一篇文章？”我怀疑我这么发文章，那些这么怀疑我的人是否会看到。一句话解...
- 我说了决定了，是不会随便更改的。尽管这里看的人很多，但是我有我的考虑，基本上该讲的已经讲完了。有人说，“你不是走了么？怎么又回来发一篇文章？”我怀疑我这么发文章，那些这么怀疑我的人是否会看到。一句话解...
- 博主您好！首页是发表精品文章的地方。您的博文“QUIZ：一个有8个属性的匿名类大约会占多大的文件大小？”被移出首页，由此给您带来的麻烦，请谅解！首页文章要求：原创，排版整齐，文中有文字明确说明文章的主...
- @银光小子
需要代码么？需要么？需要么？不已经说了么，一个只有一个TextBlock，里面只有一个字符，你自己不会敲么？在一个html页面签入copy&paste一下VS会自动给你生成的嵌入SilverLight对象的代码还需要贴出来么？还是说您和韦恩卑鄙一样，摔着手了么？
哎，我真不想发飙，可是你们什么都伸手要，不读文字之看漫画，怎么能提高呢？给你一个英文文章的连接，是不是还要我给你翻译了你才看？里面没有图，还要我给你画一个？那你的大脑是用来做什么的？你的手是用来做什么的？
还是说，你认为我说谎了，一定要贴一个图出来证明什么，然后你好说“兰州烧饼，鉴定完毕”？
我无语…… - @Curry
WP7的开发，应该是就一个SL应用吧，不是在一个浏览器里面显示的HTML页面中嵌入多个应用吧？对此情况我没有做过任何实验，所以不能回答你的问题。并且，很遗憾的告诉你，我刚刚做了一个艰难的决定——我不再在博客园玩了。所以，以后还想交流的话，可以微博上找我。 - 答案：It depends.“你去屎吧！”我猜一定会有人这么说。既然“改天我也去发一篇“QUIZ: 园子一个用户发多少篇给个问题还看心情才给答案的文章才会让全园友崩溃，是什么原因”放首页来好了”这样的...
- 一个很简单的SilverLight4应用，上面只有一个TextBlock，里面只有一个字。你猜，这一个SilverLight在同一个页面中创建多少个时，会出现莫名其妙的崩溃？这种崩溃和什么有关？哈，知...
- 在你们的开发当中，是否用过匿名类？也就是比如说：var query = from item in database.Pages where item.PageId == 100 select new ...
- 答案是：System.Security.Cryptography （.NET FX 4.0，见下图）这个Quiz看过的人不超过160个，说明大家越来越水了。打口水仗各个精神百倍，唾沫星子四处飞。真正来...
- 你的思路错了，被订阅多次是订阅方的错误，这种问题只能是通过修改订阅方代码来解决。如果试图在Observer这种模式下面由事件发布方来控制解除订阅，只会造成更多的问题。我也没有很仔细的看代码，但直觉感觉有问题。
- 从理论上来说，应该是我的快。我不太确定你的索引法是否就是先建立排序数、平衡树之类的，然后再进行比较。其实就讨论下面这几个问题即可：理论上，在完全没有任何命中的情况下，平均每个字符会被比较多少遍？如果全部命中，平均每个字符会被比较多少遍？
前者我的算法是1，后者是略大于2。
当然，还有一个问题是，就是会出现多少的假命中。对于我的算法来说，这个可能性一般比较低，需要长度相同、头尾字符相同、并且中间字符的哈希值相同。只要不是特殊构造的，应该不会经常出现假命中。如果假命中很厉害的情况下，也就等于大约是全命中的情况。 - 1、4.0的mscorlib里面最占文件空间的类是哪一个？2、最主要是因为：A) 对该类及其成员的描述；B) 该类及其成员的名称；C) 该类及其成员的签名；D) 该类中的IL代码；E) 该类所使用的字...
- @万仓一黍
还是写一下吧，也许能开阔思路。 - ) 对于差异很小，且自身重复字符非常多的串如1111111011111和1111101111111，时间和空间将会非常的悲剧；
因此该算法在遗传学领域的应用价值可能很小，在文本比较的价值上可能会更高。如果要扩展到二进制文件比较，很可能需要对这个算法做一些复杂的改进，否则两个3MB大小的文件，可想而知256个字符中的每一个都会大量的出现在两个文件中，产生的集合就会非常的大。就算是文本比较，如果是比较英文，那也是很悲剧的：26个英文字母，就算加上大小写和各种字符，重复率是非常高的。... - 么就会永远匹配后者，此时对于AYXB和AYYB这两个串，就会得到类似前一种情况的更长的结果。
如果真要修正这个BUG，可能需要修改成一直对比到B串pos = N(i-1, j)-1，然后比较B串的pos = N(i-1, j) 和 pos = N(i-1,j)-1这两个字符是否相等，相等则选择后者。
但是，我并没有仔细验证者是否适用于更复杂的情况，所以并没有进行修改。考虑到这么做会增加很多的计算（每扫描一次A串中的任意一个字符，都会增加这么一些计算），而且这么做并不会导致公共串变得更长，只是匹配长度减小，所以我并没有进行这个修改。
我现在更关心的是，如何给这个算法加上权重。权重对于差异压 - 呃，最佳匹配应该不是指长度最短，而是指公共串最长。
- Nakatsu有一个问题：能加权重吗？还没有仔细想，但这个问题会影响应用范围的。
- 代码数量多并不是问题，有代码生成工具来代劳，比如Linq2Sql/EF就有。
- 对于不使用ORM个人觉得不太了解为什么，比如Linq2sql/ef或者NHibernate之类的。另外复制为什么不使用MemberwiseClone？
- 击并不明显时，数据层开发简单，业务层的变动也确实是比较小的。但是你需要确定，你的场景属于这种情况。所述情况并不包括发生删改的情况，那将会冲击业务层的代码。对了，还有另一个悲剧，那就是你很难通过编译，来检查业务层是否已经全部正确的进行了修改，以适应数据库结构的变化。
在业务经常变化导致数据库结构可能经常发生变化的场景中，纯粹的DataTable会更合适一些，此时业务实体也需要尽量少，以避免需求变化时发生冲击。... - 另外，VI一文能否总结一下？中英文混排会看着好累……
我没有花时间仔细看，不知道该算法是否只能够得出长度，而不能得出匹配？如果是这样的话，对于做Diff一类的任务，似乎是没有帮助的。 - 其实我对该算法进行了一定的优化，其中空间优化部分已经有程序了，时间优化（剪枝）也推演过，但是还没有写代码测试。我觉得该领域的问题非常的值钱，在考虑是否要申请专利。申请专利就不能先提前公开了。
- 等就认为同样都是有效解，你的串长度是48只不过正好恰巧凑到了Nakatsu算法的特别之处：当找到最佳解的时候，行数就是公共串长度。只是你不能由这个结论任意反推可能的正确解。...
