就表达力而言,我是不看好rust的,设计的接口也远不如C++那么自由、灵活、简洁与优雅。
举个例子,设计一个异步编程的when_all接口(也被称为gather/join等),语义要求当future都获得值之后,打包返回所有future的结果,即原型为:
auto when_all(future<Ts>&&...) -> future<tuple<Ts...>>;
也就是说when_all接口可以接受任意数量的future类型,并且这些future也是泛型的,最终的返回类型是基于输入的future类型计算后得到的tuple类型。
在rust中你只能通过宏去做,并且写join2
表达支持两个future参数,生成一个future<tuple<T1, T2>>
类型,然后join3
表达支持三个future参数,生成一个future<tuple<T1, T2, T3>>
等等,由于输入参数的不确定性,每个实现都得重复,库开发者不爽,用户用起来也不爽。
宏机制并不比函数机制要好,如果能使用函数实现应该避免使用宏。因为函数可以显而易见地表达组合能力,只需要函数的参数匹配,就可以组合,哪怕组合的语义很奇怪,而宏你很难以一种通用的方式知道它是否可以与其他函数、宏进行组合。此外宏实现内部的可读性要比函数差很多。
比如我最近尝试用C++20编写协程库https://github.com/netcan/asyncio,模仿python的asyncio标准库,用户表现几乎和python没什么区别。
C++版本:
Python版本:
C++版本:
Python版本:
C++呀,rust我不会:)
本站所有内容均为互联网搜索引擎提供的公开搜索信息,本站不存储任何数据与内容,任何内容与数据均与本站无关,如有需要请联系相关搜索引擎包括但不限于百度,google,bing,sogou 等
© 2025 tinynews.org All Rights Reserved. 百科问答小站 版权所有