已经摈弃了C的简洁性，完全是另一种语言了。
至于功能和效率，未必有质的提升。可读性更差。可维护性，可移植性，你们说了算。
学习成本太高。当年学C的时候，看半天书就上手。写个程序要想让人看不懂还得费点功夫。
我们在接一个国外软件标时，对方要求提供源码和版权，我们又不愿意他把软件直接卖第三方，所以下了很多功夫。C++的，就省事多了，直接让他看不懂。他也不敢轻易改动。
【 在 buildtolast 的大作中提到: 】
: template <class F, class... Args>
: auto ThreadPool::Enqueue(F &&f, Args &&...args) -> std::future<typename std::result_of<F(Args...)>::type> {
:   using return_type = typename std::result_of<F(Args...)>::type;
: ...................
--
修改:ylh1969 FROM 221.221.52.*
FROM 221.221.52.*

C是以简洁著称，当年只有27个关键字。
当年的开发任务都很急，开发环境也不成熟，还要带一个团队协调工作，学习成本是非常关键的。
那时候跟现在不一样，不是你想招什么人就可以招的，就这么几个人，自己要学，还要把团队培养出来。
现在好了，公司的花高价把你们几个雇来，不过你们得说明这些技术有什么好处。
【 在 blueboats 的大作中提到: 】
: C和C++从来就不是以简洁性见长的……
: 已经摈弃了C的简洁性。
: 至于功能和效率，未必有质的提升。可读性更差。可维护性，可移植性，你们说了算。
--
修改:ylh1969 FROM 221.221.52.*
FROM 221.221.52.*

没有，不过和stallman交流过
【 在 buildtolast 的大作中提到: 】
: 那厉害了，和神共事过，有交流吗？
:
--
FROM 120.245.115.*

这个代码，gemini 2.5 pro 说有如下问题：

这个 AtomicRingBuffer 的实现存在严重的数据竞争缺陷，不应该在生产环境中使用。

致命缺陷: get() 方法返回 const T&，在生产者重用缓冲区槽位时，会导致消费者访问被修改或已释放的内存，引发未定义行为。

性能缺陷: update() 方法中的发布机制虽然保证了顺序，但在生产者执行速度不均时可能导致严重的性能问题（活锁/车队效应）。

【 在 poocp 的大作中提到: 】
: 那是以前的C++没有提供足够的原子操作，不得不使用汇编而已，完全不值得提倡推广，更不用沾沾自喜。
: 我早都把这种无锁原子操作换成用std::atomic，使用新的C++标准来实现了，能不用汇编尽量不用汇编。
: 随便贴一个我写的无锁环形字符串队列的std::atomic实现。功能是对于多线程竞争更新的字符串内容，无锁让所有更新得到满足，但仅仅最后一个更新有效可读，读的过程中无锁接受新的线程更新请求。类似于一堆线程读写一个全局变量，但不用对这个全局变量上锁，限制是最近一次成功更新有效。
: ...................
--
FROM 111.199.144.*

这用在Windows UI线程的，UI更新没太高频率，后来的版本我在循环中否定分支加了
std::this_thread::yield();
来主动让出执行周期。
get方法的上层调用者是copy的，不是引用，所以占用时间很短，队列长度足够时不会被二次覆盖。返回引用是考虑到某些需要0copy的使用情况，生命周期太长的当然需要copy。
另外就是我通常不会贴一点问题没有的代码，这样可以看看别人是不是仔细读了。

【 在 z16166 的大作中提到: 】
: 这个代码，gemini 2.5 pro 说有如下问题：
: 这个 AtomicRingBuffer 的实现存在严重的数据竞争缺陷，不应该在生产环境中使用。
: 致命缺陷: get() 方法返回 const T&，在生产者重用缓冲区槽位时，会导致消费者访问被修改或已释放的内存，引发未定义行为。
: ...................
--
修改:poocp FROM 171.221.52.*
FROM 171.221.52.*