软件研发的面试,除了架构设计和算法之外,还有一类看似简单的问题,但是也挂了相当一部分人,就是让写一些简单例程,比较典型的是要求实现C的一些库函数,比如我曾碰见让当场写一个strcat,一般只要细心一点,还是比较简单的,不过一般来讲在你写出以后,会有一些后续问题,比如递归改非递归等,有人可能觉得这些问题只是拿来考试的,实践中只要调用现成的库就可以了,实际上,某些C库并没有想象得那么好
memmem是一个C库函数,用于在一块内存中寻找匹配另一块内存的内容的第一个位置,其实本来我想写strstr,后来觉得太麻烦,就直接用memmem了,这个问题的起因是在Python的源码里,看到字符串的find方法没有调用strstr和memmem,而是使用了自己写的一段例程,所以想看看C库的这两个函数是不是真的很烂,环境是linux,gcc
首先是一个比较直观的myMemmem(如果严格一点,长度应该是size_t型,而且要先判断alen和blen的大小关系,以及是否为正整数,这里都省了)
int myMemmem(char * a, int alen, char * b, int blen)
{
int i, j;
for (i = 0; i <= alen – blen; ++ i)
{
for (j = 0; j < blen; ++ j)
{
if (a[i + j] != b[j])
{
break;
}
}
if (j >= blen)
{
return i;
}
}
return -1;
}
然后是一个快速版本myFastMemmem
int myFastMemmem(unsigned char * a, int alen, unsigned char * b, int blen)
{
int tag[256];
int i, ja, jb, match;
for (i = 0; i < 256; ++ i)
{
tag = 0;
}
for (i = 0; i < blen; ++ i)
{
tag[b ] = 1;
}
for (i = 0; ;)
{
for (ja = i + blen – 1, jb = blen – 1, match = 1; jb >= 0; — ja, — jb)
{
if (!tag[a[ja]])
{
i = ja;
match = 0;
break;
}
if (match && a[ja] != b[jb])
{
match = 0;
}
}
if (match)
{
return i;
}
++ i;
}
return -1;
}
解释一下myFastMemmem的算法,构造一个tag表(相当于一个索引),通过这个表可以快速判断一个字符是否存在于b中,然后从头对字符串进行比较,注意是从后往前比哦,如果发现a[ja]不属于b,则立刻跳出当前判断循环,且i可以立刻跳到ja + 1的位置,省去了i和ja + 1之间的这些位置比较,因为这些位置的blen长度内存都包含a[ja],所以肯定不匹配
从后往前比较是为了直接找到最后一个不属于b的a[ja],另外,如果在到达不属于b的a[ja]之前发现不匹配,这里并没有直接break,为的是不错过跳i的机会,当然,也会带来一些坏情况,如果改成break,算法在某些情况下会慢点,但是整体比较稳定
Python源码的方法稍有不同,不是建立了一个256大小的tag,而是用一个32位long来标记,就是把字符分为32组,每组公用一个标志位,相当于myFastMemmem的方法可以明确指出一个字符是否在tag,而Python的方法只能指出一个字符肯定不存在和可能存在,有一定模糊性,而且对于tag有很多位运算,稍微复杂了些,当然,它省了空间,原理其实是一样的
测试结果:
随机生成a和b,alen为1M,blen为50,执行1000次搜索
C库的memmem耗时3.29s
上面的例程结果则跟gcc优化有关
不优化:myMemmem耗时6.84s,myFastMemmem耗时0.26s
O1优化:myMemmem耗时3.88s,myFastMemmem耗时0.18s
O2优化:myMemmem耗时1.41s,myFastMemmem耗时0.18s
O3优化:myMemmem耗时1.42s,myFastMemmem耗时0.18s
可以看出O2和O3差别不大,这点误差不影响实际应用,大部分软件和项目都是O2优化
从myMemmem的程序可以看出,二重循环,运行时间与(alen – blen) * blen有关,因此当blen很小的时候,myMemmem比myFastMemmem要快,当blen比较大的时候,其包含的字符集可能占tag的绝大部分,这时候myFastMemmem同样不占优势,因此,实际应用中可以把两者结合起来使用
至于memmem,可能其他某些实现会比较快,如果涉及到效率相关的问题,最好先简单测试一下
myFastMemmem使用单字节tag,如果改成双字节组和的tag,则blen比较大的时候,速度相对myFastMemmem和myMemmem可以提高近百倍
int myFastMemmem2(unsigned char * a, int alen, unsigned char * b, int blen)
{
int tag[65536];
int i, ja, jb, match;
for (i = 0; i < 65536; ++ i)
{
tag = 0;
}
for (i = 0; i < blen – 1; ++ i)
{
tag[*(unsigned short *)(b + i)] = 1;
}
for (i = 0; i <= alen – blen;)
{
for (ja = i + blen – 1, jb = blen – 1, match = 1; jb >= 0; — ja, — jb)
{
if (jb < blen – 1 && !tag[*(unsigned short *)(a + ja)])
{
i = ja + 1;
match = 0;
break;
}
if (match && a[ja] != b[jb])
{
match = 0;
}
}
if (match)
{
return i;
}
++ i;
}
return -1;
}
最后说明一下,这个问题的经典算法是KMP,复杂度小而且稳定,但是部分数据下绝对时间比这个算法慢,KMP的细节可以参考算法导论
memmem是一个C库函数,用于在一块内存中寻找匹配另一块内存的内容的第一个位置,其实本来我想写strstr,后来觉得太麻烦,就直接用memmem了,这个问题的起因是在Python的源码里,看到字符串的find方法没有调用strstr和memmem,而是使用了自己写的一段例程,所以想看看C库的这两个函数是不是真的很烂,环境是linux,gcc
首先是一个比较直观的myMemmem(如果严格一点,长度应该是size_t型,而且要先判断alen和blen的大小关系,以及是否为正整数,这里都省了)
int myMemmem(char * a, int alen, char * b, int blen)
{
int i, j;
for (i = 0; i <= alen – blen; ++ i)
{
for (j = 0; j < blen; ++ j)
{
if (a[i + j] != b[j])
{
break;
}
}
if (j >= blen)
{
return i;
}
}
return -1;
}
然后是一个快速版本myFastMemmem
int myFastMemmem(unsigned char * a, int alen, unsigned char * b, int blen)
{
int tag[256];
int i, ja, jb, match;
for (i = 0; i < 256; ++ i)
{
tag
}
for (i = 0; i < blen; ++ i)
{
tag[b
}
for (i = 0; ;)
{
for (ja = i + blen – 1, jb = blen – 1, match = 1; jb >= 0; — ja, — jb)
{
if (!tag[a[ja]])
{
i = ja;
match = 0;
break;
}
if (match && a[ja] != b[jb])
{
match = 0;
}
}
if (match)
{
return i;
}
++ i;
}
return -1;
}
解释一下myFastMemmem的算法,构造一个tag表(相当于一个索引),通过这个表可以快速判断一个字符是否存在于b中,然后从头对字符串进行比较,注意是从后往前比哦,如果发现a[ja]不属于b,则立刻跳出当前判断循环,且i可以立刻跳到ja + 1的位置,省去了i和ja + 1之间的这些位置比较,因为这些位置的blen长度内存都包含a[ja],所以肯定不匹配
从后往前比较是为了直接找到最后一个不属于b的a[ja],另外,如果在到达不属于b的a[ja]之前发现不匹配,这里并没有直接break,为的是不错过跳i的机会,当然,也会带来一些坏情况,如果改成break,算法在某些情况下会慢点,但是整体比较稳定
Python源码的方法稍有不同,不是建立了一个256大小的tag,而是用一个32位long来标记,就是把字符分为32组,每组公用一个标志位,相当于myFastMemmem的方法可以明确指出一个字符是否在tag,而Python的方法只能指出一个字符肯定不存在和可能存在,有一定模糊性,而且对于tag有很多位运算,稍微复杂了些,当然,它省了空间,原理其实是一样的
测试结果:
随机生成a和b,alen为1M,blen为50,执行1000次搜索
C库的memmem耗时3.29s
上面的例程结果则跟gcc优化有关
不优化:myMemmem耗时6.84s,myFastMemmem耗时0.26s
O1优化:myMemmem耗时3.88s,myFastMemmem耗时0.18s
O2优化:myMemmem耗时1.41s,myFastMemmem耗时0.18s
O3优化:myMemmem耗时1.42s,myFastMemmem耗时0.18s
可以看出O2和O3差别不大,这点误差不影响实际应用,大部分软件和项目都是O2优化
从myMemmem的程序可以看出,二重循环,运行时间与(alen – blen) * blen有关,因此当blen很小的时候,myMemmem比myFastMemmem要快,当blen比较大的时候,其包含的字符集可能占tag的绝大部分,这时候myFastMemmem同样不占优势,因此,实际应用中可以把两者结合起来使用
至于memmem,可能其他某些实现会比较快,如果涉及到效率相关的问题,最好先简单测试一下
myFastMemmem使用单字节tag,如果改成双字节组和的tag,则blen比较大的时候,速度相对myFastMemmem和myMemmem可以提高近百倍
int myFastMemmem2(unsigned char * a, int alen, unsigned char * b, int blen)
{
int tag[65536];
int i, ja, jb, match;
for (i = 0; i < 65536; ++ i)
{
tag
}
for (i = 0; i < blen – 1; ++ i)
{
tag[*(unsigned short *)(b + i)] = 1;
}
for (i = 0; i <= alen – blen;)
{
for (ja = i + blen – 1, jb = blen – 1, match = 1; jb >= 0; — ja, — jb)
{
if (jb < blen – 1 && !tag[*(unsigned short *)(a + ja)])
{
i = ja + 1;
match = 0;
break;
}
if (match && a[ja] != b[jb])
{
match = 0;
}
}
if (match)
{
return i;
}
++ i;
}
return -1;
}
最后说明一下,这个问题的经典算法是KMP,复杂度小而且稳定,但是部分数据下绝对时间比这个算法慢,KMP的细节可以参考算法导论