@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 更好，不然会产生对闭包的多次拷贝。如果闭包还有文件对象什么的，不是要跪了。

写好单元测试，用好连续集成，没了。

如果是一个买来看看视频收收邮件写写文件，嗜好是拍照所以照片一大堆的人选 8g + 512g 我一点都奇怪。

但是楼主你这个工作内容还选 8g，我只能说，你开心就好。

我觉得楼主和你的小伙伴最好注意一下“副作用”有关的各种约定。

面向对象设计中，为了让调用更安全，函数语义上最好隔离“读取”和“写入”。换句话说，叫做 get_xxx 的，语义上应该只返回状态而不更改状态，叫做 set_xxx 的则只更改状态而不返回状态（返回 self 例外，这是链式调用）。

缓存策略是另一回事。它应该对调用者透明。换句话说，你要是不高兴现在的缓存策略，可以随时更换，而不影响接口语义。所以你第一个版本是不对的，因为调用者需要明确知道 get_term 引起一次缓存，这个接口设计是不合理的。

永远不要让外部调用者接触类内部的缓存策略。

第一个版版直接枪毙。

第二个版本，_get_term 命名不合理。get_XXX 一般默认不引起副作用，哪怕是私有（保护）函数。

p.s. 为啥第二个版本不初始化 now_weeks = what_day = None，通过 is None 决定是否调用 _get_term，而要一个单独的 __get 标志位？

@murmur 说得好，操作系统不是问题，问题是你的预算多少。

如果你有预算，我会推荐 Macbook Pro。如果没有，一个简单方案是 Ubuntu Server 虚拟机，然后在 Whatever 你喜欢的操作系统里面写程序，在虚拟机里面调试。有些 IDE 比如 WebStorm 支持自动上传到 Linux 服务器，所以还是挺方便的。

别尝试虚拟机 macOS，最没有意义的事情之一。

@tianxiacangshen 我其实也是讽刺地加上那一句的。。。

@tianxiacangshen 系统会自动平衡的，你要担心不够用再加大总容量呗。