问辅导员问上一届 ×
上 v2 发帖 √

很快会腻
纯命令行根本就不符合当下流行的交互方式，反正我折腾完一圈发现最喜欢的竟然还是原版 Gnome3
要达到这种效果放多个显示屏开个能划分窗口的 terminal 就行，没啥必要费劲巴力去折腾又难配又难交互的 CLI 环境

标准里就没规定 string 必须\0 结尾
std 的 string 就是跟结尾 0 无关的，可以当做普通 buffer 来用（甚至还加了 data()成员函数）
而且不规定 string 必须 const
c_str 只是为了与 c 兼容

没见有 reserve 和 capacity 嘛，在[size]处预留个 0 呗

鱼眼镜头 xN + 拼接融合算法，回放的时候把拍摄图像映射到包围盒 /球 上

其实用任意镜头都可以拍，但拼接算法比较难出好的效果，所以尽量都用视场角大的镜头减少拼接边缘

最简单的设备，比如 insta360

看报错 F.function 应该是个 callable，比如 std::function<double(double,void*)>之类的东西，构造这种东西要么就用 lambda，要么就 functor （重载了()运算符的类），bind 就是用模板构造一个 functor 的方法，但其实现原理相当相当复杂，特别是，如何使 functor 绑定到类成员函数上。用 lambda 就容易理解得多，闭包捕获是世界上所有能进行 functional programing 的语言都通用的语义，把 this 指针捕获进闭包中，然后返回这个闭包。虽说会多出一层显式的调用 wrapping，不过这个 lambda 几乎一定会被优化掉，所以也不用担心这个问题

F.function = [this](double x,void *param){return f(x,param);};
或者
F.function = std::bind(f,this,std::placeholders::_1,std::placeholders::_2);

@XIVN1987 emmmmm 好像的确是这样，但属于 qt 框架本身的东西可以绕开 python 封装，worker 线程间可能会被 gil 影响，但 gui 的部分应该影响不着

当然了我也是猜的，确实没细想过这种问题

@XIVN1987 qt 的 runtime 都是 c++封装的，不必担心

类似于 run1(){PyEval_CallObject(run)}

两码事为什么混为一谈

写想实现的东西，不要强加什么意义

肉球.net ？？？
emmmmmmmmmmmmmmm...

ctrl shift t......

个人觉得泛型是静态语言特有的一种提高抽象度的方法，同时不引入额外性能开销，不用泛型也的确可以获得同样高级的抽象能力，但势必要采用动态语言那一套，typeid，反射什么的，有很多额外的数据结构需要维护，还有额外的类型擦除 /标识 /转换操作，楼上提到的一律转字符串也好 ducktype 也好都是这种思路，这种思路在开发的时候能简化很多重复业务逻辑，但开发库的时候并没什么卵用，很多标准库的实现都是出乎意料的简单暴力，因为库开发，提供的接口一定是确定的，有范围的，能传入传出什么数据本来就是库说得算，根本不怎么会需要动态类型能力，这个时候考虑的只有算法对不同类型的适配度，泛型是一个恰到好处的实现

代码生成器，其实就是泛型的本质，对特定类型生成同样固定流程的代码，但总归是泛型的 workaround 而已，没有泛型本身那么好用

让我想起很多年前有人做的一个 SAO 界面的鼠标手势启动器，按住双键下滑切出 sao 游戏菜单，很是酷炫

学语言要天赋的

你可以试试去模仿一门汉语方言比如粤语，比如东北口音，试试你自己模仿分辨能力，如果没法做到同时讲得出地道粤语和地道东北话，那想讲出地道没口音的英语也是没戏的


不同语言之间相同音标有细微差异，而这个差异绝大多数人都分辨不出来，分得出来他自己也念不出差异，另外不同语言中同一个韵母音节，都是会有不同头尾音的，而头尾的发音方式，从示意图到音标无一能体现，只有听才听得出来。

举个例子，普通话的 'u' ，日语 'u'， 英语 'u' 是 3 个不同的发音，双音节就更复杂了，同样是 'ou'，粤语普通话日语英语都不一样，一个音节个人感觉起码能掐出来 5 段变化，这 5 段都发对才听起来比较地道，可不是发对一个 o 一个 u 就完事了的

@hitmanx 动态链接库只是动态链接而已，但链接时的函数签名 ABI 都是固定不可改的，在编译的那一刻起就已经从附带的.h 里编译解析成导入符号写进了 binary 的符号表，说的不可改是指源码意义上无法存在 exec(void* code)这种东西，导入 dll 也好，热更新 dll 也好，源码编译后固定下来的仍然是那些

没想较真所以也没怎么严谨，较真说的话汇编时代就有 smc 自修改用来保护软件，但那对于提升设计毫无帮助



另外怎么说，依赖管理即库 /包管理是不会错的

C 的代码是不可运行时改变的
编译生成可执行文件时就需要把所有的依赖包含进来
说白了 include 就是复制粘贴把所有用到的库的代码都粘贴进一个文件然后再开始编译

编译完了再生成可执行文件

作为静态语言的 C 压根就没有运行时代码注入和扩展的可能，自然不会有什么代码中间来一行 import，更不会有 try import raise，也更不可能在运行时来引入新的全局符号，静态语言的变量和代码符号都只是地址而已，当我们需要动态生成 /访问一个变量我们有指针，这是 C 的做法，跟有虚拟机的语言是很不一样的。

这跟 O 不 OO 半点关系都没有，你用 C++也不会存在你概念中那种所谓依赖管理框架，对于静态语言来说，依赖管理即库文件管理，即包管理

鬼知道是不是真的打擦边球，可能用什么办法判了擦边球率大于设定阈值呗
没啥毛病