顶多没作用，反正没坏处，为啥不好？

https://www.getmailbird.com/ 用过这个，观感还不错。
其实 win10 自带的邮件客户端也够用了。

@misaka19000 使得每个锁被选中的概率都是 1/N。非素数的话，每个锁的概率在整个整数域上会有一点不平均。

@whx20202 可以。Python 的字典本身的读写可以看做原子操作，所以锁对象我觉得够了。

上策是修改你的程序架构，使得你不需要锁 key。

中策是预先创建 N 个锁（最好素数个），然后根据你的 key 算个哈希数值，模 N，锁对应的那个锁。

我自己用的是 Hexo，也放在 GitHub Pages 上。只不过我用了 Travis CI 把 Hexo 的内容全部编译成静态 HTML 放到 GitHub 上面的。

Github 没说他支持 Hugo 啊。它只是用 Jekyll 的方法去解析你的 Hugo，然而部分内容能显示而已。。。

@ufo22940268 确实 PRML 是神书没错，但是等级相当之高，先修起码要有微积分（物理含义知悉，不过收敛性证明之类的不必要）、线性代数（线性空间角度理解矩阵，而非死算）、概率论（贝叶斯角度的物理含义知悉、熟悉高斯分布，不过 PRML 第一还是第二章倒是帮你复习了高斯分布），以及一点点优化理论（至少要懂拉格朗日乘子，SVM 那一节还需要懂一点线性规划）。其他数学知识也稍微涉及了一点，不过不懂也没啥。比如变分微积分（ Calculus of variations ）我至今都不懂，只知道它的物理含义但不知道怎么求解，所以相关内容（比如变分推理）我也就是接受了书上的结论，没有深究。

但是我依旧推荐它，至少你问我推荐哪本书，但没说你打算投入多少工夫对不？这本书的正确阅读方法是渐进阅读，碰到必要的数学知识（我列出的这几个）没学过就去学，其他数学知识看不懂就看个大概。等真的把一本书都读完了，你就再也不需要别的任何书了。可以说是一本顶十本。

@ufo22940268 http://b-ok.org/book/1118657/d7b523

无论多少遍，我只推荐 Pattern Recognition and Machine Learning

楼上让贴钱的怕不是石乐志？

如果小舅子是好人，给他说清楚这个价位办不到很困难嘛？

如果小舅子不是好人，那楼主怎么还能让他姐随便嫁人？关系闹僵又怎么了？直接反驳不就好了？

如果不知道小舅子是不是好人，说一下这件事情做测试呀。

综上，还得说清楚。

@monsterxx03 看他的参数 eol='\n'，可以自定义的。

import codecs

with codecs.open(filename, 'rb', 'utf-8') as f

Better Google it yourself next time.

https://stackoverflow.com/questions/4970426/html-truncating-in-python

@p64381 其一，如果你用结构体，需要 malloc。那什么时候析构？在复杂的并发程序（比如 actor framework 里面），你必须依赖内存托管，因为这个函数的生命周期是框架负责的，而不是你程序员负责的。用 std::function，那么只要你绑定给它的参数有正确的垃圾回收和拷贝机制（比如正确的拷贝构造，或者智能指针比如 std::shared_ptr ），那么 std::function 就会遵循这套机制。

其二，std::function 可以借助 bind 在普通函数上绑定临时参数，比如从一个 (int,int,std::string) 特化一个 (int,int)。当然你可以说，我用结构体存参数啊？这不对，因为我的接受者只接受 (int,int)，连结构体都不接受，你哪里传进去呢？你只能特例化一个 (int,int) 函数，想办法把 std::string 和这个特例化参数绑定…… 说实话我不太清楚该怎么用 C 做这件事情，除非你说服那个接受者重新写一个接受 (int,int,struct Context*) 的一套东西出来。

更进一步地，std::function 和 std::bind 的价值在于给所有 C++ 的用户，类库的撰写者、类库的使用者，提供了一个统一的抽象接口。它解耦了这两个角色，类库设计者只要关注 (int,int)，而类库使用者不受 (int,int) 这个参数签名的限制。不要有附加的 struct，不许要处理垃圾回收。只要符合 std::function 这套接口的标准，管你是函数指针，是函数对象（ struct + operator()），是对象的某个成员函数，是类的静态函数，还是通过 std::bind 诱导出的 partial function，又或是局部的 lambda，反正对于接受者都一样没区别。

新时代的 C++ 适合大型工程，乃至于开源世界各种风格迥异的类库，这是 C++ 这套的价值所在。这些都是石器时代的那套不能解决的问题。
- - - -

C 那套不是完全不好，比如 ABI 统一，一个二进制库永流传。C++ 这套在这方面是有缺陷的，C++ 的 ABI 被人长期诟病，std::function 跨编译器使用可能会出现各种问题。但是这套在开源世界里面其实不成问题，你完全可以用统一的编译器进行编译。反而是 C 那套，没有一套统一的兼容层解耦调用者和类库设计者，所以必须自己处理所有事情。类库就很难写了。

我只能说到这里了。我知道你说的 struct 那套，我也用过 C，而且好几年前还沉迷过，觉得 C++ 太臃肿，编译出来的程序太大，编译太慢，还是 C 好。但是后来用过 c#、用过 python、回头好好学了学 c++（真是太多东西了，编译器方面比如模板元编程，enable_if，再比如各种 boost 库），又用过 scala。用过这么多东西，我只能说 C 真的表达力比其他所有语言弱一大截。很多设计方法你必须借助高级特性才能写得出来，而且对于 C++ 而言新特性才出来不久，可能还不好写。这会迫使你转投比如 scala akka。不过学了这么多，可选择余地也大得多，我现在写个什么玩意儿，也能就着需求挑语言了。因为不同语言写同样的东西，顶层设计可能差异巨大，而这种巨大的差异也会带来巨大的工作量的区别。

你可能不知道我说的一些东西，包括 actor framework 之类的。如果有时间强烈推荐你去看看。目前成熟的 actor framework 我觉得非 scala akka 莫属。你学过之后绝对会在写并发程序方面有不一样的体会的，会得到弥足珍贵的思想的。

说句实话吧，科班不把 java vb c# 之类的当做基础，甚至可能不教，或者用三周让你熟悉一下就结束了。科班和业内一般把算法、设计模式、操作系统这类思想更多于技巧的东西看做基础。

@p64381 其实事情是这样的。如果只把函数指针替换成 std::function，当然没有比函数指针简单多少。std::function 和 lambda 表达式是一整套体系，会影响到你顶层的设计。你想想，如果你要把某个函数指针加上一些参数当做一个整体塞到 map 里面当 value，你用石器时代的招式是不是先要搞一整套铺垫？用上 std::function 和 lambda，通过闭包捕获局部参数，铺垫就都不需要了。你可以用更简洁的设计去做同样的事情。

如果你用过 scala （估计你没有用过），那你也许对 akka 这种 actor framework 有非常好的印象。没用过 actor，也许你用过 scala 的 future。又或者你没用过 scala，但是用过 nodejs，那你可能对回调也有印象。这三种新时代的并发程序设计方法，比线程池不知道高效到哪里去了，都强烈依赖局部闭包。所以 C++ 新特性对于新时代的并发程序还是很有帮助的。有一个库叫做 C++ Actor Framework，就走在路上。

Bandizip X

@snnn 函数指针不能绑定局部产生的参数，这个很麻烦。还是 std::function 好使。

不过 @fyyz 像函数对象这种可能会有很大的上下文的对象，我觉得还是用 shared_ptr 更好，不然会产生对闭包的多次拷贝。如果闭包还有文件对象什么的，不是要跪了。