@Gandum 讲道理你要是知道`errors='replace'`是在干什么的话就不会有这种问题了……

8102 年了怎么还有分不清 code point 和 byte 的人.`a.encode("gbk")`不就完了

事实错误就是事实错误,不管你想让人怎么看待那都是事实错误.如果阮一峰的博文中的事实错误都能洗地的话,下一步是不是就可以把谭浩强的事实错误也给洗掉了?

libmediainfo,有包括 Python 在内的多种语言的 API binding

@maichael Thanks! It works!

@0vels 非内置的扩展就是这样的.但是`markdown-language-features`这个没法用这种办法启用——连找都没法找到的.

arch 其实明显不折腾…… given that 你和我一样认为软件不是最新版本的根本不能用……

LZ 我告诉你一个笨但是有用的办法:画真值表硬怼 :)

直接 rsync 传过去.如果是 Win Server (<2016)当我没说.

@murmur 可是 c 里面确实不能通过 cast 来去除 const 啊,除非你把触发未定义行为也定义为"能"

没看懂.`bsoncxx::builder::stream::document`的`operator<<`不是只能接受 string,bson 的 document 和`bsoncxx::builder::stream::finalize`的吗.哪儿有接受 long long 的?LZ 能不能发一下详细的编译错误?

绿色保护着妮前进……

C++的代码和具体的机器指令又没有必然的联系."高层抽象"了解一下.首先 C 和 C++就不保证一定是 1.编译的 2.编译目标是机器指令.其次 C++的 implementation 完全可以自己插入需要的代码来获得符合要求的实现:RAII 不就是这样做的吗.POSIX 和 MINGW 的 GCC 以及 POSIX 下的 Clang 有两种异常的实现:SJLJ 和 Dwarf.Windows 下的 MSVC 和 Clang-cl 对异常的实现则是 Windows 的 SEH.不同异常的实现属于这个实现的 C++ ABI 的一部分,所以即使是同一个平台下的同一个 implementation,如果其对异常处理的实现不同的话一般情况下也是不能保证其 ABI 是互相兼容的.特别是 SJLJ,Dwarf 和 SEH 这三者两两之间 ABI 互不兼容.

哦不对我傻了.我忘了有个东西叫做 Integer promotion. Integer promotion 的存在导致`int`的 rank 必然小于等于`size_t`进行 Integer promotion 之后的类型,所以两者相乘的结果必然是严格无符号的,所以这段代码应该是严格没问题的……

1 中的代码的本意是认为`size * sizeof(PyObject *)`只有在不发生溢出的情况下其值才是数学意义上相乘的结果.不过我很怀疑这段代码可能不能保证 portable:一个`int`和一个`size_t`相乘的结果不保证一定是个无符号的(比如`int`的 rank 严格大于`size_t`的时候).而有符号数溢出是未定义行为.我没怎么读过 CPython 源码,如果 CPython 源码真的是这么写的话我只能说这代码质量还是有待改进……

《论 C 语言是如何给一名 IT 界的从业人员带来负作用的》

NOIP2004 普及组最后一题.我以为已经是常识了……

不是 Windows 10?????

@snnn 我不太清楚贵司业务注重哪块,不过对于我而言,函数指针不能放闭包,光这一点在很多时候就足以否决它了.就连 Scheme 都有 call/cc 呢,就别假装和 Haskell 多亲近了.至于说额外用个 struct 包起来什么的……都封装到这种地步了还不如 std::function 一把梭.当然确实 C++的整个闭包体系面对多线程环境对象的生命周期问题确实有点挫,但是无脑 std::shared_ptr 目前也将就够用,更何况函数指针面对这种情况只能使问题更加混乱——用裸指针管理好多线程对象生命周期的问题谁敢说是"简单"的?反正我认为这至少不比搞清楚右值引用和移动语义更简单——而且大不了无脑完美转发,撑死多写几个重载.又不是要写 extern "C"的接口,搞的那么简陋干嘛……

而且 C++一来不一定是编译的,比如 Jypiter notebook ——是的没错这货就在最近加入了对 C/C++的支持;二来就算是编译的也不一定是编译到机器码,比如 emsrcipten.js;三来就算是编译到机器码也不保证源码和目标机器码有直接对应关系,只要符合 as-if rule 编译器心情好直接就给你内联了都说不定:GCC 老早就能对虚函数调用进行内联分析了,函数指针不可能就完全两眼一抹黑;四来不同平台的机器码显然又不一样.基于以上理由"观察编译后的目标代码来分析源码"最多只能算是特定情况下的辅助源码分析手段,而大部分情况下要照着语言的语义和库的文档进行分析(当然 C 和 C++在这里一坨坨的未定义行为对这种分析方法造成了非常大的阻碍,不过良好的编码习惯还是能一定程度上减轻其影响).而论及库的语义的话 std::function 并不比函数指针复杂多少——甚至它作为一个类型擦除的容器要比泛泛而谈的仿函对象要更简单.就算是编译错误,错误还能长到哪里去?反正比那些模板满天飞的库(比如 boost.spirit, boost.spirit, boost.spirit 和 boost.spirit)的编译错误短多了,用多了也就熟了.

C++确实在功能强大程度和易用性等多方面上有很多欠缺,甚至在可见的将来很多欠缺难以有解决的可能.不过除非特殊情况特殊考虑,否则我不认为回滚到 C 上是个更好的选择.