小白发问，都说 C++开发效率比 Java 低，但 C++的 hello world 也没多几行代码啊

[wanmyj]

#c++

#include <iostream>

int main() {
    std::cout << "Hello, World!" << std::endl;
    return 0;
}

vs

#java

public class Main {
    public static void main(String[] args) {
        System.out.println("Hello, World!");
    }
}

[flyqie]

你不能只看 hello world 啊。。

得从实际业务中体会啊。

[stimw]

口算 1+1 确实比按计算器快

[wanmyj]

@flyqie 能简单说一下吗，c++不是也有包/library 拿来直接用的吗

[murmurkerman]

效率在堆内存管理和并发编程上体现，java 是自动管理内存，c++要手动管理，智能指针之类的会限制一些写法。多线程也比较麻烦，没有官方线程池，协程。

[midasfree]

@wanmyj 1. 认识的 c 系的程序员一般都不太会直接使用开源的库, 而是参考开源自己造轮子; 2. 没有垃圾回收会导致业务对大块内存的处理逻辑变得复杂.

[abcdxe2v]

@wanmyj “也有包/library” 是也有，但是在某些领域比如说后端，可能不完善、功能少、bug 多、文档少。

[ty29022]

对比一下 grpc 的 demo
用 c++的完成队列和 java 的实现比较一下 很直观

[inhzus]

都写个学生管理系统试试就知道了

[ugpu]

直接点说法:
1. java 大量开元包导入直接用， 安全 稳定 无脑.
2. cpp ？导入进去一套用法下来 还能出问题， 简单点就是说：照着说明书用都能出问题；人的问题占大比; 毕竟那点工资招聘一个真正会 cpp 的不大可能;

效率说的是 成本 & 维护 & 招聘人员。 不是说开发效率. 管理层懂点技术的会知道 公司是有钱不是傻，要的就是可复用性; 这个可复用包括人的复用; 不是 a 走了疯狂找个 b ，b 又不愿意吃屎山代码.
java go c# 都是那几个框架 不会也愿意学; cpp...你说招进来让他们学框架二次迭代开发维护, 他们只想造轮子. 给你推翻重写, 毕竟底子在那.

[ugpu]

@ugpu 另外 市面上的都是杂牌程序员, 我也是; 喷的铁铁们别激动;
正规军是什么: 科班出生 正儿八经学习了 操作系统 数据结构 努力点在刷刷 leetcode. 以及良好的数学底子，这种人很会写代码 但是也不甘心写代码;
都用上杂牌军了，还用什么 cpp 那玩意， 半天喷不出一个屁， 老板哪里管什么效率，只知道出了点 到点要看到，别出岔子; 那不出岔子 就要稳定的库代码引用； 那就 java go c# 咯。反正全球那么多地方用过了 有问题都有问题;

[tuimaochang]

"开发效率高"是个项目完成后的最终评价，决定它的因素不仅限于开发语言的易写、啰嗦程度，还有更多因素比如：是否具有大量第三方高质量开源包避免重复造低质量轮子；在协作时开发框架是否能限制、显著减少引发崩溃的垃圾代码；等。

[lc1450]


[ugpu]

大晚上在唠嗑几句, 只是个人观点.
1: 为什么说 c++ 难，难的不是语法糖; 而是语法糖背后的意义;
file.open("file_name", a). & file.open("file_name", a+) & 写文件要 4k 对齐 为什么要 4k 对齐 因为内存 为什么内存是 4k ？那就要设计到操作系统 & 特么的在去溯源， 都特么溯源到 第一台计算机的产生了;
用 java go c# ？我管你几 k 对齐， 快速我就 github 下载 广泛推广使用;

反正老板不听历史, 所以 也别纠结学什么语言了 你需要的是一个思维 而不是学习语言； 这个思维是：
我目前做的项目 & 业务。 计算机 & 代码可以给我提供我什么帮助 让我更好的完成✅

而不是：
我要学会什么语言 这个语言什么好处 能做什么。

为什么会有这样的思维， 这是 西方国家 & 部分亚洲国家的差别;
于当代科技而言， 西方在 0-1 的节点上作出的贡献占比很大很大
亚洲地区 在 1-x 上实现的更多。
至于你说哪个牛逼你说了算。 你非要我说 我说工人阶级最伟大.

[nectar33]

实际的业务可不是 hello world 这种复杂度, 复杂度高了之后差别就很大了

[neoblackcap]

Java 自带的 string 是可用，C++标准库的 string 就是聊胜于无。
而工作中字符串操作太多了。

[ShadowPower]

C++每个第三方库都有自己的字符串实现
你可能会见到：
QString
CString
……

