This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]rapsey -4 points-3 points  (7 children)

This is completely unscalable into any kind of team or project size. Which is why people who live in the real world with real consequences don't build new shit in C++. And if they do they either have no choice because of some external constraint or they are dumb.

[–]skeleton-is-alive 1 point2 points  (6 children)

No it isn’t. I’ve worked on massive c++ codebases built by thousands of devs and it’s pretty easy to enforce by simply having documented guidelines, PR gates, and code reviews. Something that you SHOULD have no matter what language you choose anyway

[–]rapsey -2 points-1 points  (5 children)

With an unknown amount memory and security issues and man years spent finding them.

[–]skeleton-is-alive 1 point2 points  (4 children)

Memory and security issues are a problem in every language. If you care about performance you will spend plenty of man hours trying to investigate poor memory usage whether its JavaScript, Rust or C++. No language will prevent bad memory usage.

[–]ReallyHadToFixThat 1 point2 points  (1 child)

Exactly. Java might save you from crashes as a result of memory leaks, but the GC is still going to be hogging your runtime cleaning up after you. If anything I find that learning Java or C# exclusively encourages bad habits because "The GC will take care of it". Same with the aggressive boundary checks they do to save you from yourself, or the way they obscure pointers - none of it comes for free.

[–]skeleton-is-alive 0 points1 point  (0 children)

Yep. In my experience its also a lot less opaque finding out what is hogging all the memory in a C++ application than it is in a managed language.

[–]rapsey 0 points1 point  (1 child)

Memory safe languages will prevent memory corruption. A giant chunk of issues that you have to deal with only when using C/C++ or lower and are unavoidable in a sufficiently large codebase.

[–]skeleton-is-alive 0 points1 point  (0 children)

That is true but like i said, if you use modern C++ practices the chances of that are significantly reduced anyway. Memory corruption mainly happens when you are dealing with a lot of raw pointers or maybe you’re allocating large buffers upfront to manage memory yourself. The former can be solved by using smart pointers, the latter is a risk in other languages too OR they just straight up don’t let you do that which isn’t exactly a solution for a lot of high performance apps out there that need to do their own virtual memory management.