TarsCPP 环境搭建—官方文档补充
前言
全程参照 Tars 官方文档的相关章节,最终搭建出了 TarsCPP 服务端环境和客户端开发环境。其间有些小波折,记录一下。
服务端
参照: 通过 Docker 部署 TarsCPP: https://tarscloud.github.io/TarsDocs_en/installation/docker.html。
调整虚拟机网络连接方式
我在 VirtualBox 里搞了一台 Ubuntu20 的虚拟机做服务器。
全程参照 Tars 官方文档的相关章节,最终搭建出了 TarsCPP 服务端环境和客户端开发环境。其间有些小波折,记录一下。
参照: 通过 Docker 部署 TarsCPP: https://tarscloud.github.io/TarsDocs_en/installation/docker.html。
我在 VirtualBox 里搞了一台 Ubuntu20 的虚拟机做服务器。
HOPL 是 History of Programming Languages(编程语言历史)的缩写,是 ACM 旗下的一个会议,约每十五年举办一次。
这是我父的第三篇 HOPL 论文,发表于 2021 年。中文译本 出自 Boolan 之手,不胜感激。
使用包含 (值,错误码) 对的类会带来巨大的成本。除了检测错误码的成本外,许多 ABI(应用程序二进制接口)甚至不使用寄存器来传递小的结构体,所以 (值,错误码) 对不仅传递了更多的信息(是通常数量的两倍),而且也使传递的性能有数量级的降低。可悲的是,在许多 ABI 中,尤其那些针对嵌入式系统的 ABI(专为 C 代码设计),这个问题直到今天(2020 年)依然存在。
这些年来,异常处理的性能相对较慢,是因为我们在优化非异常方面花费了大量精力。
具有讽刺意味的是,那些坚定支持异常规约的人转而去帮助设计 Java 了。
HOPL 是 History of Programming Languages(编程语言历史)的缩写,是 ACM 旗下的一个会议,约每十五年举办一次。
这是我父的第三篇 HOPL 论文,发表于 2021 年。中文译本 出自 Boolan 之手,不胜感激。
Concepts—我父最大的执念,也算是我父的滑铁卢了吧……大约是十年前吧,就看过我父亲自上阵“路演” Concepts 主题的 PPT。念念不忘,必有回响。终于还是标准化了。
这是一篇夹在 C++14 和 C++17 时间线中间的大幅文章,远不到 C++20 内容出场的时候,可见我父的急不可耐……我的看法?我是一个反模版者(注意不是反泛化),语法笨重,强制的实现可见,乱七八糟的错误信息。一群四六不懂的 TMP 至高无上鼓吹者直接让我把这种理性的反对变成了冲动的反感。所以这么些年我都没怎么系统地学习过模版。
Concepts 当然是出于善意,能解决“乱七八糟的错误信息”问题,在正向使用模版的时候也能对编译器做出正确的指示。但是!不管是优柔寡断或是市场的原因,引入新特性的同时依然保留了旧的、坏的实现路径,恰恰是我父前文提到的 N+1 问题:为了解决前边 N 种方案存在的问题引入了第 N+1 种方案。隔代的 C++ 程序员们该怎么沟通、共事?(此刻,我突然理解了那些依然坚持使用 C++98 的程序员们。)而且 Concepts 引入的长长的前缀语法抵消了 auto 所做的简化努力,语法笨重的问题反弹了。
为时晚矣……模版依然是特定人群(专家?)、特定领域(开源?)的小众选择。
HOPL 是 History of Programming Languages(编程语言历史)的缩写,是 ACM 旗下的一个会议,约每十五年举办一次。
这是我父的第三篇 HOPL 论文,发表于 2021 年。中文译本 出自 Boolan 之手,不胜感激。
有一种流传广泛的谬见,就是程序员希望他们的语言是简单的。 当你不得不学习一门新的语言、不得不设计一门编程课程、或是在学术论文中描述一门语言时,追求简单显然是实情。 对于这样的用途,让语言干净地体现一些明确的原则是一个明显的优势,也是理想情况。 当开发人员的焦点从学习转移到交付和维护重要的应用程序时,他们的需求从简单转移到全面的支持、稳定性(兼容性)和熟悉度。人们总是混淆熟悉度和简单,如果可以选择的话,他们更倾向于熟悉度而不是简单。
这也是我在前有 C 后有 Rust 的情况下继续跟踪并学习 C++ 新标准的原因:已经上了贼船了,没办法。
本文为 《C++17 in detail》 一书的中文渣中渣译文,不足之处还望指正。
翻译太特么累人了……剩余部分还是只做摘要翻译吧。
类型安全的字节表示,不是数值型值。
定义:
1 | enum class byte : unsigned char {} ; // in <cstddef> |
本文为 《C++17 in detail》 一书的中文渣中渣译文,不足之处还望指正。
翻译太特么累人了……剩余部分还是只做摘要翻译吧。
不止线程
除使用多线程外,还可以通过 CPU 或 GPU 的向量指令集进行加速。
CPU 中此类方法统称 SIMD — Single Instruction Multiple Data,即单指令多数据。常见的实现有 AVX256、AVX512、NEON。
GPU 中并行计算更碎片化,大多是跟硬件绑定,比如 NVIDIA 的 CUDA,Intel 的 TBB。也存在一些硬件无关的并行库,比如 OPENCL、OPENGL、OPENMP。
C++17 在这个方向上迈出了一小步:它解锁了标准库中算法的自动向量化/自动并行化。
本文为 《C++17 in detail》 一书的中文渣中渣译文,不足之处还望指正。
翻译太特么累人了……剩余部分还是只做摘要翻译吧。
头文件:
1 |
std::filesystem 是一个模块,同时也是一个命名空间。核心元素包括:
本文为 《C++17 in detail》 一书的中文渣中渣译文,不足之处还望指正。
翻译太特么累人了……剩余部分还是只做摘要翻译吧。
C++17 从两方面更新了 std::search
译注:执行策略是 STL 算法通用的更新特性,后边有专门的一章讲解,所以本章只介绍了 searcher。
本文为 《C++17 in detail》 一书的中文渣中渣译文,不足之处还望指正。
翻译太特么累人了……剩余部分还是只做摘要翻译吧。
两类函数:
本文为 《C++17 in detail》 一书的中文渣中渣译文,不足之处还望指正。
翻译太特么累人了……剩余部分还是只做摘要翻译吧。
头文件:
1 |
string_view 是 string 的“视图”。它不拥有 string,也不会复制其内容,但你却可以通过 string_view 进行一些 string 相关的操作,从而避免不必要的复制。