“Rust思维下的C++编程”:在C++中,如何应用Rust中的概念?

C语言与CPP编程 2024-08-06 09:00

本文经授权转自公众号CSDN(ID:CSDNnews)

整理 | 郑丽媛

【编者按】自从美国白宫对开发者呼吁,“停止使用 C 和 C++,改用 Rust 等内存安全编程语言”后,两方之间从未停止的争论就被推到了一个新高度。而在这之中,也有部分 C++ 开发者提议:或许 Rust 中的一些概念,可以试着运用到 C++ 编程中?


近日,一位开发者(ID:delta242)在 Reddit 上发了一篇长文《在 C++ 中应用 Rust 的概念》,里面提到了一些可用于改善 C++ 代码的 Rust 概念,引来了诸多关注和讨论。

根据他在开篇的介绍,“虽然我不是 Rust 专家,但我很喜欢这门语言的许多概念。在日常编程中,我主要用 C++,而现在我经常会运用一些 Rust 的概念来改善我的 C++ 代码”,可以看出,下面是他亲身实践过的、可用于优化 C++ 代码的 Rust 概念。


1、在 C++ 中,如何应用 Rust 的概念?

(以下为他的长文翻译:)

(1)带值的枚举

我很喜欢 Rust 的枚举,因为你可以给枚举常量赋值(例如,Option 枚举中有一个没有值的 None 和一个有值的 Some)。在类型理论中,这通常被称为代数数据类型,而在 C++ 中,我们有 variants,可以定义辅助结构体来实现类似的功能:

struct Some { T value; };struct None { };using Optional = std::variant;

(注:这个例子可能有点蠢,因为 std::optional 要好得多。但对于更复杂的类型来说,这具有一定参考意义。)

(2)CRTP 和 Traits

在 Rust 中,Traits 用于定义类型的共享功能。而在 C++ 中,我们可以用 CRTP 在编译时强制类实现特定的函数来实现静态多态性。CRTP 还允许在基类中实现默认功能,我以前曾用这种方法来定义迭代器类型,只要基类实现了 operator[],就可以减少大量模板代码的编写。

(3)字符串格式化

在 C++ 中,如果向 std::format 传递的参数数量多于格式字符串中的占位符,并不会导致编译时错误。我曾经遇到过这样的 bug,例如由于缺少占位符,日志消息中缺少了某些信息,导致与代码中不一致。

而这个情况如果放在 Rust 中,就会产生编译时错误。所以这对于 C++ 来说,将是一个简单而实用的改进,有助于提高代码质量和开发效率。

(4)拥有 Mutex

在 Rust 中,Mutex 类型拥有受保护的值。我非常喜欢这个概念,这样不获取 Mutex 就无法访问受保护的值(这在 C++ 中经常发生)。有一个简单的技巧来实现类似效果,那就是在 C++ 中写一个具有 lock 函数的封装 Mutex 类,该函数将接受一个带有对受保护值的引用的 lambda 表达式作为参数。由于 Rust 中有借用检查器,这样的操作总是安全的,而在 C++ 中,误用很容易再次导致竞争条件,但至少通过这样的封装器,这种情况就不那么容易发生了。

(5)内部可变性

Rust 在安全的情况下会使用内部可变性(即使变量是 const),例如当一个值受 Mutex 保护时。在 C++ 中,我们也可以采用类似的想法,例如“const 表示线程安全”。

(6)IIFE

在 Rust 中,每个作用域都是一个表达式,这样可以很好地将变量限制在更小的作用域中。而在 C++ 中,我们可以用 lamdas 表达式来使用立即调用的函数表达式(IIFE)来达到同样的效果:

