Earlier quoted context omitted.
If people think C++ is hard to learn and attracts opinionated people boy are they in for a surprise when they start using Rust.
Rust is way easier to learn than C++.
The pool of talented C++ developers is running dry
771–780 of 869 posts
Re: The pool of talented C++ developers is running dry
#772Earlier quoted context omitted.
C++ is not going anywhere. All operating systems and almost all compilers for every other language (plus many of their runtimes) are written in it. When the heat death of the universe is upon us and all other languages have ceased to exist and re-emerged thousands of times over, C++ will still be here, driving the lower-most layers on top of hardware.
I declare your comment to be high quality BS. First of all I never said C++ was going anywhere. I compared it to COBOL which is still estimated to be involved something on the order of 60-80% of financial transactions. C++ has a similarly bright future. But secondly, your claim is wildly overstated. C++ is a lot less fundamental and essential than you think. Operating systems: Linux and the *BSD family are written in…
Re: The pool of talented C++ developers is running dry
#773Earlier quoted context omitted.
>C++ as a whole should be deprecated -- and no new projects should use C++ (unless for some very odd and specific reason). And what can be used instead of C++? C? If C was better, then C++ wouldn't have been invented. Rust? It's much more painful to use than C++. Zig? It's immature and has very low usage. Nim? Has very low user base. Julia? It isn't solving the same problems.
Julia is solving many of the same problems as C++. GPU compute, HPC, high performance algebra kernels are all well within Julia's purview. It's not (at least yet) good for things like writing OS kernels but there is a large amount of overlap with C++.
Re: The pool of talented C++ developers is running dry
#774Earlier quoted context omitted.
I also love Python the language, but it’s hard to keep using it when it’s so slow. Parallel processing helps, but it’s still slow. Definitely dumping pandas the first chance I get. It’s one of two major bottlenecks with the other being anaconda for Windows. Maybe the culprit is running Python on Windows since it relies on so many parts of nix?
I thought parallelism was pretty limited in python due to the GIL (global interpreter lock, iirc)?
Re: The pool of talented C++ developers is running dry
#775Earlier quoted context omitted.
As someone who has been writing C++ at Google, this exactly. Despite all the tooling, guidelines and "internal magic", C++ is still an abomination. And no it has nothing to do with memory management, I actually do like C. I love how Eric Raymond describes it as "anti-compact", because, well, it really is. C++ as a whole should be deprecated -- and no new projects should use C++ (unless for some very odd and specific…
This is exactly equivalent to saying all existing C++ programmers should be demoted to doing only maintenance work, or fired. As such, it is in violation of site terms and conditions, and damned rude.
You are not your job, and prepare yourself for listening to honest criticism of the things you base your identity around or you will find it very difficult to learn and grow.
Re: The pool of talented C++ developers is running dry
#776Earlier quoted context omitted.
> I'm still wondering why `(int)` is spelled `reinterpret_cast ` in C++ 1. because it is greppable and unsafe 2. because there is also static_cast and dynamic_cast 3. Because in C (int) is all three at once and not greppable -> C will let you do whatever, C++ will not let you do with a static_cast everything you can do with a (T) cast. All in all, it is nice to ask, but if you do not know what you are talking about e…
> 1. because it is greppable and unsafe But it is not unsafe, or rather, the C++ casts aren't more safe. They have the same semantics. There are differences casting between class types, but with numeric types the issues are how to handle the value not fitting in (or being imprecise) in the destination type. Casting a value to int in C++ that overflows is still UB. It doesn't fix C's other strange numeric issues eithe…
There are C++-style casts that are compile-time errors that C would allow you to do in C style. For C everything is potentially a reinterpret cast basically.
C++ casts are safer than C's.
Re: The pool of talented C++ developers is running dry
#777I was a C++ programmer for 25 years. Last 3 years, I'm using Rust language in my daily job and for all my hobby projects. I will not return to work in C++ again. No money can make me to change my decision. Nowadays, programming is a pure joy for me again. This was not the case when I had to work with C++.
I've drank C++'s kool aid. I believe in the vision and think of everything in C++ terms. ...I think I could last about 3 months in another language before I'd forgotten too much to go back.
Re: The pool of talented C++ developers is running dry
#778As someone who has been painfully self-teaching C++ for the last ~1.5 years on and on, these are my hangups: - The features that make C++ decent are often found in C++ 20/23, for which there are woefully few resources - Code taking advantage of coroutines and generators isn't commonplace yet, rare to find examples - C++ 20 concepts are a near mirror copy of Rust Traits and enable composition that's an alternative to…
Let's add the fact that no IDE right now fully supports C++ 20. Visual Studio comes closest, but for example modules still don't really work well.
Re: The pool of talented C++ developers is running dry
#779Earlier quoted context omitted.
they are unsafe because if you try to cast something that's not valid the compiler won't let you. you can then choose to ignore it and be unsafe, or figure out the problem and fix it.
You can still cast INT_MAX to short no matter how you spell the cast, and the result won't be correct.
If you want to narrow, you would use static cast, not reinterpret cast.
If you want to reinterpret a set of bytes as another object then you reinterpret cast (actuall use std::bit_cast, will catch more errors,). So yes, you can still do that but consciously.
In C you could even turn a cast that is essentially a static cast into a reinterpret cast by accident and the compiler would say nothing.