[agagega]

1. C++没有 GC
2. C++编译模型比较原始
3. C++构建会涉及大量依赖库、编译选项和目标平台 ABI 的细节，极容易踩坑
4. C++本身的语义就比 (一般的) Java 程序复杂，模版之类要考虑的很多，心智负担大
5. C++适用的场景，代码本来就要比 Java 更谨慎

[cheng6563]

给你段 Windows C++ 窗口开发的“hello world”，你再看看。


#include <windows.h>

LRESULT CALLBACK WindowProc(HWND hwnd, UINT uMsg, WPARAM wParam, LPARAM lParam) {
switch (uMsg) {
case WM_DESTROY:
PostQuitMessage(0);
return 0;
}
return DefWindowProc(hwnd, uMsg, wParam, lParam);
}

int WINAPI wWinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, PWSTR pCmdLine, int nCmdShow) {
// 注册窗口类
WNDCLASS wc = {0};
wc.lpfnWndProc = WindowProc;
wc.hInstance = hInstance;
wc.lpszClassName = L"MyWindowClass";
RegisterClass(&wc);

// 创建窗口
HWND hwnd = CreateWindow(
L"MyWindowClass", L"Sample Window", WS_OVERLAPPEDWINDOW,
0, 0, 800, 600, NULL, NULL, hInstance, NULL
);

if (hwnd == NULL) return 0;

// 显示窗口
ShowWindow(hwnd, nCmdShow);
UpdateWindow(hwnd);

// 消息循环
MSG msg = {0};
while (GetMessage(&msg, NULL, 0, 0)) {
TranslateMessage(&msg);
DispatchMessage(&msg);
}

return 0;
}

[cnbatch]

@ugpu 写文件 4K 对齐？对于调用标准库 fopen 、std::iostream 而言，并没有这种事。标准库的文件读写并没有 4K 对齐这种选项。
大概是想说现代硬盘的 4K 对齐吧？那是操作系统和文件系统的事情。调用标准库文件读写 API 的时候，操作系统已经帮调用者处理好背后的对齐了，调用者并不需要考虑硬盘“4K”对齐这种事。如果分区没做 4K 对齐，开发者想要干预也没法干预。

[mayli]

@cnbatch 明显是真菜，或者是故意 troll ，综合看发言前者概率比较大。大概是出租车司机水平指点程序员。。。

开发效率除了代码行数还有复杂度，简单说，c++需要显式内存管理，java 就直接 gc ，省去了最难的一部分。
你可以理解为 c++程序员一直在手动 gc ，java 程序员可以把这部分精力放在其他地方，或者聘用 java 程序员的时候，可以选择能力差一些的。

[crackidz]

Java 也不是都嫌啰嗦吗...

[zjsxwc]

cpp 要各种自己造轮子，别人的轮子与自己的不兼容。

cpp 要自己管理内存，自己对内存释放负责。

cpp 没有反射，玩不了依赖注入容器，对于元编程更是痴心妄想。

[Nosub]

c++的包管理没有，这可以劝退 90%的程序员，之前你要用第三方库，比如 FFmpeg ，要自己编译，要自己编译就要学脚本语言 cmake ，学完你发现编译一堆 error ，你不是缺少头文件就是缺少依赖，你编译完 Windows 你以为完了，Linux 下又是别的问题，c++ 20 在改变这些，不过推进速度太慢了，世面上有一些第三方库管理工具，比如微软出的 vcpkg ，其实学习 c++，相当于你学了很多语言，c/c++/cmake 。

[Nosub]

当然最大的问题是跨平台，这也是 Linux 内核开发不愿意用 c++的原因，一点点开发上的便利，不足以取代 c 语言的优势。

[codefun666]

C/C++是 native 语言，性能当然暴打 JIT 语言。

指针、内存管理、依赖对于 C/C++开发者都不是问题。

[tairan2006]

c++非常难用，到现在连个包管理都没有，std 聊胜于无，老登们又喜欢自己造轮子。语法复杂的一批，模板调试让人头秃，内存泄露和 segmentfault 让人欲哭无泪。

[wanguorui123]

主要还是生态问题，包管理，数据结构，Utils 库，Web 框架，部署便利性，还有异常处理，指针这些需要开发者的代码维护心智比较高

[jones2000]

@zjsxwc “反射”这些东西， 直接把函数地址换了就可以。c++有指针， 什么都可以搞。

[0x676e67]

这种 old 问题还有什么讨论的必要。。。

[zjsxwc]

