I write C++ for a living but feel out of the loop. Do people still select C++ for new projects? Seems a waste when so many people have put effort into replacing it with something modern. I still learn dark corners and pitfalls almost weekly. It also feels hard to tell when something is going to be a performance hit.
I write C++ for a living and I think you should give it a try. If you stick to the core guidelines and avoid 95% of the language, it's actually pretty nice. I'd prefer Rust for most things I'd use C++ for, but there are definitely areas where it shines (look at boost::hana, which gives you a unified way of handling compile time and runtime computations, for example).
I do, but only because I haven't gotten around to learning Rust yet. There doesn't seem to be all that much happening in the lean & mean with strong C FFI category (aka, the "I want to use the GPU to draw stuff" category).
I wish I could like D but I just don't, some of the decisions it made I think were mistakes.
Go's FFI story is unfortunate, and it seems too narrow in target usage anyway.
C gets a lot of rose-tinted love, but I'd never chose it over modern C++.
And... well that's sort of it, isn't it? What else is there in this area?
> I wish I could like D but I just don't, some of the decisions it made I think were mistakes.
Like what? D is everything I ever wanted C++ to be. The only reason I feel compelled to learn Rust is peer pressure, but if it were up to me, D would be the language everyone is getting excited about instead.
I don't like D's GC. I don't like its multiple modes (-betterC) which only seem to really exist because enough people didn't like the original design of D. The defaults seem off (like shouldn't functions default as @safe?)
I get a general impression of D being in just too weird of a space. It's occupying a zone somewhere between C/C++ & Java/C#, and I'm not sure that's a place I ever want to be. I'd rather just use Java/C# if I need D's feature set, and if I don't I don't want to deal with the headaches that result from trying to avoid them (or use -betterC mode which seems to just be what D should have been from the start)
Oh, the GC. I don't understand why everyone seems so hung up on that. I've never noticed it at all. Maybe I just write code where the GC doesn't matter.
I mean, I do use the GC, it's just that it's never been something that I care about, just like I don't care how exactly new and delete are implemented in C++ (are they just malloc and free wrappers? Eh, who cares.)
1) Because interop with non-GC (aka, C) code is terrible from a GC'd language. D is better here than other GC'd languages as you can still build smart pointers via RAII, but it still sucks. It's a significant mindset shift in random spots in your code.
2) Custom allocators can be hugely important in achieving certain optimizations or runtime behaviors. This can either be for just performance reasons or in some cases are mandatory for correctness such as if it's a real-time thread.
A lot of performance-sensitive code involved in game development usually eschews garbage collection, as pause times can affect per-frame performance budgets non-deterministically.
It's partially why Rust and modern C++ are getting a lot of attention in that space, as they provide a lot of higher-level niceties but don't require the overhead of a GC.
It really depends on the project. A lot of times that modern thing you're working with is just a wrapper around some C/C++ library (unless you're doing web dev - then there's a whole other set of issues).
I currently use C++17 for all new projects, in a purely modern style which minimizes the complexity that must be dealt with. It is still a very complex language to learn, I certainly don't know every corner of it.
For some types of high-performance infrastructure software like database engines, there really isn't a better alternative unfortunately. While there are other non-GC languages like C and Rust, equivalent software requires significantly more lines of code due reduced expressiveness, sometimes with a performance impact, and there are some types of code safety that are difficult to enforce in those languages.
Because C++ is so expressive in a systems programming context and is rapidly adding valuable features, it makes it difficult for other languages to catch up to the point where there is a direct architectural translation from the latest version of C++ to some other language. I know quite a few shops that actively pull their code bases forward when a new C++ version lands, which is usually pretty painless, to take advantage of new features/safety and added tidiness.
I generally avoid using C++ for new projects, despite having written a ton of it in the past.
My problem with C++ is that writing "best practices C++" in 2019 is so different from writing "best practices C++" in 2011 that it may as well be a different language. And if it's going to be a different language, I'm going to prefer a language and toolchain that started from a cleaner slate, such as Rust. For example: C++11 got rvalue and move semantics and that was pretty awesome, but it took me a ton of mental overhead to cleanly reason about interfaces where I wanted to support move semantics. I think Rust's borrowing semantics clean up a lot of C++'s memory ownership/management issues into a simpler model that I just don't have to think as hard about.
I sometimes still use C++ because it's easier to work with existing code. For example, if I am prototyping something that requires hitting OS API's, C++ is often the best combination of easily calling into the APIs while still getting modern conveniences.
reply