auto value = [] {  // Complex initializer  return result;}(); // notice the invocation

以上,就是我现在能想到的。


2、“Rust 让我成为了一名更好的 C++ 开发者”

在这篇长文下,不少开发者也分享了自己在 C++ 编程中借鉴 Rust 概念的心得,甚至直言“Rust 让我成为了一名更好的 C++ 开发者”。

(1)“最近,我养成了在 C++ 中使用“match”宏的这个习惯,我很喜欢。”

template struct overloaded : Ts... { using Ts::operator()...; };
template auto match(Val val, Ts... ts) { return std::visit(overloaded{ts...}, val);}

(2)“重载非常好,我觉得它可以成为 STL 的一部分。此外,有了 C++20 模板化的 lambdas,还可以编写一些非常花哨的代码。”

visit(  overloaded {    [] T>(T value) {}    [](auto other) {}  }, value)

对此,一位开发者感慨:“这正是我希望看到的,虽然我不喜欢 Rust,但它确实有一些 C++ 可以借鉴的做法,更安全总归是好的。”


3、在 C++ 中应用 Rust 概念的一些失败案例

不过与此同时,也有开发者提醒“必须小心”:以 Rust 的 Mutex 为例,当你访问 Mutex 中的数据时,不可能将该指针存储下来,然后在解锁 Mutex 后再访问数据(忽略特殊情况)。你可以在 C++ 中实现一个拥有 Mutex 的类,但编译器不会在意你是否在锁的作用域之外持有一个指向受保护数据的指针,并在未受保护的情况下访问它。

针对这个话题,开源搜索引擎 Meilisearch 的高级工程师 Louis Dureuil 曾写过一篇相关文章《这对 C++ 来说太危险了》:“一些设计模式之所以实用,归功于 Rust 的内存安全性,而在 C++ 中使用则过于危险。”

在文中,Louis Dureuil 分享了他在 C++ 中应用 Rust 概念的失败案例。

当时,他正在用 Rust 编写一个内部库,其中有一个他希望能克隆、而不会复制其中数据的错误类型。在 Rust 中,这需要使用引用计数指针,比如 Rc。他编写了一个错误类型,将其用作可能发生错误的函数的错误变体,继续了他的工作。

struct Error {    data: Rc,}
pub type Response = Result;
fn parse(input: Input) -> Response { todo!()}

后来他发现,对某些输入进行解析需要很长时间,于是决定通过通道将输入发送到另一个线程,并通过另一个通道获取响应,这样长时间的解析就不会阻塞主线程。

enum Command {    Input(Input),    Exit,}
pub enum RequestStatus { Completed(Response), Running,}
pub struct Parser { command_sender: Sender, response_receiver: Receiver<(Input, Response)>, cached_result: HashMap,}
impl Parser { pub fn new() -> Self { let (command_sender, command_receiver) = channel::(); let (response_sender, response_receiver) = channel::<(Input, Response)>();
std::thread::spawn(move || loop { match command_receiver.recv() { Ok(Command::Input(input)) => { let response = parse(input); let _ = response_sender.send((input, response)); } Ok(Command::Exit) => break, Err(_) => break, } });
Self { command_sender, response_receiver, cached_result: HashMap::default(), } }
pub fn request_parsing(&mut self, input: Input) -> RequestStatus { // pump previously received responses while let Ok((input, response)) = self.response.receiver.try_recv() { self.cached_result .insert(input, RequestStatus::Completed(response)); }
let response = match self.cached_result.entry(input) { Entry::Vacant(entry) => { self.command_sender .send(Command::Input(entry.key())) .unwrap(); entry.insert(RequestStatus::Running) } Entry::Occupied(entry) => entry.into_mut(), }; response.clone() }}

然而,在进行这一更改时,Louis Dureuil 收到了以下错误信息:

error[E0277]: `Rc` cannot be sent between threads safely   --> src/main.rs:58:32    |58  |               std::thread::spawn(move || loop {    |  _____________------------------_^    | |             |    | |             required by a bound introduced by this call59  | |                 match command_receiver.recv() {60  | |                     Ok(Command::Input(input)) => {61  | |                         let response = maybe_make(input);...   |68  | |                 }69  | |             });    | |_____________^ `Rc` cannot be sent between threads safely    |    = help: within `(&'static str, Result)`, the trait `Send` is not implemented for `Rc`note: required because it appears within the type `Error`   --> src/main.rs:17:16    |17  |     pub struct Error {    |                ^^^^^note: required because it appears within the type `Result`   --> /home/dureuill/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/result.rs:502:10    |502 | pub enum Result {    |          ^^^^^^    = note: required because it appears within the type `(&str, Result)`    = note: required for `Sender<(&'static str, Result)>` to implement `Send`note: required because it's used within this closure   --> src/main.rs:58:32    |58  |             std::thread::spawn(move || loop {    |                                ^^^^^^^note: required by a bound in `spawn`   --> /home/dureuill/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std/src/thread/mod.rs:683:8    |680 | pub fn spawn(f: F) -> JoinHandle    |        ----- required by a bound in this function...683 |     F: Send + 'static,    |        ^^^^ required by this bound in `spawn`

正如编译器所解释的那样,这是因为 Rc 类型不支持在线程之间发送,因为这样会导致数据竞争。实际上,Rc 中的引用计数并不以原子方式进行操作,而是使用常规的整数操作。

为了实现线程安全的引用计数,Rust 提供了另一种类型 Arc,它使用原子引用计数,而将代码修改为使用 Arc 非常简单:

diff --git a/src/main.rs b/src/main.rsindex 04ec0d0..fd4b447 100644--- a/src/main.rs+++ b/src/main.rs@@ -3,9 +3,9 @@ use std::{io::Write, time::Duration}; mod parse {     use std::{         collections::{hash_map::Entry, HashMap},-        rc::Rc,         sync::{             mpsc::{channel, Receiver, Sender},+            Arc,         },         time::Duration,     };@@ -15,13 +15,13 @@ mod parse {
#[derive(Clone, Debug)] pub struct Error {- data: Rc,+ data: Arc, }
impl Error { fn new(data: ExpensiveToCloneDirectly) -> Self { Self {- data: Rc::new(data),+ data: Arc::new(data), } } }

也就是说,只要不需要引用原子操作的计数,就可以使用 Rc。但当需要线程安全时,编译器会强制 Louis Dureuil 切换到 Arc,并带来了原子引用计数的开销。

Louis Dureuil 指出,这个原则也深受 C++ 开发者的喜爱。但与 Rust 完全不同的是,在 C++ 中,标准库中只有带有原子引用计数的 shared_ptr,它相当于 Arc,而不是 Rc——所以,即使你不使用原子操作,也仍要为原子引用计数付出代价。

最后,一句话总结:在 C++ 中适当应用 Rust 概念固然不错,但切记不要根据在 Rust 中会发生的情况,对 C++ 也做出相同的假设。

参考链接:

https://www.reddit.com/r/cpp/comments/1bx7wjm/applying_concepts_from_rust_in_c/

https://blog.dureuill.net/articles/too-dangerous-cpp/

本文转自公众号“CSDN”,ID:CSDNnews
EOF

你好,我是飞宇,本硕均于某中流985 CS就读,先后于百度搜索字节跳动电商以及携程等部门担任Linux C/C++后端研发工程师。

最近跟朋友一起开发了一个新的网站:编程资源网,已经收录了不少资源(附赠下载地址),如果屏幕前的靓仔/女想要学习编程找不到合适资源的话,不妨来我们的网站看看,欢迎扫码下方二维码白嫖~

同时,我也是知乎博主@韩飞宇,日常分享C/C++、计算机学习经验、工作体会,欢迎点击此处查看我以前的学习笔记&经验&分享的资源。

我组建了一些社群一起交流,群里有大牛也有小白,如果你有意可以一起进群交流。

欢迎你添加我的微信,我拉你进技术交流群。此外,我也会经常在微信上分享一些计算机学习经验以及工作体验,还有一些内推机会

加个微信,打开另一扇窗

感谢你的分享,点赞,在看三  

C语言与CPP编程 C语言/C++开发,C语言/C++基础知识,C语言/C++学习路线,C语言/C++进阶,数据结构;算法;python;计算机基础等
评论 (0)
  • 长期以来,智能家居对于大众家庭而言就像空中楼阁一般,华而不实,更有甚者,还将智能家居认定为资本家的营销游戏。商家们举着“智慧家居、智慧办公”的口号,将原本价格亲民、能用几十年的家电器具包装成为了高档商品,而消费者们最终得到的却是家居设备之间缺乏互操作性、不同品牌生态之间互不兼容的碎片化体验。这种早期的生态割裂现象致使消费者们对智能家居兴趣缺失,也造就了“智能家居无用论”的刻板印象。然而,自Matter协议发布之后,“命运的齿轮”开始转动,智能家居中的生态割裂现象与品牌生态之间的隔阂正被基于IP架
    华普微HOPERF 2025-03-27 09:46 109浏览
  • ​2025年3月27日​,贞光科技授权代理品牌紫光同芯正式发布新一代汽车安全芯片T97-415E。作为T97-315E的迭代升级产品,该芯片以大容量存储、全球化合规认证、双SPI接口协同为核心突破,直击智能网联汽车"多场景安全并行"与"出口合规"两大行业痛点,助力车企抢占智能驾驶与全球化市场双赛道。行业趋势锚定:三大升级回应智能化浪潮1. 大容量存储:破解车联网多任务瓶颈随着​车机功能泛在化​(数字钥匙、OTA、T-BOX等安全服务集成),传统安全芯片面临存储资源挤占难题。T97-415E创新性
    贞光科技 2025-03-27 13:50 148浏览
  • 在电子设计中,电磁兼容性(EMC)是确保设备既能抵御外部电磁干扰(EMI),又不会对自身或周围环境产生过量电磁辐射的关键。电容器、电感和磁珠作为三大核心元件,通过不同的机制协同作用,有效抑制电磁干扰。以下是其原理和应用场景的详细解析:1. 电容器:高频噪声的“吸尘器”作用原理:电容器通过“通高频、阻低频”的特性,为高频噪声提供低阻抗路径到地,形成滤波效果。例如,在电源和地之间并联电容,可吸收电源中的高频纹波和瞬态干扰。关键应用场景:电源去耦:在IC电源引脚附近放置0.1μF陶瓷电容,滤除数字电路
    时源芯微 2025-03-27 11:19 146浏览
  • WT588F02B是广州唯创电子推出的一款高性能语音芯片,广泛应用于智能家电、安防设备、玩具等领域。然而,在实际开发中,用户可能会遇到烧录失败的问题,导致项目进度受阻。本文将从下载连线、文件容量、线路长度三大核心因素出发,深入分析烧录失败的原因并提供系统化的解决方案。一、检查下载器与芯片的物理连接问题表现烧录时提示"连接超时"或"设备未响应",或烧录进度条卡顿后报错。原因解析接口错位:WT588F02B采用SPI/UART双模通信,若下载器引脚定义与芯片引脚未严格对应(如TXD/RXD交叉错误)
    广州唯创电子 2025-03-26 09:05 146浏览
  • 文/陈昊编辑/cc孙聪颖‍2025 年,作为中国实施制造强国战略第一个十年计划的关键里程碑,被赋予了极为重大的意义。两会政府工作报告清晰且坚定地指出,要全力加速新质生产力的发展进程,推动传统产业全方位向高端化、智能化与绿色化转型。基于此,有代表敏锐提议,中国制造应从前沿技术的应用切入,逐步拓展至产业生态的构建,最终延伸到提升用户体验的维度,打出独树一帜、具有鲜明特色的发展牌。正是在这样至关重要的时代背景之下,于 AWE 2025(中国家电及消费电子博览会)这一备受瞩目的舞台上,高端厨房的中国方案
    华尔街科技眼 2025-03-25 16:10 82浏览
  • 六西格玛首先是作为一个量度质量水平的指标,它代表了近乎完美的质量的水平。如果你每天都吃一个苹果,有一间水果店的老板跟你说,他们所卖的苹果,质量达到六西格玛水平,换言之,他们每卖一百万个苹果,只会有3.4个是坏的。你算了一下,发现你如果要从这个店里买到一个坏苹果,需要805年。你会还会选择其他店吗?首先发明六西格玛这个词的人——比尔·史密斯(Bill Smith)他是摩托罗拉(Motorloa)的工程师,在追求这个近乎完美的质量水平的时候,发明了一套方法模型,开始时是MAIC,后来慢慢演变成DMA
    优思学院 2025-03-27 11:47 147浏览
  • 在当今竞争激烈的工业环境中,效率和响应速度已成为企业制胜的关键。为了满足这一需求,我们隆重推出宏集Panorama COOX,这是Panorama Suite中首款集成的制造执行系统(MES)产品。这一创新产品将Panorama平台升级为全面的工业4.0解决方案,融合了工业SCADA和MES技术的双重优势,帮助企业实现生产效率和运营能力的全面提升。深度融合SCADA与MES,开启工业新纪元宏集Panorama COOX的诞生,源于我们对创新和卓越运营的不懈追求。通过战略性收购法国知名MES领域专
    宏集科技 2025-03-27 13:22 179浏览
  • 在嵌入式语音系统的开发过程中,广州唯创电子推出的WT588系列语音芯片凭借其优异的音质表现和灵活的编程特性,广泛应用于智能终端、工业控制、消费电子等领域。作为该系列芯片的关键状态指示信号,BUSY引脚的设计处理直接影响着系统交互的可靠性和功能拓展性。本文将从电路原理、应用场景、设计策略三个维度,深入解析BUSY引脚的技术特性及其工程实践要点。一、BUSY引脚工作原理与信号特性1.1 电气参数电平标准:输出3.3V TTL电平(与VDD同源)驱动能力:典型值±8mA(可直接驱动LED)响应延迟:语
    广州唯创电子 2025-03-26 09:26 198浏览
  • 汽车导航系统市场及应用环境参照调研机构GII的研究报告中的市场预测,全球汽车导航系统市场预计将于 2030年达到472亿美元的市场规模,而2024年至2030年的年复合成长率则为可观的6.7%。汽车导航系统无疑已成为智能汽车不可或缺的重要功能之一。随着人们在日常生活中对汽车导航功能的日渐依赖,一旦出现定位不准确或地图错误等问题,就可能导致车主开错路线,平白浪费更多行车时间,不仅造成行车不便,甚或可能引发交通事故的发生。有鉴于此,如果想要提供消费者完善的使用者体验,在车辆开发阶段便针对汽车导航功能
    百佳泰测试实验室 2025-03-27 14:51 186浏览
  • 案例概况在丹麦哥本哈根,西门子工程师们成功完成了一项高安全设施的数据集成项目。他们利用宏集Cogent DataHub软件,将高安全设施内的设备和仪器与远程监控位置连接起来,让技术人员能够在不违反安全规定、不引入未经授权人员的情况下,远程操作所需设备。突破OPC 服务器的远程连接难题该项目最初看似是一个常规的 OPC 应用:目标是将高安全性设施中的冷水机(chiller)设备及其 OPC DA 服务器,与远程监控站的两套 SCADA 系统(作为 OPC DA 客户端)连接起来。然而,在实际实施过
    宏集科技 2025-03-27 13:20 109浏览
  • 在智能语音产品的开发过程中,麦克风阵列的选型直接决定了用户体验的优劣。广州唯创电子提供的单麦克风与双麦克风解决方案,为不同场景下的语音交互需求提供了灵活选择。本文将深入解析两种方案的性能差异、适用场景及工程实现要点,为开发者提供系统化的设计决策依据。一、基础参数对比分析维度单麦克风方案双麦克风方案BOM成本¥1.2-2.5元¥4.8-6.5元信噪比(1m)58-62dB65-68dB拾音角度全向360°波束成形±30°功耗8mW@3.3V15mW@3.3V典型响应延迟120ms80ms二、技术原
    广州唯创电子 2025-03-27 09:23 151浏览
我要评论
0
0
点击右上角,分享到朋友圈 我知道啦
请使用浏览器分享功能 我知道啦