为什么我觉的C++不是很难, 难点在哪里?
为什么感觉和C++相见恨晚, 并没有什么难点.以前感觉难, 只是小马过河, 被松鼠吓到了.
学习C++不数日; 看过C++ primer 前10章,看过大部分cppreference, 还有 cppstudy 内存, 堆栈布局部分.
类, 我N年前算是精通PHP, 所以稍微了解下多态等语法细节就OK.其他诸如 std:: map vector array span queque....c++ 有更多method, 更能高效管理内存.走下cppreference就OK了;其他语言很多想优化的地方, c++都内置method....
宏,c语言的宏;不如rust 宏好用. 也没必要那么复杂, rust宏部分功能是为了解决其泛型的短板.
模版元:看似复杂, 实际就是当泛型用. 这东西比其他语言的泛型NB多了, 代码更能抽象.
重载:现在看来, 没有重载的语言简直反人类. 没有重载的语言其实都在曲线实现重载, 那个代码繁琐度...
高并发:这东西原理很简单, epoll就那几个接口.主要是写个调度器, 参考下go实现, 写个简版的stackful纤程也不过十天.跨平台封装两个方案就好. 客户端和服务端本来就是两个程式;
内存管理: c# golang实际上后期的垃圾回收优化, 都是直接操作内存的,都是unsafe的, 本质是曲线实现C++的原始内存; 作为其他语言unsafe重度患者表示:内存管理稍微注意,尽量使用RAII, 没什么难点.
当然我看过很多复杂的指针转换之类. 这种写法是人为的反人类. 写代码要通俗易懂, 好维护不是?那种代码我连碰都不会碰.
还有什么呢?!
为什么我要学C++, 用c# go rust也能写项目,但抽象化和C++没法比.最终的性能优化都是大量的unfase, 那何必呢?rust 反人类的borrow, 写到想哭.go c#用unsafe可以把gc300ms 降低到 确实如此，你跟我的想法和体验是类似的。在工程方面，对比其他主流语言，其实开发效率高，控制力极强，重构非常方便，极适合原型法渐进开发。
一般说难度高的，主要是：
1、编译器版本上不来。
2、极度抠性能。在这种情况下，其实让你做的都是些比较逆天的、反常规的想法和思路，导致甚至对标准库也各种求毛求疵。而标准库难以做到的，你自己做当然更难，而且更容易在兼容性上出问题。不过在这种情况下，C++虽然难做，但其他语言几乎更没可能，或者难度更高。
3、RAII封装度不足，工程里参杂了大量裸指针。一出现裸指针，马上就附带了确定所有权归属谁的问题，很容易出问题。在库里其实是比较容易确定的，也容易控制，在工程里往往就很难。这个问题其实相当一部分来源于第2点。另外就不得不提一嘴google的code style不太行，最新的不知道，按它以前的那种范式，则必然难以避免出现大量裸指针。
4、逻辑上该传值的地方，为了性能，硬是设计为传引用或指针，后续导致调用上需要额外的隐藏规则，一不小心就会意想不到的错误。
5、一些诸如动态设计、类型擦除容易导致的问题。尽量克制自己不要随便写这种代码，尽量做能静态决定的代码。
6、内存池与Allocator的配合。说起来标准库和boost好像都没什么特别好用的内存池啊。
7、自我好奇心与模板元编程的滥用，说真的，控制这种容易放飞自我的行为，还挺难的。这部分几乎是没底的，永远都有黑魔法。
8、多线程和多进程开发，没有完全定型。像我基本就直接用asio了，其实很好用了。如果完全自己搞一套，那难度必然高了。这里又涉及到各种锁、原子操作、内存序等细节和性能控制，对性能没特别要求就容易，有特别要求就又回到第2点了。
9、多开发范式混杂的情况。宁愿封装一层了，尽量避免混杂，统一风格。
10、工程上对concept体系的构建，近乎于道和艺的追求了，不完全是技术层面的东西了，本身也是一大难点。
那么说起来，其他大部分语言也没有以上10点，如此还真没法说不难。 我认为c++的难点在于入门C++的书里面没有一本是编写良好而得到广泛传播(也就是出名的)。导致大多数新人入门c++都要以一种奇怪而错误的方式学习c++而踩坑。而有其他语言经验的人学习c++并不困难。 这个问题问对了啊。C++ 确实不难，假设你已经学会了诸如模板，STL，智能指针，C++ 的面向对象这些语言级别的语法和特性，你也更进一步的能升级到能理解多线程编程和并发的编程思维，理解了多线程安全，可重入是什么意思，理解了各种异步操作，重叠 IO 等稍微复杂一点的技巧，知道了如何写并发环境下的代码（这一步会有少数天赋较差的人倒下，但实际上比例不低，很多人对多线程和并发编程的底层部分是一知半解非常模糊的），这一步通常没有太大的障碍，90 % 的码农在这一步没有特别的困难，除了需要经常百度，去适应的理解编译器那给出的十分晦涩并不直观的警告和 error。我也觉得 C++ 不难。但难于用好，因为 C++ 是 native code，是为数不多毫无歧义毫无争议的编译型语言（假设 C++ 是个汉子，那 java ，c# 这种就有点不男不女的），这就意味着它比其他语言难伺候的多，程序员和底层 CPU 指令靠的非常近，所以会有很多很多细节上的麻烦需要程序员很清楚底层才能搞定。C++ 主要难在让程序具有稳定性，可靠性，可扩展性，可维护性这 4 大工业级质量要求的特性上，要做到一个东西 work 了是远远不够，工业级要求它稳定可靠持续的不间断 work，比如说你也能仿照别人照猫画虎的整个战斗机发动机，感觉飞的还挺帅，但是飞机飞着飞着就莫名其妙的掉下来了，飞行员挂了，你说就算你飞的再帅，但飞行员敢用你的飞机吗？明白差距了吧。很多人到了这一步死都入不了门，因为，天赋不够！使用 C++ 就意味着程序员肩负着资源管理，内存维护的重任，很多人在这个基本的门槛上都倒下了，更别提卖向下一步。下一步是让你的代码具有可扩展性和可维护性（此为不可道之道也），在这一步通常你对运行时性能和时空平衡有了认识，你能为了运行时效率付出额外的编程成本，让程序的速度运行如飞！或者让程序占用的内存大大降低，同时你也知道了什么叫做资源/内存维护权，一个资源应该由谁，以及怎样正确的释放和管理维护。再下一步是让你的产品具有稳定可靠性，这可谓 C++ 里的至高境界或者说基本上 99.9% 的人在这一步上永远的一脸懵逼不得入门，那就是你能维护改进别人的质量残缺的产品，你能解决莫名其妙的 segment fault，进程 crash，EIP 寄存器跑飞，很多莫名其妙的运行时意外甚至经验最丰富的人也无法解释原因，你不仅知道如何调试如何处理 C++ level 的异常，更能用 CPU level 的异常处理解决这类问题，能像福尔摩斯破案，海底捞针一样的逐步摸排查出 memory leak 的点，这类极其极其困难的 c++ 问题，几乎都是那些不可替代的人才能解决。 用C++写东西本来也不应该很难，不然 modern C++ 那么多年的工作都在干啥。。。
抛开需要深刻理解C++所有主要特性，才有资格去写C++代码这种奇奇怪怪的想法的话。
我理解 C++ 的实际难点有三点：
[*]没有足够好用通用的官方库，导致很多东西得自己造轮子。
[*]出现问题时排查问题的困难。这点是由兼容C语言引入的（说是cpp的设计哲学也没问题）
[*]奇奇怪怪的OB和莫名其妙的语法规则。后者尝试在代码里用过一些模板的想必都能体会。
嘿嘿，本来想写一个类似于“C++ 就难在你不知道它难这样的回答”，但看了你的问题的具体内容，明显就不能那么答了……
根据你的回答，我得说，C++ 要用好主要是需要理解它解决的痛点问题。觉得难的人的主要原因一般是，看到了极其复杂的语法和规则，不知道什么时候该用什么，也记不住那些繁杂的规则。而你，似乎已经有了相当的经验，也用了很多的其他语言，在系统编程方面已经有了相当多的背景知识。所以，也许 C++ 确实是一种适合你的语言。
但是，即便如此，写实际的项目代码和了解语言的规则不是一回事。比如英语虽然是公认为语法规则相对简单的外语，但说好英语绝对不比说好另一门外语更简单多少。如果 C++ 的基本概念对你不是问题了，项目中代码出问题时能不能找出问题所在，就是考验对语言是不是真正深入掌握的时候了。这时候，语言里的一些可能比较奇怪的小规则就会暴露出来。写错一点代码的时候，动辄成百上千行的模板相关错误也会是一件非常让人头大的事情。这些都会大大拖慢开发的效率。可以这么说，C++ 开发顺利的时候，我不觉得用 C++ 开发效率会比其他语言低。但作为一个有经验的开发者，我也会碰到一些问题被卡住，这就好比虽然时速可以开到 120，但如果动不动就来了大塞车，你的平均时速就肯定上不去了。对于新手，最大的问题一是牵涉到的概念太多（恭喜你，看来这步你已经跨过去了），其次就是碰到问题不知道如何解决，或者耗时太长了。
如果大部分时间都处于停车排雷，甚至是自己给自己埋雷的状态，不觉得难才怪了。
页:
[1]