@jones2000
你对反射一无所知，不单单只是你理解的函数与指针这么简单，qt 为了能用基础的反射还不得不搞个 moc 预先编译，转换 cpp 代码，但高级的反射功能比如运行时获取对象的完整类型信息包括但不限于私有属性、面向切面编程、根据字符串来 eval 执行、泛型与反射的结合……，这些对于 cpp 来说都是无能为力的

[wanmyj]

@Nosub C++也有 Conan 包管理呀

[574402766]

打个不是很恰当的比方
去楼下便利店买瓶水 只用走的所以有没有车公共交通方不方便没什么影响
但是要去城市另一头办点事 有车没有车公交能不能直达体验差距就大了

[v2exgo]

@0x676e67 我感觉是来骗铜币的，

[securityCoding]

你拿 c++写个 crud 就知道好不好了

[ppxppx]

主要看场景,没什么语言所有场景都很优秀。crud Java 更有效率；计算密集的高性能算法 c++实现起来更方便并且速度更快。

[WorseIsBetter]

@cnbatch #19

有的时候还是需要考虑的。

硬盘的读写以 block 为单位，每个 block 的大小通常为 512 或 4096 字节。如果一次写入不能覆盖整个 block ，那操作系统只能先把整个 block 读出来，更新后再写回去。这带来了一定的额外开销。

文件系统的「对齐」保证了每个文件的数据和元数据的起始位置在 block boundary 上，这在一定程度上避免了这个问题。如果只是简单地将一些数据顺序地一次性写到文件里，那确实没必要考虑太多，只要确保缓冲区的大小是 block size 的倍数就行。

但如果有随机写入的需求（比如要实现一个存储引擎），自己手搓 buffer 逻辑并裸调 system call 的时候，就不得不考虑。不过这跟 C++ 就没什么关系了，换哪个语言都是一样的。

[OBJECTION]

c++写起来本身就慢，外加 c++出了 crash 问题其实很难进行排查。特别是跨模块 组件之间的调用。 很多公司甚至部门之间都不相信别人的组件安全性。。

出了问题。。1/100 的概率 然后你去查吧。。 说不定还没 log 堆栈都不一定清楚

[caqiko]

两个尖角括号 + 两个冒号 第一眼看着都感觉不好理解

[xuanbg]

我同学写了一段 C 艹程序，内存溢出了。在他的代码里面，每个对象用完都释放了……但内存还是溢出了。光看代码没毛病，但是，架不住有一个对象它在释放的时候还在使用中，它释放不了啊。
Java 就基本不可能存在这种挑战认知的问题了。

[xuanbg]

后来，我建议他还是别写 C 艹了，对象这玩意他把握不住。写 C 代码就好。。。于是，内存完全自主可控，从此就再也没有内存溢出了。

[henix]

看看 https://www.v2ex.com/t/1063354 C++ 连一个简单的接口都要考虑内存释放问题，Java 就没这么多事

[junkun]

把输出换成"你好世界！"，有的时候 hello world 就能踩到坑。

[kaedeair]

@jones2000 #28 没有反射，如何获得一个特化模板对象的模板参数？

[Pony69]

op 是来骗币的🤣

[linzyjx]

心智负担大，而且由于能直接操作内存，还没有 GC ，有的时候一个不小心就踩坑了，调试还麻烦。

[kinkin666]

想锻炼自己分析 coredump 的能力，尽管用去吧

[levelworm]

写了一段自己的 C++项目，几个坑，都比较初级，大家见笑了。

第一，尽量不用 unsigned integers 作为循环的 index ，或者是任何可能需要做减法的地方，因为到了负数的时候就会溢出。这个问题其实我很早就知道，架不住有些地方没第一时间发现。比如说 if (i - 0xff > 0) 这种地方，根本就不应该用 unsigned integers 。

第二，stringstream 对 char 的处理有点特殊，不会自动转换成整数，所以如果需要显示为整数而不是字符的话，需要显式转换成整数。

第三，文件夹架构最好上来就弄好，不然改 Makefile 也蛮麻烦的。

还有几个 ImGui 的问题，因为没啥文档，只好靠搜索和读源代码解决，这里就不说了。但是基本上两三个礼拜写下来，就适应了。

内存的问题倒是没碰到，因为我都没用 new ，直接就是堆栈上建立对象，所以不担心泄漏或者指针的问题。

[bao3]

解释器的语言，帮开发者处理好了一堆乱问题，但像 C++ 这种，就需要开发者自己考虑。这就特别影响效率，即使不看项目的维护升级，光是前期的调试，真的会让人头秃。

[sofukwird]

开发生态，以前我用 nodejs 开发后台各种需要自己造轮子，换到 go 之后轮子都有，直接用就行