先给出github上的代码链接以及项目需求

1.项目概述

这个项目的需求可以概括为:对记事本(txt)文件进行单词的词频统计和排序,排序结果以指定格式输出到默认文件中,并要求能够快速地完成整个统计和结果输出功能。乍一看,这个功能实现起来十分简单,基本上就是遍历一遍文件,对提取出来的单词按照词频排个序就搞定了。但是要是考虑到性能问题,那还需要多动动脑筋。下面附上这项目的PSP表格。

PSP2.1 PSP阶段 预估耗时(分钟) 实际耗时(分钟) PSP2.1 PSP阶段 预估耗时(分钟) 实际耗时(分钟)
Planning 计划 5 5 Development 开发 310 340
· Estimate · 估计这个任务需要多少时间 5 5 · Analysis · 需求分析 (包括学习新技术) 30 30
· Design Spec · 生成设计文档 20 20
Reporting 报告 52 **52 ** · Design Review · 设计复审 (和同事审核设计文档) 10 10
· Test Report · 测试报告 30 30 · Coding Standard · 代码规范 (为目前的开发制定合适的规范) 30 60
· Size Measurement · 计算工作量 2 5 · Design · 具体设计 60 60
· Postmortem & Process Improvement Plan · 事后总结, 并提出过程改进计划 20 20 · Coding · 具体编码 90 60
· Code Review · 代码复审 10 10
· Test · 测试(自我测试,修改代码,提交修改) 60 90
合计 367 397

因为我个人数据结构学得比较好,所以我做这个项目的时候很顺利,各种链表、散列写起来也得心应手,于是编码阶段花费的时间比预计的还要少。(后来知道室友全程使用C++自带的向量类、容器类,根本就不用自己动手写内部实现,我自己倒是哼哧哼哧写了好几个数据结构。只好感叹自己还是比室友少算了一步,哈哈哈)而在制定代码规范的时候,我们花了一个小时去研究Google提供的C++编码规范,就感觉开辟了新世界的大门,很多我之前认为很规范的代码,都被这个规范“一棍打死”!最后,在单元测试的时候,由于出现了未曾预料的BUG,也耽误了不少时间。

2.大体思路

这个项目的核心任务可以分为两部分,一是在文本中识别出不同的单词,二是统计所有单词并将这些单词按照词频进行排序。我们将我们的程序大致可以分成四个模块:输入模块,状态模块,统计模块,输出模块。具体的需求分析文档可以在这里找到

在文本中识别出不同的单词

识别文本中的单词,我使用的是一个有限状态机模型。

假如文本中没有连词符 '-' ,那么问题十分简单,只有两个状态,一个是单词内部,一个是单词外部,相互转换的条件则是在单词内部的状态下检测到一个非字母字符,或者在单词外部的状态下检测到一个字母字符。

当文本中出现了连词符,那么情况会复杂一些,不过仍然不会太复杂。我们增加了一个临界状态,当读入一串字母之后突然检测到了一个连词符,则会进入到这个状态。这个状态不会持续,一旦读入下一个字符,就会根据它是字母或者非字母字符,进入到单词内部或单词外部的状态。

使用这一个3状态7过程的状态机模型,可以完美地满足需求。

统计所有单词并将这些单词按照词频进行排序

这个部分就复杂一些。我们的基本思路是使用一个双向链表来存储所需要的数据,具体来说,每个结点记录了一个单词和这个单词的词频,从链表到链表尾词频依次递减,相同词频字母字母靠前的靠近链表头。每次遇到一个单词,我们先去查找有没有对应于这个单词的结点,如果有,就让这个单词的词频加一,否则在链表的尾部添加一个这个单词的结点。然后不论哪种情况,都要对该单词对应的结点进行调整,使它在同一词频的几个其他单词中,根据首字母大小排序,处于正确的位置。最后从链表头开始,依次遍历一百个结点,就能找到词频最高的一百个单词。

