But many places are using C++ only because something about the problem domain requires it, often performance. Understanding C++ and cpu architectures well enough to write high performance code is a completely different beast than just understanding c++ well enough to write code.
Understanding C++ syntax is a long ways from writing C++ that's not full of memory corruptions, as others have mentioned.
So it's not just "train somebody in C++", it's "train somebody in C++ and writing memory-safe C++ and writing fast C++".
const auto &foo = something(args);
…
other_thing(foo);
One can debate whether the const belongs there and how many &’s to use, but, unless something has changed dramatically in the last couple years (I’ve been focused on things that aren’t C++), there is no answer that is universally safe and efficient.
const auto &ref = v[0];
v.push_back(42);
cout << ref;
Rust will not permit this problematic usage. GC languages tend not to offer this pattern — you can reference a boxed vector element with different semantics than the above C++ code, and you mostly can’t reference an unboxed element. C++ lets you do things like this but has little ability to statically verify correctness.
(Doing the above maneuver with a vector is a bit silly: it saves typing, and indexing a vector is extremely fast. With a map, though, indexing is not so fast, and keeping an iterator or a reference around may be a big performance win. At least if you keep an iterator around, dynamic checkers have a better chance of noticing errors.)
Some times it can be pretty indirect: eg if the ref ends up pointing into some std container then it might need invalidated by making an otherwise unrelated change to the container.
“In C++ it’s harder to shoot yourself in the foot, but when you do, you blow off your whole leg.”
A C++ program with UB is just buggy. Same as a java program with bugs. The program does something you don't want it to do. That's what a bug is. The compiler isn't going to maliciously introduce code that you didn't write to order pizzas.
Compare mutating a container in a way that invalidates a live iterator: in java it's a specific exception that you can read on stack overflow, and in C++ it's just a use after free that might still appear to work correctly a random percentage of the time.
I think if you're looking to write a simple HTTP server with some API functions that talk to some RDBMS at less than 100 requests per second, yeah, C++ is pretty hygienic and safe these days.
If you need to play around with memory management strategies like non-default allocators then yeah, the knives are still very sharp and will cut you if you're not careful. This comes up a lot when writing C++ extensions for scripting languages like PHP, Python, etc and you have to interact with objects managed outside of your C++ code.
C++ these days still supports all the syntax and programming style of C++ in the 70s. You probably mean "you can program in a hygienic and safe way in C++", which is true, but also is not necessarily a feature of the language but of the programmer (just a few years ago I interacted with some theoretically senior C++ programmers who claimed mixing raw pointers with smart pointers is fine because they're senior and know what they're doing).
Ask developers to safely define a string constant that is accessible outside of that translation unit. Now do it without C++17, which many companies aren't using yet.
Things have gotten a lot better, but even these incredibly basic needs can be really tricky.
For example, while I'm not particularly fond of Python as an engineering language, I've never worked on a team with poor enough process that we deal with (eg) production runtime failures due to typo-ed variable names that would have been caught by the compiler. And yet I'd never claim that it's impossible for such a problem to exist, given arbitrary levels of talent composed in arbitrary teams and processes.
I notice this more and more in hiring process. Teams expecting new member to perfect fit wrt hard skills over soft skills. Frankly, hard skills can be taught, soft skills can’t be taught and take long time to modify behavior.
If a person is excited about technology and is familiar with translating ideas into code, that’s really all that I’m really looking for. Writing good code, understanding OS, networking etc are things that can be looked up and learned by people who are motivated to do so… there are so many resources to learn from.
One caveat here is that for “senior” hires, the expectation is opposite: not that they write perfect idiomatic code, but they’re able to write solutions. I think the practice of less technical interviews for higher level seems somewhat paradoxical: you want your Software architects and Principal Engineers to be able to code with a degree of competence.
C++ requires you to think quite a bit about memory. Modern C++ not so much. However the kind of job that requires C++ will probably require you to know some hardware / embedded which is a completely different domain than web devs and could make java / python transitions even more difficult.
You can pass everything by value, write very child-friendly C++ code, using std::map like Python dict and std::vector like Python list, and still VASTLY beat the speed of an interpreted, weakly-typed language like Python.
But nobody does that. Chances are someone on the team takes a shit about unnecessary memory copies, the code will be littered with a smattering of pass-by-reference and pass-by-pointer, there will be std::shared_ptr, std::weak_ptr, std::unique ptr everywhere, and if you're lucky some intern will have committed some C-ish C++ code that will leave you gift of memory leaks, and now all of a sudden you need everyone to understand all the nuisances of the language and how memory works.
It’s not just performance. In any moderately complicated C++ program, you will want a function to mutate its argument, and this falls apart.
Sure, you can write in a pure functional style with immutable data structures, but I wish you luck implementing an immutable data structure with asymptotically reasonable performance without using pointers of some sort.
In my experience a combination of pass-by-value with move semantics provides good code readability and almost optimal performance in most cases, so that's my default. Unless a profiler disagrees in specific cases, of course.
A map or pretty much any nontrivial data structure is not a flat region.
In any event, waiting to optimize until a profiler tells you to is a reasonable practice as long as you pay attention to scaling. It’s very easy to write, for example, a JSON parser that performs fine in small tests and has a nice small n^2 coefficient. And then someone throws in a bigger input than you tested and your game takes ten minutes to load.
Not necessarily. A hashmap can be implemented in a way it stores both the keys and values in a flat memory region, as long as keys and values are fixed size, and such a structure is way more efficient that traditional array-of-pointers implementation, where fetching each key requires following a pointer and getting the value requires following another pointer.
(IMO) C++ is quickly becoming that middle ground language that is destined to be a niche language in a decade. It's not low level enough and not high level enough to give people dealing with assembly code or business logic code a reason to switch.
>A good programmer could learn it, but it exposes concepts that python and java abstracts from the programmer.
Education varies wildly, and overall in industry you will not apply 100% of your learnings. I'm sure I forgot plenty of algorthms that others use daily. Likely, others forgot plenty of low-level memory management than I use daily.
Let's not turn this into a programmer measuring contest. They are different concepts and tools done for the purpose of solving problems, not flexing IQ's. coments like this are no better than the ones you complain about.
The unfortunate bit is - there is a lot of people that are learning Python or TypeScript that can develop that business logic as fast as you at a fraction of the cost.
Sounds like you have no idea what are you talking about. It was exactly Python project I've recently completely rearchitected, rewrote and greatly improved. Client can't thank me enough as it performs hundreds of times better than the old one. And from what the client told it was developed in less time than the original Python version.
In general I use multiple languages including Python. I just do not see anything in Python that noticeably speeds up development of big and complex projects vs modern C++ ( or any other decent language for that matter ).
You just have to know what are you doing. Language is secon
The inexperienced developer will write code that is subtly wrong. The senior developers will spend more time debugging than the time would take to write the code themselves. The new hire will effectively have negative productivity. And when the new hire has learned enough, s/he will get a new job. The comapny will not have recouped the investment on the developer.
Realistically, the majority of developers spend their days doing rather mundane work with CRUD/data-munging probably being a good description for most of it (regardless of whether it's server/desktop/mobile/web) which isn't rocket science. Now if you need an expert to write a memory management system for language X on OS Y, that's a different story.
If you are at a company with highly automated style checking, strong developer education resources, and a culture of using sanitizers all the time - you can let people learn C++ on the job.
But if you are just writing code with code review from other team members as your only option? Oof. C++ is a barrel of knives. Incredibly safe looking code can actually be filled with horrible horrible nightmare bugs.
Someone experienced in C++ will be able to pick it up a lot faster than someone transitioning from the Java world, but there's always going to be a fair learning curve for a new hire.
Is this really accurate? C++ is a very different language than even Java, not to mention Python or JS. Languages have their own quirks and attributes that often matter at some point. Especially C++.
I am on a team where we are constantly building stuff with new technologies that nobody on the team has learned, so a certain extent I understand the sentiment, but we are under no impression that we are doing that good a job at it.