C++之基于正倒排索引的Boost搜索引擎项目usuallytool部分代码及详解

C++之基于正倒排索引的Boost搜索引擎项目usuallytool部分代码及详解
这部分是通用工具部分的代码,简单来说就是这份代码里面的函数会在项目的其他多个部分里面被使用,所以我们专门创建一个部分用来存储这些代码。

1.FileUtil

这个类就是专门用来读取文件用的,这个代码从指定的文件路径读取文件内容,将读取到的内容(按行读取)追加到传入的字符串指针(out)所指向的字符串中;同时,该方法会返回一个布尔值,用于标识读取操作是否成功 —— 若文件成功打开并完成读取,返回 true;若文件打开失败(如路径错误等),则输出错误信息并返回 false。

文件以二进制输入模式打开,读取过程中不会修改原文件内容。

class FileUtil{ public: static bool ReadFile(const std::string &file_path,std::string *out) { //下面这行代码就是在打开文件,并通过ifstream定义一个对象in,用于关联特定的文件 std::ifstream in(file_path,std::ios::in | std::ios::binary); //这两边的in不是同一个东西,前面那个in用于关联特定的文件 //后面那个in是指定文件的打开方式,表示 "以输入模式打开文件"(即只读模式) if(!in.is_open())//这边判断文件是否打开,没打开就退出 { std::cout<<"open file "<<file_path<<": error"<<std::endl; return false; } //while里面要求是bool类型,然后getline的返回类型是输入流引用 //但在实际使用中能当作 bool 类型来使用,因为重载了 bool 类型转换操作符。 //简单来说就是要bool的地方C++会尝试转换成bool类型 std::string line; while(std::getline(in,line)) *out+=line;//把file_path的内容添加到out里面 //in 的只读特性限制的是 “不能写原文件”,而*out+=line并没有试图修改原文件 in.close();//关闭文件 return true; } };

2.JiebaUsutl

这边的话我们是相当于套皮,就是jieba这个非标准库里面有用来分词的函数,然后我们相当于是把那个函数的路径给拿出来,然后通过调用这几个路径里面的构造函数来初始化一个jieba的类,然后我们通过CutString来调用实例化后的jieba类里面的CutForSearcher来实现分词。

为什么我们要加static 呢?

1. 对于静态成员变量jieba

cppjieba::Jieba对象的初始化依赖词典文件,初始化成本较高,且分词功能通常只需要一个实例即可满足需求。用static修饰后,jieba成为类级别的成员,整个程序运行期间只会被初始化一次,避免了重复创建对象带来的资源消耗和冗余操作。确保所有使用JiebaUsutl类进行分词的地方,都共享同一个jieba实例,保证分词逻辑和词典数据的一致性。

2. 对于静态成员函数CutString

该函数的功能是调用jieba的分词方法,而jieba是静态成员(属于类本身),不需要依赖JiebaUsutl的具体实例即可访问。因此,CutStringstatic修饰后,可以直接通过类名(如JiebaUsutl::CutString)调用,无需先创建JiebaUsutl对象,简化了使用方式。

const char* const DICT_PATH = "test/cppjieba/dict/jieba.dict.utf8"; const char* const HMM_PATH = "test/cppjieba/dict/hmm_model.utf8"; const char* const USER_DICT_PATH = "test/cppjieba/dict/user.dict.utf8"; const char* const IDF_PATH = "test/cppjieba/dict/idf.utf8"; const char* const STOP_WORD_PATH = "test/cppjieba/dict/stop_words.utf8"; //test/cppjieba/test这个路径就是那个分词的函数所在的位置 class JiebaUsutl{//这边就是通过cpppjieba里面的分词来进行分词 private: static cppjieba::Jieba jieba; public: static void CutString(const std::string& src,std::vector<std::string>* out) { jieba.CutForSearch(src,*out);//这个CutForSearch就是cppjieba里面的函数 } }; cppjieba::Jieba JiebaUsutl::jieba(DICT_PATH,HMM_PATH,USER_DICT_PATH,IDF_PATH,STOP_WORD_PATH); //对类 JiebaUsutl 中的静态成员 jieba 进行初始化。 //传入几个词典相关的路径(DICT_PATH、HMM_PATH 等),就是调用 Jieba 的构造函数,用这些路径来初始化 JiebaUsutl 类里的静态成员 jieba。 //这样,在后续使用 JiebaUsutl::CutString 方法时,jieba 这个静态对象已经被正确初始化,可以调用其 CutForSearch 方法来进行分词操作了。

3. 总结

以下就是usuallytool部分的完整代码,基本上来说我们只要写项目那就肯定是需要一份usuallytool的。

#pragma once #include<iostream> #include<string> #include<fstream> #include<boost/algorithm/string.hpp> #include"cppjieba/Jieba.hpp" namespace ns_util{ class FileUtil{ public: static bool ReadFile(const std::string &file_path,std::string *out) { //下面这行代码就是在打开文件,并通过ifstream定义一个对象in,用于关联特定的文件 std::ifstream in(file_path,std::ios::in | std::ios::binary); //这两边的in不是同一个东西,前面那个in用于关联特定的文件 //后面那个in是指定文件的打开方式,表示 "以输入模式打开文件"(即只读模式) if(!in.is_open())//这边判断文件是否打开,没打开就退出 { std::cout<<"open file "<<file_path<<": error"<<std::endl; return false; } //while里面要求是bool类型,然后getline的返回类型是输入流引用 //但在实际使用中能当作 bool 类型来使用,因为重载了 bool 类型转换操作符。 //简单来说就是要bool的地方C++会尝试转换成bool类型 std::string line; while(std::getline(in,line)) *out+=line;//把file_path的内容添加到out里面 //in 的只读特性限制的是 “不能写原文件”,而*out+=line并没有试图修改原文件 in.close();//关闭文件 return true; } }; class StringUtil{ public: //target是要切分的目标,out是最后把结果输入到里面,sep是分隔符(\3) static void Split(const std::string& target,std::vector<std::string>* out,std::string sep) { boost::split(*out,target,boost::is_any_of(sep),boost::token_compress_on); //split这个函数就是用来对字符串做切分的 //token_compress_on表示会把连续的“\3”合并成一个 } }; const char* const DICT_PATH = "test/cppjieba/dict/jieba.dict.utf8"; const char* const HMM_PATH = "test/cppjieba/dict/hmm_model.utf8"; const char* const USER_DICT_PATH = "test/cppjieba/dict/user.dict.utf8"; const char* const IDF_PATH = "test/cppjieba/dict/idf.utf8"; const char* const STOP_WORD_PATH = "test/cppjieba/dict/stop_words.utf8"; //test/cppjieba/test这个路径就是那个分词的函数所在的位置 class JiebaUsutl{//这边就是通过cpppjieba里面的分词来进行分词 private: static cppjieba::Jieba jieba; public: static void CutString(const std::string& src,std::vector<std::string>* out) { jieba.CutForSearch(src,*out);//这个CutForSearch就是cppjieba里面的函数 } }; cppjieba::Jieba JiebaUsutl::jieba(DICT_PATH,HMM_PATH,USER_DICT_PATH,IDF_PATH,STOP_WORD_PATH); //对类 JiebaUsutl 中的静态成员 jieba 进行初始化。 //传入几个词典相关的路径(DICT_PATH、HMM_PATH 等),就是调用 Jieba 的构造函数,用这些路径来初始化 JiebaUsutl 类里的静态成员 jieba。 //这样,在后续使用 JiebaUsutl::CutString 方法时,jieba 这个静态对象已经被正确初始化,可以调用其 CutForSearch 方法来进行分词操作了。 }; 

Read more

DeepSeek各版本说明与优缺点分析_deepseek各版本区别

DeepSeek各版本说明与优缺点分析 DeepSeek是最近人工智能领域备受瞩目的一个语言模型系列,其在不同版本的发布过程中,逐步加强了对多种任务的处理能力。本文将详细介绍DeepSeek的各版本,从版本的发布时间、特点、优势以及不足之处,为广大AI技术爱好者和开发者提供一份参考指南。 1. DeepSeek-V1:起步与编码强劲 DeepSeek-V1是DeepSeek的起步版本,这里不过多赘述,主要分析它的优缺点。 发布时间: 2024年1月 特点: DeepSeek-V1是DeepSeek系列的首个版本,预训练于2TB的标记数据,主打自然语言处理和编码任务。它支持多种编程语言,具有强大的编码能力,适合程序开发人员和技术研究人员使用。 优势: * 强大编码能力:支持多种编程语言,能够理解和生成代码,适合开发者进行自动化代码生成与调试。 * 高上下文窗口:支持高达128K标记的上下文窗口,能够处理较为复杂的文本理解和生成任务。 缺点: * 多模态能力有限:该版本主要集中在文本处理上,缺少对图像、语音等多模态任务的支持。 * 推理能力较弱:尽管在自然语言

By Ne0inhk
【DeepSeek应用】100个 DeepSeek 官方推荐的工具箱

【DeepSeek应用】100个 DeepSeek 官方推荐的工具箱

【DeepSeek应用】Deepseek R1 本地部署(Ollama+Docker+OpenWebUI) 【DeepSeek应用】DeepSeek 搭建个人知识库(Ollama+CherryStudio) 【DeepSeek应用】100个 DeepSeek 官方推荐的工具箱 【DeepSeek应用】Zotero+Deepseek 阅读与分析文献 【DeepSeek应用】100个 DeepSeek 官方推荐的工具箱 * 1. DeepSeek 工具箱:应用程序 * 2. DeepSeek 工具箱:AI Agent 框架 * 3. DeepSeek 工具箱:RAG 框架 * 4. DeepSeek 工具箱:即时通讯软件 * 5. DeepSeek 工具箱:浏览器插件 * 6. DeepSeek 工具箱:

By Ne0inhk
“现在的AI就像1880年的笨重工厂!”微软CSO斯坦福泼冷水:别急着造神

“现在的AI就像1880年的笨重工厂!”微软CSO斯坦福泼冷水:别急着造神

大模型仍未对上商业的齿轮? 编译 | 王启隆 来源 | youtu.be/aWqfH0aSGKI 出品丨AI 科技大本营(ID:rgznai100) 现在的硅谷,空气里都飘着一股“再不上车就晚了”的焦躁感。 最近 OpenClaw 风头正旺,强势登顶 GitHub,终结了 React 神话,许多人更是觉得“AI 自己干活赚钱”的日子就在明天了。 特别是在斯坦福商学院(GSB)这种地方,台下坐着的都是成天琢磨怎么用下一个技术风口搞个独角兽出来的狠人。 微软的首席科学官(CSO)Eric Horvitz 被请到了这个几乎全美最想用 AI 变现的礼堂里。作为从上世纪 80 年代就开始搞 AI 的绝对老炮、也是微软技术底座的“扫地僧”,这位老哥并没有顺着台下的胃口,去吹捧下个月大模型又要颠覆什么行业,而是兜头给大家浇了一盆带点学术味的冷水。 他讲了一个挺有画面感的比喻:大家都在聊

By Ne0inhk
Godot被AI代码“围攻”!维护者崩溃发声:“不知道还能坚持多久”

Godot被AI代码“围攻”!维护者崩溃发声:“不知道还能坚持多久”

整理 | 郑丽媛 出品 | ZEEKLOG(ID:ZEEKLOGnews) 当大模型能在几秒钟内生成一段“看起来像那么回事”的补丁时,开源社区却开始付出另一种代价。 最近,开源游戏引擎 Godot 的核心维护团队公开吐槽:他们正被大量“AI 生成的低质量代码”淹没。那些代码往往结构完整、注释齐全、描述洋洋洒洒,但真正的问题是——提交者可能并不理解自己交上来的内容。 这件事,并不是简单的“有人偷懒用 AI 写代码”。它正在触及开源协作最核心的东西:信任。 一场悄无声息的“AI 洪水” 事情的导火索来自一条 Bluesky 讨论帖。 Godot 主要维护者之一、同时也是 Godot 商业支持公司 W4 Games 联合创始人的 Rémi Verschelde 表示,所谓的“AI slop”

By Ne0inhk