这个方法简单粗暴,但效率低下。两个原因,一个是结点交换位置时必须依次在相邻位置进行交换,这个缺点是对于链表这种数据结构来说无法克服;另一个原因是查找单词时必须从链表头开始遍历。我们考察了很多种数据结构,但是没有一种数据结构能够既快速地处理排序,又能快速地查找结点。机智的我决定给这个链表,根据单词内容构建一个哈希索引。对于每一个单词(实际上是一个字符数组),我们可以对所有字符进行求和,然后通过模除得到哈希索引,通过哈希索引来查找结点,大大提高了查找的速度。为了提高哈希函数的性能,我们选取128作为模,因为任何一个数模除128都可以写成它和127进行按位与(&)运算,与运算的速度远远高于除法。

引入了哈希索引的链表看起来像是这样的:

3.代码框架与接口

整体思路现在已经十分明晰了,在统计词频的时候,我们依次读入文件中的字符,根据状态迁移的路径,决定是否到了一个单词的末尾,是否将单词添加进入我们的数据结构。

 	WordState wordState;     //用于记录当前的状态
processType process; //这个变量用于记录状态迁移的路径 char c = 0;
do {
c = in.get();
//这个函数可以根据读入字符进行状态转移,并返回转移过程
process = wordState.stateTransfer(c); switch (process) {
//根据不同状态做出不同的响应
case PROCESS_23:
//临界状态->单词外部,删去最后一个连词符,单词数++
break;
case PROCESS_13:
//单词内部->单词外部,单词数++
break;
case PROCESS_33:
//单词外部-单词外部,放弃这个非字母字符
break;
default:
//其他情况:储存这个字母字符
}
} while (c != EOF);

为了记录单词及其词频,我们建立了一个WordList类,其中包括一个链表和这个链表的索引。最后,我们得到一个关于程序的大体框架,这个大体框架的代码可以在这里看到。其中,最重要的两个接口在下面给出:

processType WordState::stateTransfer(char c);        //根据当前状态及下一个字母,返回状态转移的方向
void WordList::addWord(char word[]); //向WordList中添加一个单词,如果已经有这个单词,则它的词频+1

状态迁移函数十分重要,但之前我们说过,这个状态模型非常简单,只有三个状态七条路径,这里就不详细说明了,你可以去github上看到具体的实现。添加单词的函数就比较繁琐了,它涉及到:利用单词计算哈希索引、根据哈希索引查找结点,对结点的位置进行调整。具体的代码在下面给出。

    int  p_index = Hash(word);    //利用单词计算哈希索引

    WordIndex* pIndex = index[p_index];
while (pIndex != nullptr) {
Word *pWord = pIndex->pWord;
if (!strcmp(word, pWord->word)) { //在哈希索引对应的几个单词中,找到我们需要找到的单词
pWord->num++; //如果找到了,首先把这个单词的词频+1 //接着根据词频调整单词的位置
Word *qWord = pWord->previous;
while (qWord->num < pWord->num) {
if (qWord == pWordHead)
return; shiftWord(pWord); qWord = pWord->previous;
} //然后再在同一词频下根据单词在字典中的顺序调整位置
while (strcmp(qWord->word, pWord->word) > 0) {
if (qWord->num > pWord->num) return;
shiftWord(pWord);
qWord = pWord->previous;
}
return;
}
pIndex = pIndex->next;
}

当然,上述代码只给出了根据哈希索引成功找出结点的情况,对于首次遇见的单词,无法根据哈希索引找到它,那我们就在链表的末尾增加一个新的结点以记录这个单词,然后为它建立一个索引。具体的代码可以在github中找到。

4.单元测试

WordList类是我认为最有风险的一个类,它用于实现这个项目最最最主要的功能:词频统计。而为了实现这个功能,它又要调用各种子函数(如哈希函数),从函数调用图来看,它的入度和出度总和是最高的。具体的测试用例设计表格在下面给出。完整的测试用例表格可以在我们的github上看到。

