C++17 详解 5
本文为 《C++17 in detail》 一书的中文渣中渣译文，不足之处还望指正。
2. 语言阐明
学习并完全理解 C++ 是很有挑战的，许多地方都让程序员很疑惑。缺乏明确行为的一个原因，可能是赋予了编译器实现自由选择的权利。比如，允许更激进的优化，或者为了向后兼容（或者兼容 C）的需要。C++17 回顾了几个最出名的“黑洞”并把它们做了处理。
C++17 详解 4
本文为 《C++17 in detail》 一书的中文渣中渣译文，不足之处还望指正。
1.2 修复（Fixes）
修复的定义是有争论的。下边 3 条应该算是对在之前规则下缺失、不能正常工作的内容的修复。
C++17 详解 3
本文为 《C++17 in detail》 一书的中文渣中渣译文，不足之处还望指正。
1.1.2 删除关键字 register
关键字 register 在 2011 年（C++11）被弃用，自那以后 register 已经没有意义，现在它被删除。这个关键字仍然被保留，有可能会在未来某个版本重新设计意图（比如关键字 auto 就是复用而来，现在它是一个全新的、更强大的特性）。
C++17 详解 2
本文为 《C++17 in detail》 一书的中文渣中渣译文，不足之处还望指正。
1. 修复和弃用
C++17 标准现在有超过 1600 页，比 C++14 多出了 200 多页。幸运的是，语言规范在一些地方得到了清理，一些老旧的或潜在的坏特性随之被清除。
本章你将学到：
- 从语言中删除了什么，比如：
register关键字，auto_ptr和std::random_shuffle。 - 已弃用并会在未来版本被删除的内容。
- 修复内容，尤其是对“花括号初始化”（
brace initialisation）的自动类型推导。
C++17 详解 1
本文为 《C++17 in detail》 一书的中文渣中渣译文，不足之处还望指正。
第一部分——语言特性
C++17 是对 C++ 的一次重大更新，引入了大量语言特性。大多数新增特性让 C++ 更简洁更直截了当。
在本部分你将学到：
- 被移除和被标记为已弃用的特性
- C++ 是如何变得更精准的：比如，借助表达式求值顺序保证
- 模版相关新特性：比如
if constexpr、折叠表达式（fold expressions） - 新的标准属性（
attributes） - 如何借助结构化绑定（
structured binding）、内联变量（inline variables）、编译时if和类模版参数推导（template argument deduction for classes）写出更简洁更具表现力的代码
视频编辑器 ffcutter
ffcutter 初版写完有段日子了。本想着把功能再丰富下， UI 规范后再开源，无奈此后一连数月都忙于新家的智能家居系统的设计开发，ffcutter 就淡忘了。就以现状开源了吧，献给有缘人 。
外链 Jellyfin 视频播放页地址
我自己的检索服务
本人珍藏的视频比较多，有 TB 级别，所以之前我通过人工给视频文件打 tag 的方式，自创了一套文件检索系统。比如：
1 | snis243_吉川爱美_单体_好身材_漂亮.mp4 |
这样一个文件名，约定以下划线分隔 tag，且第一个 tag 总是视频标题。
Sanic 还不错
简单横向比较了 Sanic、Flask、FastAPI 之后，决定以后还是优先学 Sanic 吧。
Sanic 在同类评测里名列前茅。异步架构有先天的性能优势，Flask 甚至才认识到这点，好像又显得不那么重视。最新发布的 2.x 版本里的异步支持形同鸡肋，不支持 ASGI，不支持后台任务，Websocket 也同样不能支持。
通过人体识别实现智能家居控制
市面上普遍使用的人体检测方案是红外传感器，缺点很多且显得特别弱智：
- 只能检测运动物体；
- 完全不能区分人或其它活动物体；
- 不能区分人体是进入或离开某一区域。
设想一个最简单普遍的生活场景：当我晚上 7 点步入餐厅时，餐厅灯光应随之亮起；同理，当识别到餐厅无人时，应自动将餐厅灯关闭。通过人体传感器是死活做不到这点的。
转换思路，视餐厅为一平面图，上述问题即可抽象成 “如何检测一张图片内是否有人存在”，解决方案就显而易见了——目标检测。
智能家居终端控制系统设计
手里有闲置的 Surface 3 平板、Android 平板、Android 手机各一台，正好可以把它们分散固定在常驻区域的墙面上，一可以用作多媒体终端（这个功能是现成的），二就是可以用作智能家居的控制终端，和我的树莓派（中控系统）进行双工通信。
这是我设想的语音助手外的另一个重要的控制路径。比如，你已经在终端附近时，或超出拾音范围时，或者你恰巧在一直嗡嗡响的洗衣机周边时，通过屏幕终端下发命令应该是更优解。
3 个固定的终端大概是分别放在厨房、客厅、阳台。树莓派作为服务端，允许多个客户端的接入，推送设备状态信息到所有终端。最终的网络连接很可能不是图里这种 all to all 的结果，因为我很可能有两段路由。
终端的软件实现，大致确定以 web 页面形式实现，否则分别开发原生应用的代价太大了。前端框架用 React，小巧、组件化实现，上手简单；搭配 Spectre CSS 库，开发一个看起来差不多的 UI 应该是够了。
网络传输自然是 Websocket 了，树莓派是服务端，各个终端是客户端。因为是局域网传输，数据量也不大，所以应该直接传输 json 数据。具体的数据模型待定，跟最后选定的家电的能力强关联，现在写得太细也没什么意义。