- 主题:c++太复杂了,我承认这几行代码我一辈子写不出来
要看懂已经很不容易了,要写出/修改/维护,简直是不可能。。。
语言是拿来用的工具,在工具本身花费太多时间,有点得不偿失,本末倒置。。。
现在的孩子,能用好c++,要到2030年了,那时候世界不知道是什么样子了。
【 在 z16166 的大作中提到: 】
: 似乎重点跑到“精简”上了
: ...................
--
修改:buildtolast FROM 183.242.243.*
FROM 183.242.243.*
不如把2030改成3030,那样更不用学啥东西了,躺平就能当亿万富翁了
而且你的另一个说法也不对,俗云“工欲善其事必先利其器”,你要上阵杀敌,不把自己手里的枪pao的原理和实操搞得滚瓜烂熟?那不等于是去送人头吗
而且楼上有一位还在说C++要大力做好各种工具呢
还有个先入为主的假定是:C++搞语言改进是“shi上雕花”,这也是错误的认识。
那就是,你凭啥认为搞C++标准的这帮人是脱离软件开发实际来对C++语言做改变的?是你觉得你自己比他们更懂软件开发的需求和现状吗?
我举个简单例子:
C++里引入ranged-for,用来在绝大多数情况下替代从C里继承来的for循环语法,能规避多少for循环的错误?C里的那种for写法,是很容易出现边界错误、自增错误的。
还有一个简单例子,带赋值的if语句,可以在if语句内定义变量,避免要在if语句之前定义一个范围大的变量,使得变量的生效范围最小化,避免变量范围过大带来的一些问题。这也是有用的改进。
不花时间去了解、学习就乱喷,是high-ego的表现,可以赠送五个字:无知又无畏
【 在 buildtolast 的大作中提到: 】
: 要看懂已经很不容易了,要写出/修改/维护,简直是不可能。。。
: 语言是拿来用的工具,在工具本身花费太多时间,有点得不偿失,本末倒置。。。
: 现在的孩子,能用好c++,要到2030年了,那时候世界不知道是什么样子了。
: ...................
--
修改:z16166 FROM 111.199.144.*
FROM 111.199.144.*
看哭了
【 在 z16166 的大作中提到: 】
: ...................
--
FROM 183.242.243.*
哈哈
我再加一个观点:抛弃pure C、拥抱C++(或者Rust)!
为啥?因为C++在C的基础上做了很多有用的改进(为了规避代码bug、提高抽象能力),除了我上面说的ranged-for、带赋值的if语句,还有enum class替代enum、模板函数替换macro等等,可以列出一大箩筐。
除非绝对必要(指的是某些受限环境下,比如kernel、嵌入式环境等),不要再使用pure C。
有些情况下,可以用C++/Rust来实现,然后封一套pure C的接口给C代码用。
【 在 buildtolast 的大作中提到: 】
: 看哭了
:
--
FROM 111.199.144.*
不太想看这种代码。太多新的语法糖了 看不明白
让ai写了个java的版本 我觉得好懂点
import java.util.concurrent.*;
import java.util.function.Supplier;
public class ThreadPool {
private final ExecutorService pool;
public ThreadPool(int threads) {
pool = Executors.newFixedThreadPool(threads);
}
public <T> CompletableFuture<T> enqueue(Callable<T> task) {
return CompletableFuture.supplyAsync(() -> {
try {
return task.call();
} catch (Exception e) {
throw new CompletionException(e);
}
}, pool);
}
public CompletableFuture<Void> enqueue(Runnable task) {
return CompletableFuture.runAsync(task, pool);
}
public void shutdown() { pool.shutdown(); }
}
--
FROM 210.75.217.*
c++几乎没人敢自称精通。
分享一个便捷技巧,如何快速分辨一个人是否"掌握"c++: 如果他的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;
: ...................
--
FROM 124.64.19.*
这还差个东西:任务的函数是参数可变的,并且是编译时可以检查参数是否匹配的。
加上这个feature后(恐怕java实现不了,或者会用很hack的办法来实现),你再对比一下哪个简洁点。
而且楼主那里面没有什么新的语法糖,只有巨老的using、typename。变参展开可能稍微新一点。
剩下的都是std::里的东西,有些可能是老的std里新增的
【 在 babam 的大作中提到: 】
: 不太想看这种代码。太多新的语法糖了 看不明白
: 让ai写了个java的版本 我觉得好懂点
: import java.util.concurrent.*;
: ...................
--
修改:z16166 FROM 111.199.144.*
FROM 111.199.144.*
c++ 20可以
整个标准是从无到有,从纯数学构架慢慢给各个传统函数和类添加constexpr
模板库是不是优雅,不要看库的代码,要看使用的时候用法。
项目底层用模板库,其他业务逻辑不要用,就算用也必须是anonymous namespace里的local helper函数
只要有那么几个底层的库作者能写就可以了
【 在 buildtolast 的大作中提到: 】
: 问一下,你的这个lambda表达式和index_sequense是必需的吗?不能用普通的for循环实现吗?感觉有点炫技的成分。
:
--
FROM 115.193.181.*
更elegant或者现代的写法应该是:
template <class handler_t>
auto Enqueue(handler_t&& handler)-> std::future<decltype(handler())>
{
using return_type = decltype(handler());
std::unique_lock<std::mutex> lock(queue_mutex);
tasks.emplace(std::packaged_task<return_type>([handler= std::forward<handler_t>(handler)]
{ return handler(); }));
auto res = task.back().get_future();
condition.notify_one( );
return res;
}
这回简单明了了吧。user应该在Enqueue()一个lambda进来,这才是现代c++的用法
【 在 jjjrrrbbb 的大作中提到: 】
: GPT5给了个更现代的写法,替换了不再使用的一些废弃方式。我也不知道写的咋样,没细看
: class ThreadPool {
: public:
: ...................
--
FROM 115.193.181.*
在这个基础上,如果面对的user不太行的,可以把handler_t的concept constrain加上去,变成
template<class handler_t>
concept as_task = requires(handler_t f)
{
f();
}
template <as_task handler_t>
.....
七七八八多这么代码,无非就是让user一旦用错在编译时就能报错。另外,在copilot的加持下,这些代码看起来很多,但是事实上大多数情况,你只需要写 //....的注释,很多体力活copilot自动补全
--
FROM 115.193.181.*