13个测试用例,从最简单的对一至两个单词进行的功能测试,到最后面对高频词、长单词、超多种类单词进行性能测试,基本把能想到的部分都测了。

其中,第八个超长单词测试,我们使用了一个22个字母组成的单词进行测试,注意到我们代码中为单词设置的最大长度是20,所以这里产生了错误。修改的方法很简单,重新设定单词最大长度即可。

第12和第13个测试用例出错是我没有想到的,这个测试用例无法正常运行,提示说这是一个非法堆指针错误。



一开始我以为是堆空间不够了(因为从aaa-zzz总共有一万多个不同的单词,意味着链表有一万多个结点),我就调大了堆空间,但是没有奏效。我就只好硬着头皮使用断点调试,发现其实链表建立很成功,出错的是在测试执行完毕之后,释放空间的那段代码。为了少些几行代码,在释放链表空间的时候,我采取了简单粗暴的递归方式:在释放一个结点之前,首先调用next结点的析构函数,然后再释放自己。这就是一个递归的过程。

    //错误的示例
~Word() {
delete next;
next = nullptr;
}

但是,现在我们总共有一万多个链表结点,也就是要递归调用10000多层!!!栈空间肯定不够了。要怪只能怪我偷懒,后来我老老实实改成了用一个for循环释放结点,测试就成功通过了。

        //正确的示例
Word *p = pWordHead;
while (p != nullptr) {
pWordHead = p->next;
delete p;
p = pWordHead;
}

成功的单元测试脚本运行结果如下图。一个值得注意的现象是,用例12和用例13分别是顺序多单词测试和逆序多单词测试。在顺序多单词测试中,所有的单词都按照字典顺序进入链表,不需要做多余的排序,因此仅仅用了307毫秒就完成了对一万七千多个单词的词频统计。相比之下,用例13每个单词都按照字典逆序进入链表,这意味着每个单词都要进行一次排序(而且这个排序很慢,是一个节点一个节点地挪动,在前面也解释了,这是链表的硬伤),最后用了24秒才完成统计,是用例12的80倍!如果不使用链表,而是使用向量的话,可以考虑使用先统计后排序的策略,向量排序是很快的,它有封装好的快速排序的算法,可惜我既然已经走上了链表的道路,再推翻重写就有点不太愿意了。

总体来说,我负责的部分测试质量还是不错的,它全方位地考虑了各种情况,包括极限情况,而且也确实发现并解决了问题。对于被测模块(WordList类),我认为在测试过后,它的质量也十分的好:首先它能正确完成需求。其次,对于各种高频词、长单词、多单词都能够处理。只有对于极端情况(用例13),才会有些吃力,不过这个情况简直太极端了,正常的用户绝对不会遇到。

5.静态检查

使用静态测试是为了确保代码符合行业规范。在这个项目中,我们参考了Google给出的C++风格指南,并且对所有的代码进行了检查。Google给出的代码规范涉及的范围十分全面,从头文件、命名空间,一直到if……else……语句,到注释、空格、花括号,都给出了详尽的规范。我们本来想使用Google提供的所有规范,但后来失败了。一方面,有些规范我们不是很能理解,例如Google对于命名空间提出的规范,我们并不能完全地理解;另一方面,规范中的某些内容我们并不认可,比如对于变量的命名,Google推荐使用下划线分隔变量中的每个单词,而我们认为变量命名使用变量首字母小写、单词首字母大写,中间不使用空格分隔的方式也很好(而且这是面向对象程序设计老师推荐的命名方式)。

综上,最后我们仅使用了头文件注释格式上的规范对整个项目进行代码检查。

进行代码检查,我们使用的是一款也是由Google提供的代码检查工具cpplint。这款工具十分方便,对于一款配置好Python环境的电脑来说,只要将被测文件和脚本文件cpplint.py放在同一目录下,然后使用控制台运行Python脚本(被测文件路径作为参数),就能够快速地进行测试。对于Python3环境来说,需要对脚本进行一些修改,修改的方法在这里给出。

