100万url找到出现频率最高的100个

shiter
人工智能领域优质创作者
博客专家认证
2015-07-25 01:29:41
加精
一个阿里的面试题,我做着玩下。 第一个迸发的思路是stl,map。用pair插入时候要是已经存在了url,就给后面的index++,完后按照index排序,测试了一下120m的txt应该有两百万左右,五十秒左右得出结果。 http://blog.csdn.net/wangyaninglm/article/details/47049907 url限制最长256个字符, 大家还有没有更好的思路。
...全文
10268 131 打赏 收藏 转发到动态 举报
写回复
用AI写文章
131 条回复
切换为时间正序
请发表友善的回复…
发表回复
列子汤问 2016-04-05
  • 打赏
  • 举报
回复
C++写入文件使用的时间:15.5768 秒 感觉有点长。
xyt8525594 2015-09-04
  • 打赏
  • 举报
回复
还是有些难度~~~~
庚武讲堂 2015-08-23
  • 打赏
  • 举报
回复
Hadoop, MapReduce.
shiter 2015-08-21
  • 打赏
  • 举报
回复
引用 126 楼 xade 的回复:
[quote=引用 123 楼 wangyaninglm 的回复:]劳烦你看看python代码,本身就是正则表达式匹配出来的长度小于256个字符的url,你说说了很多要注意的点,谢谢分享,但是代码呢?
你blog的python代码我看了的,如果你讨论的仅仅是用你的python脚本抓出来的url的话,的确可以不考虑有没有协议前缀的,因为那个脚本根本就没有抓到没有协议前缀的url,或者说那个python脚本给题目加上了一个特化的条件:输入url都符合 ((http|ftp)s?://.*?) 这个正则的格式,这貌似有点改变题目了,或者说没考虑周全? 但是,这个正则仍然没有消除这两种 url 的差别: http://bbs.csdn.net/topics/391080906 http://bbs.csdn.net/////////////////topics////391080906//////////// 前面诸位讨论的算法,如果我没看错的话,貌似没有哪位有将这两种统计为一个的。 另外,我也确实没有听说过有把这两种url处理成不同url的习俗或者大家心照不宣的约定,如果有,那就是我错了,这两种就按两个url来统计,代码还可以更简单一些。 以上是url的格式问题。 另外,在IO效率的方面,前面有几位都提到了,耗时的动作都花在了IO上,这对于研究一个算法的效率来说,会是一个很大的误差。 在实际的生产环境中,如baidu google,或者就阿里,对要进行统计的 url 必然是要保存到数据库的,所以使用数据库会是最接近实际生产环境的方案,前面有位同学已经说了,但是貌似反应不是很大。 在采用数据库的方案中,插入数据的时候就可以对url的格式进行规整,这一点,在实际生产环境中是可行的。 说句狂妄的话,这种题的答案,不是答数据库的必然是嫩鸟,因为思路太狭隘了,而且一眼就能看出缺乏经验。 这种大数据的统计排序工作,大部分的任务是要在数据库内来解决的,外部代码更多是负责逻辑和调度。 另外,有多少人敢声称自己的排序一定能比数据库快? 而且,就算你的算法比数据库快了,算上与数据库交换数据的额外消耗,你还能保证比数据库快吗? 好吧,就算你比数据库更快了。现在你的算法要运用到更大规模的集群上去了,要与MapReduce等机制协同工作,你能保证你的算法在新的环境不出问题吗? 好吧,你有思路有解决方案,经过多次的尝试你终于找到了。 可是隔壁用数据库的人家早就在一周前就完成任务了! 软件是辅助生产的工具,一切都要以最终生产环境的应用为优先,所以数据的量化和任务的量化请一定要在面试的时候考虑到——你是在找工作,不是在解题,对于大多数企业来说,要的不是会造更好的轮子的优等生,而是能给企业带来生产力改进的人才。 虽然待的公司不大,但也是经常面对刚从学校出来找工作的同学们的,甚至还有工作经年的人,遇到的代码狂人也算不少了,所以有了这些认识。 请原谅我用狂妄的语气发言,并不是想做什么炫耀或者秀优越感的事,只是希望这些经验能够给大家带来参考,也帮助真正需要人才的公司能够好招人一点——同学们觉得工作难找,企业觉得人才难招,连续两周面试不到一个合适的人其实作为管理者也是很头痛的事。 最后,lz如果执意需要代码的话,请参考前面 cobra_chen 的答案,我投他一票。[/quote] 非常感谢指导,,你说的很有意义
xade 2015-08-21
  • 打赏
  • 举报
回复
引用 123 楼 wangyaninglm 的回复:
劳烦你看看python代码,本身就是正则表达式匹配出来的长度小于256个字符的url,你说说了很多要注意的点,谢谢分享,但是代码呢?
你blog的python代码我看了的,如果你讨论的仅仅是用你的python脚本抓出来的url的话,的确可以不考虑有没有协议前缀的,因为那个脚本根本就没有抓到没有协议前缀的url,或者说那个python脚本给题目加上了一个特化的条件:输入url都符合 ((http|ftp)s?://.*?) 这个正则的格式,这貌似有点改变题目了,或者说没考虑周全? 但是,这个正则仍然没有消除这两种 url 的差别: http://bbs.csdn.net/topics/391080906 http://bbs.csdn.net/////////////////topics////391080906//////////// 前面诸位讨论的算法,如果我没看错的话,貌似没有哪位有将这两种统计为一个的。 另外,我也确实没有听说过有把这两种url处理成不同url的习俗或者大家心照不宣的约定,如果有,那就是我错了,这两种就按两个url来统计,代码还可以更简单一些。 以上是url的格式问题。 另外,在IO效率的方面,前面有几位都提到了,耗时的动作都花在了IO上,这对于研究一个算法的效率来说,会是一个很大的误差。 在实际的生产环境中,如baidu google,或者就阿里,对要进行统计的 url 必然是要保存到数据库的,所以使用数据库会是最接近实际生产环境的方案,前面有位同学已经说了,但是貌似反应不是很大。 在采用数据库的方案中,插入数据的时候就可以对url的格式进行规整,这一点,在实际生产环境中是可行的。 说句狂妄的话,这种题的答案,不是答数据库的必然是嫩鸟,因为思路太狭隘了,而且一眼就能看出缺乏经验。 这种大数据的统计排序工作,大部分的任务是要在数据库内来解决的,外部代码更多是负责逻辑和调度。 另外,有多少人敢声称自己的排序一定能比数据库快? 而且,就算你的算法比数据库快了,算上与数据库交换数据的额外消耗,你还能保证比数据库快吗? 好吧,就算你比数据库更快了。现在你的算法要运用到更大规模的集群上去了,要与MapReduce等机制协同工作,你能保证你的算法在新的环境不出问题吗? 好吧,你有思路有解决方案,经过多次的尝试你终于找到了。 可是隔壁用数据库的人家早就在一周前就完成任务了! 软件是辅助生产的工具,一切都要以最终生产环境的应用为优先,所以数据的量化和任务的量化请一定要在面试的时候考虑到——你是在找工作,不是在解题,对于大多数企业来说,要的不是会造更好的轮子的优等生,而是能给企业带来生产力改进的人才。 虽然待的公司不大,但也是经常面对刚从学校出来找工作的同学们的,甚至还有工作经年的人,遇到的代码狂人也算不少了,所以有了这些认识。 请原谅我用狂妄的语气发言,并不是想做什么炫耀或者秀优越感的事,只是希望这些经验能够给大家带来参考,也帮助真正需要人才的公司能够好招人一点——同学们觉得工作难找,企业觉得人才难招,连续两周面试不到一个合适的人其实作为管理者也是很头痛的事。 最后,lz如果执意需要代码的话,请参考前面 cobra_chen 的答案,我投他一票。
line_us 2015-08-21
  • 打赏
  • 举报
回复
真的想知道该怎么弄,不编程行不行
赵4老师 2015-08-21
  • 打赏
  • 举报
回复
无profiler不要谈效率!!尤其在这个云计算、虚拟机、模拟器、CUDA、多核 、多级cache、指令流水线、多种存储介质、……满天飞的时代!
shiter 2015-08-21
  • 打赏
  • 举报
回复
引用 122 楼 xade 的回复:
[quote=引用 112 楼 qaqz111 的回复:] 貌似都没有提 url 的格式问题? http://bbs.csdn.net/topics/391080906 http://bbs.csdn.net/topics/391080906/ http://bbs.csdn.net/topics//391080906 http://bbs.csdn.net/////////////////topics////391080906//////////// bbs.csdn.net/topics/391080906 bbs.csdn.net/topics/391080906/ bbs.csdn.net//topics/391080906/ bbs.csdn.net//////////////topics///391080906//////////// 这些写法复制到浏览器地址栏试试? 虽然/出现得太多的情况很少,但是连着两个/的还是比较常见的,对于有意义的统计数据来说,这些url格式应该全部都被规整到第一种写法。 所以,这个url的问题,其实前面讨论的都是针对字符串的统计,而不是url。按我对题目的理解,ls诸位的思路吧url和单纯的字符串等同了是在思路上有缺失的,如果出现另一个考虑到这种情况的,很显然会是更好的解决方案。
这个才是重点好不好?沉溺到算法和优化的细节里面是学生党和代码狂人最大的毛病,完全无视实际应用中遇到的情况,结果写出来的东西最后上机跑的时候发现只能应对一小部分情况,大部分被疏漏了,然后又下来来来回回的改。 解决问题多关注问题本身,不要光纠缠细节,很多时候解决问题的细节都不止一种而且不止一面,不然人家给你的问题为什么不干脆说数百万字符串的统计而要说是 url 的统计? 你们讨论的那些有n种实现方法,而且根据不同的数据量和服务器架构和剩余可用资源以及任务的优先度都可能采取不同的策略,前面讨论的那些方法在实际生产中,在最上面还要加一个调度器才是最符合生产力要求的做法。[/quote] 劳烦你看看python代码,本身就是正则表达式匹配出来的长度小于256个字符的url,你说说了很多要注意的点,谢谢分享,但是代码呢?
xade 2015-08-19
  • 打赏
  • 举报
回复
引用 112 楼 qaqz111 的回复:
貌似都没有提 url 的格式问题? http://bbs.csdn.net/topics/391080906 http://bbs.csdn.net/topics/391080906/ http://bbs.csdn.net/topics//391080906 http://bbs.csdn.net/////////////////topics////391080906//////////// bbs.csdn.net/topics/391080906 bbs.csdn.net/topics/391080906/ bbs.csdn.net//topics/391080906/ bbs.csdn.net//////////////topics///391080906//////////// 这些写法复制到浏览器地址栏试试? 虽然/出现得太多的情况很少,但是连着两个/的还是比较常见的,对于有意义的统计数据来说,这些url格式应该全部都被规整到第一种写法。 所以,这个url的问题,其实前面讨论的都是针对字符串的统计,而不是url。按我对题目的理解,ls诸位的思路吧url和单纯的字符串等同了是在思路上有缺失的,如果出现另一个考虑到这种情况的,很显然会是更好的解决方案。
这个才是重点好不好?沉溺到算法和优化的细节里面是学生党和代码狂人最大的毛病,完全无视实际应用中遇到的情况,结果写出来的东西最后上机跑的时候发现只能应对一小部分情况,大部分被疏漏了,然后又下来来来回回的改。 解决问题多关注问题本身,不要光纠缠细节,很多时候解决问题的细节都不止一种而且不止一面,不然人家给你的问题为什么不干脆说数百万字符串的统计而要说是 url 的统计? 你们讨论的那些有n种实现方法,而且根据不同的数据量和服务器架构和剩余可用资源以及任务的优先度都可能采取不同的策略,前面讨论的那些方法在实际生产中,在最上面还要加一个调度器才是最符合生产力要求的做法。
super_admi 2015-08-19
  • 打赏
  • 举报
回复
不用上了,是我考虑错了。这些天状态不对,一回复完就知道自己错了。
引用 113 楼 wangyaninglm 的回复:
[quote=引用 111 楼 super_admi 的回复:] 按我的想法,我们只需要建立两张表就可以了: 1.一张hashmap,用途:统计表,记录每个url出现的频率; 2.一张pair<int, string>[100],用途:排行榜,记录频率最高的100个url; 每提取一条url,首先,进行统计,因为是hash,应该很快,对吧?然后,扫描一遍排行榜,找到此url的位置,依次往后刷。最坏的情况,操作100万*100次,很明确吧?
上代码学习一下![/quote]
小木鱼%2345 2015-08-19
  • 打赏
  • 举报
回复
引用 49 楼 zjq9931 的回复:
小于10秒的,不知道是怎么办到的? 我写了个程序生成了100万条记录文件 生成 100万条记录 使用的时间:11.3155 秒(生成的方法不够好?) C写入文件使用的时间:1.93822 秒(fwrite) C++写入文件使用的时间:15.5768 秒 (ofstream<<buffer不知道有没有更好的办法) 用数据库的有没计算进去导入数据库的时间? 用哈希表的有没有计算进去读入内存的时间? 后面我再写找出频率最高的100条的代码,先附上生成代码,各位评评哪里还可以优化的。。。 代码如下:

#include <iostream>
#include <fstream>
#include <cstdlib>
#include <string>

#include <windows.h>
using namespace std;

int main()
{
	LONGLONG start_time;
	LONGLONG end_time;
	LONGLONG frequency;
	LONGLONG elapsed;
	double elapsed_time;

	char *file = new char[256*100*10000];
	char *pc;
	pc=file;

	QueryPerformanceFrequency((LARGE_INTEGER*)&frequency);
	QueryPerformanceCounter((LARGE_INTEGER*)&start_time);
	srand(1000000);
	char url[256];
	int ilen;
	string str;
	for(int i=0; i<1000000; i++)
	{
		int iRand = rand()%10000;
		sprintf(url, "%c,%c,%d,%08x,%08X,", iRand%26+'A',iRand%26+'a',iRand,iRand,iRand,iRand);
		str=url;
		ilen = sprintf(url, "%s,%s,%s,%s,%s,%s,%s,%s,\r\n", str.c_str(),str.c_str(),str.c_str(),str.c_str(),str.c_str(),str.c_str(),str.c_str(),str.c_str());
		memcpy(pc, url, ilen);
		pc+=ilen;
	}
	*pc='\0';
	QueryPerformanceCounter((LARGE_INTEGER*)&end_time);
	elapsed = end_time - start_time;
	elapsed_time = (double)elapsed/frequency;
	cout << "生成 100万条记录 使用的时间:" << elapsed_time << " 秒" << "\r\n" << endl;
	cout << "\r\n" << endl;

	QueryPerformanceCounter((LARGE_INTEGER*)&start_time);
	FILE  *pflOut = fopen("milion_record2.txt", "wb");
	fwrite(file, pc-file, 1, pflOut);
	fclose(pflOut);

	QueryPerformanceCounter((LARGE_INTEGER*)&end_time);
	elapsed = end_time - start_time;
	elapsed_time = (double)elapsed/frequency;
	cout << "C写入文件使用的时间:" << elapsed_time << " 秒" << "\r\n" << endl;

	QueryPerformanceCounter((LARGE_INTEGER*)&start_time);
	ofstream outfile("milion_record.txt");
	outfile << file;
	outfile.close();

	QueryPerformanceCounter((LARGE_INTEGER*)&end_time);
	elapsed = end_time - start_time;
	elapsed_time = (double)elapsed/frequency;
	cout << "C++写入文件使用的时间:" << elapsed_time << " 秒" << "\r\n" << endl;
	return 0;
}
导入数据库这个时间肯定不计算时间,所以感觉这个比较优越性也不太好比较。。。除非在数据全部都读取,并且都加载到内存,才开始计时。。。
fly_dragon_fly 2015-08-19
  • 打赏
  • 举报
回复
引用 109 楼 wangyaninglm 的回复:
[quote=引用 108 楼 fly_dragon_fly 的回复:] [quote=引用 106 楼 wangyaninglm 的回复:] [quote=引用 13 楼 fly_dragon_fly 的回复:] 想了下,没试过, 如下
struct info{
    string url;
    int cnt;
    bool operator<(const info &r) const {
        return cnt>r.cnt;
    }
};
unordered_map<string,int> count;
    priority_queue<info> pq;
cout直接用来计数,判断是否需要压入pq, pq为小顶堆,最多只要100个元素即可
[/quote] 测试一下慢在那里, find的参数改成引用
void find_largeTH(unordered_map<string,int> &urlhash)
{
    for(auto &item : urlhash){
        pq.push({item.first,item.second});
        if(pq.size()>100) pq.pop();
    }
}

void insertUrl(string url)
{
    ++hash_url[url];
}
[/quote] 大神你太犀利了,那个insertUrl函数你改成一行代码后好了很多啊,为啥呢? 我的vs2010好像不支持auto关键字,所以没用你排序部分的代码,速度快了很多啊。

// urlFind.cpp : 定义控制台应用程序的入口点。
//

// sortUrl.cpp : 定义控制台应用程序的入口点。
//

#include "stdafx.h"
 
#include <vector>
#include <map>
#include <fstream>
#include <iostream>
#include <string>
#include <algorithm>
#include <unordered_map>
#include <queue>
#include "ComputeTime.h"

using namespace std;


typedef pair<string, int> PAIR;


struct info
{
	string url;
	int cnt;
	bool operator<(const info &r) const
	{
		return cnt<r.cnt;
	}
};


unordered_map<string,int> hash_url;

priority_queue<info> pq;

//
//
void find_largeTH(unordered_map<string,int> &urlhash)
{

	unordered_map<string,int>::iterator iter = urlhash.begin();
	info temp;
	for (; iter!= urlhash.end();++iter)
	{
		temp.url = iter->first;
		temp.cnt = iter->second;
		pq.push(temp);
	}

	for (int i = 0; i != 100; ++i) 
	{

		cout<<pq.top().url<<endl;
		cout<<pq.top().cnt<<endl;
		pq.pop();
	}
}

//void find_largeTH(unordered_map<string,int> &urlhash)
//{
//	for(auto& item : urlhash)
//	{
//		pq.push(item.first,item.second);
//		if(pq.size()>100) pq.pop();
//	}
//}

void insertUrl(string url)
{
	++hash_url[url];
}

//void insertUrl(string url)
//{
//
//	pair<unordered_map<string ,int>::iterator, bool> Insert_Pair;
//	Insert_Pair = hash_url.insert(unordered_map<string, int>::value_type(url,1));
//
//	if (Insert_Pair.second == false)
//	{
//		(Insert_Pair.first->second++);
//	}
//
//}

int _tmain(int argc, _TCHAR* argv[])
{
	fstream URLfile;
	char buffer[1024]; 
	URLfile.open("url.txt",ios::in|ios::out|ios::binary);

	if (! URLfile.is_open())  
	{ cout << "Error opening file"; exit (1); } 
	else
	{
		cout<<"open file success!"<<endl;
	}

	ComputeTime cp;
	cp.Begin();
	int i = 0;
	while (!URLfile.eof())  
	{  
		URLfile.getline (buffer,1024);  
		//cout << buffer << endl;  
		string temp(buffer);
		//cout<<i++<<endl;
		insertUrl(temp);
	}  
	double insert_time = cp.End();
	
	cp.Begin();
	find_largeTH(hash_url);
	double sort_time = cp.End();

	cout<<"insert running time: "<<insert_time<<"ms"<<endl;
	cout<<"sort running time: "<<sort_time<<"ms"<<endl;
	cout<<"running time: "<<insert_time + sort_time<<"ms"<<endl;

	getchar();
	//system("pause");
	return 0;
}




[/quote] 在url统计中没必要构造pair和iterator, 我认为这里还是有性能损耗的, 当然你可以在网上找个其它hash的方法替换unordered_map中的hash试一下.
shiter 2015-08-19
  • 打赏
  • 举报
回复
引用 120 楼 super_admi 的回复:
进一步使用1G多,500万条URL测试: 我发现getline这个地方,耗时很多,不做任何处理,只getline,大约需要7-9秒。楼主你还要建堆什么的,约在13秒左右--所以,后面的排序貌似没耗费多少时间?? 15秒有大约一半多的时候在getline,大家讨论的排序什么的,还有多大意义?我看还不如研究怎么快速读txt。即使楼主使用二进制方式来读txt,我觉得它并不是一次就加载进了内存中,而是在getline中逐步加载。IO操作是很耗时的,so,楼主你觉得你测出的时间,有多少水分?
有道理,所以我想之前有人说,做内存,文件映射这块的思路,主要就是探讨一下此类问题的思路,最近毕业找工作面试呢,哈哈
shiter 2015-08-19
  • 打赏
  • 举报
回复
引用 111 楼 super_admi 的回复:
按我的想法,我们只需要建立两张表就可以了: 1.一张hashmap,用途:统计表,记录每个url出现的频率; 2.一张pair<int, string>[100],用途:排行榜,记录频率最高的100个url; 每提取一条url,首先,进行统计,因为是hash,应该很快,对吧?然后,扫描一遍排行榜,找到此url的位置,依次往后刷。最坏的情况,操作100万*100次,很明确吧?
上代码学习一下!
super_admi 2015-08-19
  • 打赏
  • 举报
回复
进一步使用1G多,500万条URL测试: 我发现getline这个地方,耗时很多,不做任何处理,只getline,大约需要7-9秒。楼主你还要建堆什么的,约在13秒左右--所以,后面的排序貌似没耗费多少时间?? 15秒有大约一半多的时候在getline,大家讨论的排序什么的,还有多大意义?我看还不如研究怎么快速读txt。即使楼主使用二进制方式来读txt,我觉得它并不是一次就加载进了内存中,而是在getline中逐步加载。IO操作是很耗时的,so,楼主你觉得你测出的时间,有多少水分?
super_admi 2015-08-19
  • 打赏
  • 举报
回复
楼主你的代码在我的机器上测试了下,200多M,100万条URL的txt文件,整个程序运行耗时约3秒,所以我提升到了1G多,500万条URL,耗时15秒左右。 由此带来的问题是:我不好再继续优化了--1秒两秒的,实在提不起兴趣。
shiter 2015-08-19
  • 打赏
  • 举报
回复
引用 117 楼 worldy 的回复:
[quote=引用 6 楼 wangyaninglm 的回复:] [quote=引用 5 楼 zilaishuichina 的回复:] 分治 可以把100w个url分成1w个一组, 对1w个url求top100,无论是内存的消耗,还是排序时间,应该相对来说都比直接对100w个url做排序要快 这样就可以得到100个top100, 然后对这100个top100做合并求最终的top100
分治 的话,怎么能够保证,出来的100个就是频率最高的呢?我觉得这块是个难点[/quote] 不是说了,每组都取前100个,这样,哪个都跑不了 但我感觉不应该分10000个一组,应该分1000000^0.5为一组,是不是更好?[/quote] 大牛有没有兴趣,写点代码,嘿嘿黑
worldy 2015-08-19
  • 打赏
  • 举报
回复
引用 6 楼 wangyaninglm 的回复:
[quote=引用 5 楼 zilaishuichina 的回复:] 分治 可以把100w个url分成1w个一组, 对1w个url求top100,无论是内存的消耗,还是排序时间,应该相对来说都比直接对100w个url做排序要快 这样就可以得到100个top100, 然后对这100个top100做合并求最终的top100
分治 的话,怎么能够保证,出来的100个就是频率最高的呢?我觉得这块是个难点[/quote] 不是说了,每组都取前100个,这样,哪个都跑不了 但我感觉不应该分10000个一组,应该分1000000^0.5为一组,是不是更好?
qaqz111 2015-08-19
  • 打赏
  • 举报
回复
貌似都没有提 url 的格式问题? http://bbs.csdn.net/topics/391080906 http://bbs.csdn.net/topics/391080906/ http://bbs.csdn.net/topics//391080906 http://bbs.csdn.net/////////////////topics////391080906//////////// bbs.csdn.net/topics/391080906 bbs.csdn.net/topics/391080906/ bbs.csdn.net//topics/391080906/ bbs.csdn.net//////////////topics///391080906//////////// 这些写法复制到浏览器地址栏试试? 虽然/出现得太多的情况很少,但是连着两个/的还是比较常见的,对于有意义的统计数据来说,这些url格式应该全部都被规整到第一种写法。 所以,这个url的问题,其实前面讨论的都是针对字符串的统计,而不是url。按我对题目的理解,ls诸位的思路吧url和单纯的字符串等同了是在思路上有缺失的,如果出现另一个考虑到这种情况的,很显然会是更好的解决方案。
super_admi 2015-08-18
  • 打赏
  • 举报
回复
按我的想法,我们只需要建立两张表就可以了: 1.一张hashmap,用途:统计表,记录每个url出现的频率; 2.一张pair<int, string>[100],用途:排行榜,记录频率最高的100个url; 每提取一条url,首先,进行统计,因为是hash,应该很快,对吧?然后,扫描一遍排行榜,找到此url的位置,依次往后刷。最坏的情况,操作100万*100次,很明确吧?
加载更多回复(109)

64,646

社区成员

发帖
与我相关
我的任务
社区描述
C++ 语言相关问题讨论,技术干货分享,前沿动态等
c++ 技术论坛(原bbs)
社区管理员
  • C++ 语言社区
  • encoderlee
  • paschen
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
  1. 请不要发布与C++技术无关的贴子
  2. 请不要发布与技术无关的招聘、广告的帖子
  3. 请尽可能的描述清楚你的问题,如果涉及到代码请尽可能的格式化一下

试试用AI创作助手写篇文章吧