对性能不敏感的话，我也支持用 python 这样的胶水语言来做插件，ABI 相关的问题都不用自己来解决

我没仔细看文档, 总感觉写的不够诱人啊. 有几个问题. 我是 cmake 用户.
问题 1: 假如我刚入门, 这个项目如何吸引无基础的新用户呢? 或者说, 假如有后辈问我, 我为什么要推荐他从 xmake 入手,而不是 cmake 入手呢?
问题 2: 我为什么要从 cmake 迁移到 xmake 上, 有没有什么技术上的痛点是 xmake 才能解决的.
问题 3: xmake 有没有明确的推广计划? 比如找大公司背书, 或者抱项目的大腿, 我觉得当年 cmake 就是抱上了 kde 的大腿才稳住了不少人吧.

今年抽空把 <C 语言程序设计：现代方法（第 2 版)> 看了. 确实是本好书, 只有二三处瑕疵吧, 比如某些实践中不应该用的 featrue 也详细的介绍了一下. 语言层面非常推荐看这本书.

至于其他所谓的底层编程, 和 C 的关系并不是很大, 这些问题一般都和硬件及 OS 有紧密的关系, CSAPP 这样的书可以作为入门. 其他的则可以进一步按需求补充

首先, @ysc3839 说的很对, 楼主应该从根本上描述下自己的需求, 而不是自己想当然的来一个解决方案,一条路走到黑.

然后, LZ 其实就是想做一个 C/C++的简单 addon 系统.
如果做得太玩具, 那可能不如重新编译. 如果做得太全面, 考虑到 LZ 描述的水平, 可能吃不下这个饼,C/C++毕竟是"静态"的.
具体而言:
@chingyat 的路线正确, 但是有点像把大象装进冰箱里. 第三步第四步其实是很麻烦的, 毕竟你在编译期并不知道要 cast 成什么样的函数, 最起码需要考虑参数数量的问题. 这里, 要么按 @HHehr0ow 所说的, 按照 C 的 ABI 直接压栈进行调用. 要么楼主可能就要按照写一个很大的`switch(arg_number)`,每个 case 都先 cast 一下,再触发函数调用, 且不可避免的所有形参都必须是某种`Variant`类型

@iceheart 提到了参数类型的问题, 其实 xml 是不需要描述函数签名的,只要有函数名就够了, dlsym 拿到的只有一个指针,类型信息对函数调用是没有意义的. 重点是序列化 /反序列化的问题,大概就是 protobuf 这样的库做的. 也就是你在 js 中传了一堆东西给某个进程, 这个进程需要把这堆东西变成一串对象`arg1,arg2....argN`作为函数实参,然后进行函数调用. 如果涉及了复杂类型, 那么"在 C++中实现反射"等着你.

当然,这里面还有很多比较细节的问题, 比如调用的约定, IPC 传参的实现,等等等等,LZ 不要再考虑一下开头第一句吗?

发呆比较闲 ,闲扯一下, 所以没有后续 XD

同意不少 v 友的意见 , 人口基数,细分领域都很重要.
比如强如 NVIDIA https://github.com/NVIDIA/cutlass 这么优质的代码也没多少 star

我只能说, 楼主的思路是正确的. 服务器踢你下线基本看不出来什么规律,应该就是网易定期把没获得经验的号炸服踢下去.

这样的工具我已经撸了一个稳定用了几天了, 不过显然没必要在这个点发出来. 一方面增加服务器拥堵,另一方面枪打出头鸟, 弄得太广泛搞成外挂封号就得不偿失了.

意思是只有 mac 和 ios 能用吗?

口音是非常次要的,张大嘴巴说清楚就行了.
巧妇难为无米之炊.楼主的这个状态还是找些适合自己的语法书比较合适.
对中文母语者而言,英语的听-说几乎就是两个问题,听懂要比会说容易很多.语法就是知道自己在说什么的依据.然后才是熟能生巧.

这和学编程是一样的,实战固然重要,但是基础还是要有的.你不学计算机的基本工作原理,不学语言的基础细节,就容易陷在各种等效 /类比 /强记中

我只能说,一定要蓝牙,兄弟

@chris5641 正解.

我翻译一下:
派生类构造时没有调用基类的构造函数,导致基类成员没有被创建,直接输出自然报错.

@IgniteWhite
@PythonAnswer
开玩笑,各位这么认真,语言上的东西没必要这么较真啊.

从语法的理论上讲,这样分析应该是没错的.
陈述句举例: Either this apple or that apple is bad == Both apples are bad.

实际应用中最正确的回答是"随语境".
因为 either or 可以用在陈述句中使用,也可以用在选择句中,而有的选择句中强调必须择其一,有的则不限制必须择其一.

就像"i++i+i++i+++i"的结果一样,答案是随编译器而定的

各位英语捉急啊,英语中 either 的逻辑与 both 意义等价. Either A or B 的逻辑意义是 A 和 B 必须都为真.若任何一个为假,则不能用 either
所以是 A and B

你们这些码农啊,too young,用到编程了就是 IT.

目前所谓的机器学习,不过就是基于统计进行的估计,归根到底是数学系的人搞的.coding 只是必要的工具而已.
所以要不要深造是看你数学功底行不行.和 IT 有毛关系呢

@wutiantong 赞同
这显然是变长编码的问题,使用定长编码 UTF32 或者 UCS4 就行了

```
char data[]=u8"中文";
std::wstring_convert<std::codecvt_utf8<char32_t>, char32_t> utf8_ucs4_cvt;
std::u32string ucs4_cvt_str = utf8_ucs4_cvt.from_bytes(data); // utf-8 to ucs4
std::string u8_str_from_ucs4 = utf8_ucs4_cvt.to_bytes(ucs4_cvt_str); // ucs4 to utf-8
```
详情可参考: http://blog.poxiao.me/p/unicode-character-encoding-conversion-in-cpp11/

@quadpixels 想法基本是对的.
depth testing 和 blend 是两个层面的问题.
先进行 depth testing ,它是基于三维模型进行的,这一步就会丢弃被遮挡的 fragment.
blend 则是基于颜色缓冲进行的,是把当前渲染的帧和上一次渲染的帧进行混合.

传统解法是:
保持开启深度测试.
先绘制所有不需要透明度的**物体**
再从远到近绘制每一个需要透明度的"曲面".