我们的代码主要存在的问题就是格式,以及一点点头文件的问题。Google规定代码中所有用Tab制表符的地方都得使用空格,每个花括号之前都要有一个空格,以及对于if……else……语句来说,只要一个分支使用了花括号,那么所有的分支都要使用花括号,而且else分支必须和前后两个花括号处在同一行。对于注释,注释内容和双斜杠之间必须要留有一个空格(我也不知道为什么)。

    // 符合Google 规范的代码
if ((c >= 'a') && (c <= 'z')) {
state = INNERWORD;
} else if (c == '-') {
if (state == INNERWORD)
state = CRITICAL;
else
state = OUTERWORD;
} else {
state = OUTERWORD;
}

对于头文件而言,每个头文件都必须给出版权声明,还要进行#define保护。

// Copyright[2018]<Star>
#ifndef WCPRO_WORDLIST_H_
#define WCPRO_WORDLIST_H_ // 在这里添加代码... #endif // WCPRO_WORDLIST_H_

不得不说,Google给出的规范真的是面面俱到。然而真的要实现它的所有规范我也不是很愿意。就拿#define保护来说吧,这三行代码,在VS编译器下,只需要用 #pragma once 这一条指令就可以实现。对于if……else……分支的种种规范,我觉得都很多余。我个人本身也有一套自己的格式规范,我的if语句看起来本来也相当顺眼,非常整齐,改成Google规范后反而看着不舒服了。

这个项目大部分代码都是我和Levey写的,就我们所采用的那部分Google规范而言,我们实际上都是差不多的。原因就是,在VS编辑器中,调整代码格式可以很方便地使用一组组合键来完成(Ctrl+K 和 Ctrl+F),使用这个组合键,可以快速地将我们的代码调整至VS的代码规范。对于没有采用Google规范的那部分(即,变量命名),我自认为胜他一筹,我对于变量命名,都会确实使用变量的含义命名,如pIndex, wordState等等,不会使用形如c, p, q 这样的简单的单字母来命名。(在小组讨论之前,我单独和Levey同学讨论了代码,提前把命名问题告诉了他,在静态检查之前就已经改正了。)

6.性能测试和优化

I/O优化

为了寻找一份一个在内容上能造成足够压力的txt文档,我在网上找了以《巴黎圣母院》为首的四部英文名著,把它们整合成一份大小超过5M的txt文档。这份文档也会在github中提供(文件非常大,需要下载下来才能看到)。



第一次测试是很惨烈的,我运行了数秒钟之后发现程序没反应,特地加了断点去看。确保程序的确在正确地运行后,我又足足等了一分多钟才运行出结果。而我室友跑出来的程序只要两秒钟(虽然室友的是错的)。

这个运行时间让我十分惊讶,首先我决定对I/O进行优化。我们的程序读取文件采用的是逐字符读取的方式,边读文件边处理,那么一个文件里面字符越多,我们的I/O次数就越多。于是,我们对此进行了改进。先将文件的所有内容一次性读到内存中,然后就可以关闭文件,从内存中逐字符判断了。

// 改进的I/O代码
ifstream in(fileName, ios::binary);
if (!in) { // Determine if the file exists
cout << fileName << "file not exists" << endl;
return nullptr;
}
filebuf *pbuf = in.rdbuf(); // 调用buffer对象方法获取文件大小
long size = pbuf->pubseekoff(0, ios::end, ios::in);
if (size == 0) {
cout << fileName << "file is empty" << endl;
in.close();
return nullptr;
}
pbuf->pubseekpos(0, ios::in); // 分配内存空间
char *ch = new char[size + 1];
pbuf->sgetn(ch, size);
ch[size] = '\0';
in.close();

在进行了这一优化后,运行时间减少了5秒(是的,只减少了5秒而已)。

排序优化

