回复“无敌函数库”
2026-08-10 14:46:37
发布于:浙江
原帖 | 作者 | 回复@Deep欠揍 | 深度欠揍
我严肃查看了你的“基于Linux+GCC的无敌函数库”。这不是“有点瑕疵的函数库”,而是大量未定义行为、接口冒充标准库、错误优化和被主动屏蔽的编译器警告叠在一起。我还把纯代码部分拿出来用 GCC 14.2 编译并做了几个针对性测试;下面只挑硬伤。
-
最讽刺的地方:先把所有能救你的警告关掉。
代码直接忽略-Wuninitialized、-Wmaybe-uninitialized、-Wconversion、-Wstrict-aliasing、-Woverflow、-Wstringop-overflow、-Warray-bounds等。
这些恰好就是这种手写内存、手写格式化 I/O 最应该打开的警告。这不是“优化”,这是把烟雾报警器拆了,然后宣布厨房绝对安全。 -
那一整串
#pragma GCC optimize有明显的“参数堆砌感”。
我用 GCC 14.2 编译,-fwhole-program、-fstrict-overflow、-fcse-skip-blocks、-funsafe-loop-optimizations等若干项目直接被 GCC 报为不适用于该 pragma 的 bad option。与此同时Ofast、fast-math、各种 loop 参数又大量重复。
更糟的是强制avx512f。这意味着生成的程序可能在不支持 AVX-512 的机器上直接Illegal instruction。一个号称“Linux+GCC”的通用库,开头先把大量普通 CPU 排除出去,属实很“无敌”。 -
有些所谓 GCC builtin 宏,实际上用了就编译不过。
例如:
fnlikely(cond) -> __builtin_unpredictable,我这里 GCC 14.2 根本没有这个 builtin;
assume(cond) -> __builtin_assume,同样编译失败;
types_compatible_p(int,long)的宏展开写法本身就有语法问题;
最离谱的是unreachable(x)展开成__builtin_unreachable((x)),而这个 builtin 不接收参数。
换句话说,有些“函数库功能”之所以没报错,只是因为作者自己还没用到它。 -
往
namespace std里面硬塞一个自己的struct string,属于红线级错误。
代码直接定义namespace std { struct string { char r1[1001]; ... } }。
用户代码不应该自己往std加这种声明。更现实的问题是:我只要再#include <string>,GCC 就立即报:
using typedef-name 'std::string' after 'struct'。
所以它不是“重写了一个更快的 std::string”,而是占了标准库的身份证号码,然后祈祷警察永远不来查。 -
这个所谓
std::string也根本不是 string,而是固定 1000 字节的静默截断缓冲区。
构造、拼接全部最多留 1000 字节,超出的内容悄悄扔掉,没有异常、没有返回状态。size()每次还调用strlen,因此是 O(n),而不是正常字符串保存长度。
所谓“跟标准库一样”,从容量模型、复杂度、异常行为、API 到兼容性,没有一样是真的。 -
read_s()处理超过 1000 字节的单词时甚至会把输入流读坏。
循环条件是cnt < 1000,但每一轮末尾已经提前执行了一次_gc()。因此第 1001 个字符已经从输入流取出来,却既不保存,也不退回;接下来的剩余字符串又留给下一次读取。
结果不是简单的“截断”:是丢一个字符 + 把一个 token 撕成两个 token。这是会让后续所有输入错位的 bug。 -
底层
_gc()用char表示 EOF,是经典错误。
_gc()返回char,但 EOF 是int。
在默认signed char的 x86 上,字节0xFF会和 EOF 混淆;更有意思的是read_s()用c <= 32判空白,那么 UTF-8 中文的高位字节在 signed-char 环境下通常是负数——也就可能被当成“空白”。
如果是 unsigned-char 平台,EOF == -1又可能永远匹配不上。
一个字符串输入库,连“字符”和“EOF”为什么必须用 int 区分都没处理好。 -
所谓“
read_w/write_w和scanf/printf一模一样”是整份代码里最危险的宣传。
read_w("%d", ...)实际用va_arg(args, ll*)取参数,真正scanf("%d",&x)对应的是int*;照 scanf 用法调用就是未定义行为。
write_w("%d", -1)更明显:它用va_arg(args,ll)去取实际上通过 varargs 传入的int。我实测:
write_w("%d", -1)输出了 4294967295。
%lld也没真正实现:第一个l会错误处理,随后两个l继续被当格式文本解析。我实测456得到的是类似456ld。相关实现就在这里。 -
浮点输入输出同样和 scanf/printf 差得离谱。
read_f()不支持科学计数法;.5也读不对。
我实际输入:
.5 1e3
得到:
5.000和1.000。
write_p()又只是不断乘 10 后截断整数,不进行 printf 那种正确舍入。比如保留两位时,某些本应进位的值会直接被截掉。
因此“printf 一模一样”可以直接删掉“一模一样”,甚至最好把“printf”三个字一起删掉。 -
整数输出存在最经典的
LLONG_MIN未定义行为。
write(ll x)中:
if (x < 0) { ... x = -x; }。
当x == LLONG_MIN时,正数对应值无法由 signedlong long表示,-x发生有符号溢出。int版本对INT_MIN同理。
而作者恰好又在前面把 overflow 警告关了。首尾呼应得非常完整。 -
底层
write()完全不处理 partial write。
_pc()缓冲区满以后直接调用一次write(1,...),然后无条件认为所有数据都写完了;_return()也是这样。
POSIXwrite并不保证一次写完全部字节,也可能被信号中断。对于普通 OJ stdout 很多时候“恰好能用”,但这离“函数库”该有的可靠性差得很远。
而且它没有 RAII 自动 flush,忘记最后调用_return()、提前return,缓冲区的数据就可能直接丢掉。 -
cin >> char和标准cin的行为都不一样。
它直接val = _gc()。
标准格式化输入cin >> char默认会跳过前导空白;这里不会。也没有endl、manipulator、状态位、EOF/failbit 等标准流语义。
所以原文的“直接跟标准库 cout/cin 用法一模一样”属于明显错误描述。 -
数学库有“看起来数学,实际定义域没想清楚”的问题。
pow(0,-1)这份实现直接在a == 0时返回 0,而数学/标准浮点语义显然不是这样;指数先double -> long long再分析,也会碰到超范围转换和LLONG_MIN取负的问题。
sqrt(x,n)名义上算 n 次方根,却把n定义成double,牛顿迭代里的幂次数又靠static_cast<int>(n)控制;如果n=2.5,公式的一半认为它是 2.5,另一半认为它是整数 2,数学上已经自相矛盾。还没有迭代次数上限。 -
那个“introsort”名不副实。
真正 introsort 的关键思想之一,是递归深度耗尽以后切到有 O(n log n) 最坏保证的排序;这里d == 0时却调用insertion_sort。
也就是说,一旦快速排序部分表现不好,作者选择的兜底算法反而是 O(n²)。这等于消防通道尽头放了一个油桶。
另外深度d = 2 * ln(n)用的是自然对数。
我做了约三万组随机/重复值/升降序数组的正确性 fuzz,这部分暂时没轻易炸出排序错误;所以我不会硬说“sort 一定排错”。但它的“introsort”最坏复杂度设计确实是错的。 -
最后还有一个非常基础的事实:这份“源码”原样连源码都不是。
文件第一行就是没加//的中文说明文字,代码之后又继续直接写中文用法说明。
我必须先把代码区单独截出来,它才能编译。所谓“复制即用函数库”在第一关就已经失败。
最核心的评价可以浓缩成一句:作者花了大量精力模仿“高手代码的外观”——builtin、AVX512、branch hint、手写 buffer、pragma、introsort——但对 C++ 对象模型、标准库命名空间、varargs ABI、EOF、POSIX I/O、浮点格式化和复杂度保证这些真正决定正确性的东西掌握得很不扎实。
尤其是“屏蔽 -Warray-bounds/-Woverflow/-Wuninitialized + Ofast + 自己重写 std::string + 自己实现 printf”这一套组合,不叫“无敌函数库”;更像是把安全带、ABS 和故障灯全部拆掉,然后因为仪表盘没有报警而宣布车性能提升了。
全部评论 3
本来代码就是 AI 生成的,可以发现与他本人平时码风完全不符,同时本人也没有这个能力
1周前 来自 浙江
1我觉得不一定,@Deep欠揍 | 深度欠揍的代码有这么多漏洞(
我承认一些漏洞是ChatGPT帮我找出来的),我认为不像是AI编写的。有一定的可能性为此人自己编写,而且他的基础页挺扎实的。1周前 来自 浙江
0注意到此人甚至不知道埃筛的复杂度,或者说不会分析复杂度。并且这个帖子里他承认了用 AI 分析代码复杂度,虽然并非直接证据,但也可以看出来。并且这个人很多都是装出来的,比如先前说不会四年级余数的问题,后脚说数学学到大学。
1周前 来自 浙江
1不过我觉得他知道的还是挺多的,虽然可能只知道一点皮毛。
1周前 来自 浙江
0
ai文
1周前 来自 广东
0声明:GPT-5.6 Sol提供部分技术支持。
1周前 来自 浙江
0GPT不是付费AI吗
1周前 来自 浙江
0是的。
1周前 来自 浙江
0
1周前 来自 浙江
0



























有帮助,赞一个