LeetCode 14. 最长公共前缀
编写一个函数来查找字符串数组中的最长公共前缀。
如果不存在公共前缀,返回空字符串 “”。
示例 1:
输入: [“flower”,“flow”,“flight”]
输出: “fl”
示例 2:
输入: [“dog”,“racecar”,“car”]
输出: “”
解释: 输入不存在公共前缀。
说明:
所有输入只包含小写字母 a-z 。
- 解题思路
对于像【s1,s2,s3…sn】n组字符串,我们可以先比较【s1,s2】,找到他们的最长公共前缀Max,然后再比较【Max,s3】,找到他们的最长公共前缀,以此类推,直到遍历所有。 - 代码
class Solution {
public:
string longestCommonPrefix(vector<string>& strs) {
if (!strs.size())return "";
string Maxtarget =strs[0];//最大公共前缀初始值设为第一个字符串
for(int i=1;i<strs.size();i++)
{
Maxtarget=TwoMaxtargat(Maxtarget,strs[i]);
}
return Maxtarget;
}
string TwoMaxtargat(string s1,string s2)
{
string Max=s1;
int i;
for(i=0;i<s1.length()&&i<s2.length();i++)
{
if(s1[i]==s2[i])Max[i]=s1[i];
else break;
}
Max[i]='\0';
return Max;
}
};
- 答案分析
时间复杂度O(n*m),n表示有多少字符串,m表示最长字符串的位数。 - 问题分析
1.在最长的思路中,是纵向扫描法,即比较每个字符串的【0】元素,如果相等就进行比较下一个,以此类推,直到元素不相等,就返回之前相等的所有元素。结果运行时间过长。
2.之后看了解析,发现可以用横向扫描法,即当前所用方法。但是在第一次提交时发现,如果传入的是空指针就会发现错误。
然后添加了一行代码if(strs==NUll)return “”
编译不通过。发现传进来的参数为vector,要用strs.size()==NULL
。
3.现在还存在一个问题 : TwoMaxtargat函数返回的string字符串的长度会大于查找到的公共前缀字符串长度。
(但是不知道为什么程序还是通过了)
#include <iostream>
using namespace std;
string TwoMaxtargat(string s1,string s2);
int main()
{
string s1="aaaaaaaa",s2="aaa";
string s3=TwoMaxtargat(s1,s2);
cout<<s3;
}
string TwoMaxtargat(string s1,string s2)
{
string Max=s1;
int i;
for(i=0;i<s1.length()&&i<s2.length();i++)
{
if(s1[i]==s2[i])Max[i]=s1[i];
else break;
}
Max[i]='\0';
return Max;
}
预想中输出的应该是aaa
但是结果却是aaa aaaa。
在网上找了一下,发现这是因为string字符串有个方法length它的大小决定了字符串的长度。我在程序中想改变他的值,发生了错误。
对于这个问题,我有一个想法
int i;
for(i=0;i<s3.length();i++)
{
if(s3[i]=='\0')
{
break;
}
}
char *a=new char[i];
for(int j=0;j<i;j++)
{
a[j]=s3[j];
}
cout<<a;
可以先遍历字符串,查看一下在 \ 0 之前有几i个元素,然后创建一个长度为i的字符数组,然后输出。
然后我对源程序进行修改,进行提交发生错误
=================================================================
30ERROR: AddressSanitizer: heap-buffer-overflow on address 0x602000000072 at pc 0x7f4d23c88090 bp 0x7ffd18cb8190 sp 0x7ffd18cb7940
READ of size 3 at 0x602000000072 thread T0
#0 0x7f4d23c8808f (/usr/local/lib64/libasan.so.5+0x9508f)
#2 0x7f4d222b72e0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202e0)
0x602000000072 is located 0 bytes to the right of 2-byte region [0x602000000070,0x602000000072)
allocated by thread T0 here:
#0 0x7f4d23cdcea0 in operator new[](unsigned long) (/usr/local/lib64/libasan.so.5+0xe9ea0)
#2 0x7f4d222b72e0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202e0)
SUMMARY: AddressSanitizer: heap-buffer-overflow (/usr/local/lib64/libasan.so.5+0x9508f)
Shadow bytes around the buggy address:
0x0c047fff7fb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c047fff7fc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c047fff7fd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c047fff7fe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0c047fff7ff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x0c047fff8000: fa fa fd fa fa fa fd fa fa fa fd fa fa fa[02]fa
0x0c047fff8010: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c047fff8020: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c047fff8030: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c047fff8040: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x0c047fff8050: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
30ABORTING
??????无能为力了,感觉应该是读写地址时出现错误吧。。。。。