作为一个执着追求优质程序的人,我并不满足于这短短5秒的缩短。并且我们在前面提到,链表是一个对排序极其不友好的数据结构。想必剩下的时间开销就是链表造成的。终于,我决定彻底放弃链表。注意到需求中说,只要对前100个单词进行排序。所以我觉得在统计单词的时候不去做任何的排序,在统计完之后,首先采用选择算法找出前一百个单词,然后再进行排序。创建一个优先队列(最小堆)来做这件事情再适合不过了。对于一个单词量(n个)很多的文件来说,我们建一个大小为100,层数为7的堆,最坏情况下的时间开销也是O(7n),是一个线性的时间开销。对一个大小为100的固定的堆进行排序,在单词量很大的情况下,可以视为将时间开销视为常数!当然,在统计单词的时候,为了快速查找单词,我们仍然沿用了之前的哈希索引,将所有的结点先存放在散列中,最后在输出的时候再进行堆排序。

堆的常规操作包括建堆、上滤、下滤、排序,这些我们在这里不多说明。散列的使用也和之前相差不大,具体的代码可以再github上看到。优化过后的代码,运行时间大幅下降,从之前的一分半钟下降到现在的13秒,速度提高了六倍!在面对更加巨大的文件时,可以估计,时间增长也会想当缓慢。因为当文件足够大是,由于英语单词的种类并未是无限的,到最后单词种类必然会趋于一个定值,这意味着我们的单词结点数目并不会无限地上升!在一定范围内,我们的时间复杂度和结点数成线性相关,那么由于排序所造成的时间开销,将不再无限制的上升!唯一会增加时间开销的就是I/O操作,当文件非常非常非常非常巨大时,排序的开销趋于定值,I/O操作成为时间开销的主导。不过,我们已经在上一步优化了I/O,而且文件再大也不会大到无限制,至少不会超过电脑所能提供的最大的堆空间。

哈希优化

然而想想室友的程序只花了2秒多久运行完成了,我还是很不甘心的。他直接调用了某些库文件提供的方法,这些方法为了确保高效率,甚至使用了汇编代码来编写!所以我们也要继续优化(当然,我们仍然不会去调用现成的库函数)。现在,我们的IO操作、统计、排序的时间开销是这样的:

现在,统计的时间开销变成了整个项目优化的瓶颈!回顾一下我的统计是怎么实现的:首先构建一个长度为128的散列表,在录入单词的时候,给单词的所有字符求和并取模,得到一个散列表的索引,然后根据索引得到一系列的结点(这些结点以散列表为头结点,形成一个线性链表),逐一排查,如果遍历完这个索引下的所有结点,仍然没有找到单词,那么就在散列表的头部添加一个结点。查找、增加结点的过程看起来是这样的:

void WordList::addWord(char word[]) {
// Add the word to the WordList (or word frequency +1)
int p_index = Hash(word);
Word* pWord = index[p_index]; while (pWord != nullptr) {
if (!strcmp(word, pWord->word)) {
pWord->num++;
return;
}
pWord = pWord->next;
} pWord = new Word(word, 1, index[p_index]);
index[p_index] = pWord;
wordNum++; }

现在,这里的时间开销达到了瓶颈,所以我们不得不再去对这个地方做出改进。首先想到的是,对于一个5M的文件,我们使用一个大小为128的散列表来存放单词,可以预料到,效率会十分低下。每个单元里可能会有上百个单词,每次都要遍历这些链表,时间开销会十分昂贵。我们可以把散列表扩大吗?

答案是可以,而且扩大散列表,并不会加剧空间开销。我们知道,在散列表还是一个空表,没有任何一个结点时,它的空间开销是L倍的结点指针大小(L是散列表的长度),当成千上百个结点慢慢进入散列时,散列表本身的空间开销仍然是L倍的结点指针大小,就可以看成是一个常量了。而结点的个数和文件里面的单词种类有关,和散列表的长度无关。于是,即使我们将散列表的长度扩大数倍,也不会付出很大的空间代价。当然,我们也不会无限制地扩大,注意到我们的哈希函数是对单词所有字符求和,高频单词通常都比较短,求和结果也就是几百而已。如果散列表太长,散列表靠后的那些桶就没办法最大效率地利用到,散列就不均匀了。

在我们的深思熟虑以及亲自尝试下,我们认为512是一个合适的散列长度。将散列表增长后,时间开销有了显著的减少,大致缩短为原来的三分之一。

还有一个问题。在我们通过哈希函数得到索引,然后对一系列具有相同索引的结点进行逐一排查时,如果可以尽量保证高频词优先被排查,那么效率就会进一步提高!审视一下我们之前的代码,每次我们在散列中添加单词时,都会选择在散列的头部添加。这意味着,最先出现的单词排在了散列的尾部,每次都会被最后一个排查到。对于一个有意义的文本,高频词通常都会很快遇到,低频词通常会在文件中后部才首次出现。这无疑会大大增加排查产生的时间开销。

因此,我们决定将这些后出现的单词添加到每个散列表引出的链表的尾部。这一做法并不会使得每次添加产生额外的开销(都只要排查一次所有结点),但是大大提高了查找的效率。在这一次优化后,我们的性能再一次得到了质的飞跃!运行时间缩短了三分之一!不过还是要强调一点,对于一个全随机的无意义的文件,这一做法并不会提高效率!

如果你想看一看我们写的改进后的代码,可以在这里查看WordList.h

这下,对于一个5M的有意义的文件,我们仅仅需要2.100秒就可以完成词频统计(包括输入、统计、排序、输出),和室友调用库函数的效率不相上下!相比最开始的97秒,性能提高了45倍!并且当文件大小不断增长,我们的统计、排序和输出的时间开销将趋于常数(因为单词的种类趋于常数,散列表的大小是常数,并且对100个单词进行排序和输出也是常数开销),IO操作相当快,程序的整体性能非常高!



(运气最好的一次,仅仅在2秒内就完成了对一个5M大小的文件的词频统计!)

7.总结

我们所做的这个项目可以说是非常有意义了!从一开始认为这个项目十分简单,到后面开始测试发现各种奇怪的bug,再到最后为了提升性能对源代码大幅修改,我亲自见证了一个简陋的程序进化为一个高质量程序的过程。为了做这个程序,我前后使用了散列、链表、优先队列,这都是最最重要的数据结构,现在,我能够驾轻就熟地亲手操纵这些数据结构,这意味着我离一个合格的程序员又近了一步。

纵观这次项目开发的过程,我们先进行需求分析,然后设计、编码,在保证程序基本正确的情况下,首先进行静态测试以规避隐藏的缺陷,然后设计测试用例进行详细的单元测试(从最基础的功能,到用户可能使用到的最刁钻的功能),最后进行了性能测试。实际上,开发和测试是不分家的,在编码的时候,绝不可能一味地从头写到尾,一定是边写就边测试了;在性能测试时,这点我深有体会,性能测试花费的时间远远没有我为了提升性能,而进行的“二次开发”多。测试和开发相辅相成,如果孤立地看待测试和开发这两件事情,那软件质量一定也不会好。

C++实现对文件中各单词词频的统计及其代码优化的更多相关文章

  1. java算法面试题:编写一个程序,将a.txt文件中的单词与b.txt文件中的单词交替合并到c.txt文件中,a.txt文件中的单词用回车符分隔,b.txt文件中用回车或空格进行分隔。

    package com.swift; import java.io.BufferedReader; import java.io.BufferedWriter; import java.io.File ...

  2. Java 中统计文件中出现单词的次数练习

    统计英文article.txt文件中出现hello这个单词的次数 这个是article.txt文件内容 { hello The Royal Navy is trying hello to play h ...

  3. Scala快速统计文件中特定单词,字符的个数

    val fileContent=Source.fromFile("/home/soyo/桌面/ss5.txt").getLines.mkString(",") ...

  4. c语言统计一个文件中的单词,字符和行数

    body, table{font-family: 微软雅黑; font-size: 10pt} table{border-collapse: collapse; border: solid gray; ...

  5. Hadoop 统计文件中某个单词出现的次数

    如文件word.txt内容如下: what is you name? my name is zhang san. 要求统计word.txt中出现“is”的次数? 代码如下: PerWordMapper ...

  6. 编写一个程序, 将 a.txt 文件中的单词与 b.txt 文件中的 单词交替合并到 c.txt 文件中, a.txt 文件中的单词用回车符 分隔, b.txt 文件中用回车或空格进行分隔。

    package cn.itcast; import java.io.File; import java.io.FileReader; import java.io.FileWriter; public ...

  7. 编写一个程序,将a.txt文件中的单词与b.txt文件中的单词交替合并到c.txt文件中,a.txt文件中的单词用回车符分隔,b.txt文件中用回车或空格进行分隔

    package sundemo2; import java.io.File; import java.io.FileReader; import java.io.FileWriter; public ...

  8. 编写一个程序,将 a.txt 文件中的单词与 b.txt 文件中的单词交替合并到 c.txt 文件中,a.txt 文件中的单词用回车符分隔,b.txt 文件中用回车或空格进行分隔。

    package IO; import java.io.*; public class test { public void connectWords(File file1, File file2, F ...

  9. 软件工程-构建之法 WordCount小程序 统计文件中字符串个数,单词个数,词频,行数

    一.前言 在之前写过一个词频统计的C语言课设,别人说你一个大三的怎么写C语言课程,我只想说我是先学习VB,VB是我编程语言的开始,然后接触到C语言及C++:再后来我是学习C++,然后反过来学习C语言, ...

随机推荐

  1. Win7“当前用户没有安装Microsoft Office&quot;

    故障:在win7 win10系统已安装office2007~但打开word excel应用程序时提示"当前用户没有安装Microsoft Office". 原因:office200 ...

  2. 【JAVA、C++】 LeetCode 008 String to Integer (atoi)

    Implement atoi to convert a string to an integer. Hint: Carefully consider all possible input cases. ...

  3. A Multipart Series on Grids in ASP.NET MVC

    A Multipart Series on Grids in ASP.NET MVC Displaying a grid of data is one of the most common tasks ...

  4. 【刷题 Python Tip】题目6~10

    [题目6]输出100以内的所有素数,素数之间以一个空格区分 from math import sqrt print ' '.join(str(key) for key in [x for x in x ...

  5. Asteroids!-裸的BFS

    G - Asteroids! Time Limit:1000MS     Memory Limit:32768KB     64bit IO Format:%I64d & %I64u Subm ...

  6. AtCoder Regular Contest 071

    C - 怪文書 / Dubious Document 题意:定义一种无序的子序列:在原串中随意地取字符并随意打乱顺序.求多个字符串的最长公共无序子序列. #include<cstdio> ...

  7. AppCan移动开发技巧:3步走,获取移动APP签名信息

    大家知道,在移动APP开发里,与应用包名一样,应用的签名信息需是唯一的,否则将会出现应用冒领.重复安装等问题.之前分享过安卓应用的签名如何获取(点击查看),这里将继续以AppCan平台为例,分享如何获 ...

  8. eclipse svn 删除不了项目,合并不了问题

    window/preferences  下  Teme  >svn  svn接口选择跟删除不了有关 但是合并 需要选择 JavaHl svn 服务端 1.8 eclipse选则 http://s ...

  9. Online Resource Mapping for SDN Network Hypervisors using Machine Learning

    发表时间:2016 一些定义: self-configuring networks: FlowVisor: FlowVisor是建立在OpenFlow之上的网络虚拟化工具,它可以将物理网络划分成多个逻 ...

  10. Centos6.5 安装配置docker

    宿主机:win7 64位   vagrant封装环境运行在VirtualBox 虚拟机上CentOS6.5,这是做测试时的一个环境,顺便错用安装docker玩玩.   centos6.5可以直接安装d ...