Earlier quoted context omitted.
C++ has already been around for 36 years.
And COBOL was for ~40 years before starting to be left in oblivion in 2000's. Your point?
[deleted]
Does C++ still deserve a bad rap?
261–270 of 310 posts
Re: Does C++ still deserve a bad rap?
#262Modern C++ can be a joy to write, and is fine for a lot of tasks. It's hard to beat the combination of performance characteristics and higher-level constructs. The issue with C++ is that it's unsafe by default. Foot-guns abound. The right way is to make everything safe by default and provide an escape hatch when needed, e.g. Rust's unsafe or C#'s unmanaged. Unfortunately, there's no way to "fix" C++ to be safe-by-def…
IMO fixing the unsafety is impossible, because doing so would mean re-evaluating the very core idea of C++ that C is a suitable substrate for building a safe, expressive language on. We know from years of experience that C has plenty of footguns of it's own, and fixing them is not possible without a fundamental redesign of the language. Therefore, the foundation of C++ is already rotten.
If that foundation were to be redesigned one'd have to get rid of the current near-100% compatibility with C, making the interop no longer an argument for using C++. Add the fact that most real-world C++ code will also be incompatible, and the strongest argument for using C++ is gone (namely, the impressive ecosystem size and maturity).
At that point there'd be no more justification for the existence of C++ over Rust (or another language that takes Rust's good ideas and supersedes it).
Re: Does C++ still deserve a bad rap?
#263Earlier quoted context omitted.
In terms of large projects C++’s role is very much shrinking. C++’s last major strength is being cross platform, but new platforms keep excluding it. You can’t program on iOS or client side websites with it. Microsoft actively discourages using C++ on Windows, and C# took over for large projects. Essentially C++ and the modern ideas about computer security are at war.
For data-intensive applications, which are only increasing, C++ is the only game in town. State-of-the-art architectures typically rely on schedule-based safety models that are not productively expressible within Rust's ownership-based safety model, and the performance characteristics of working within these respective safety models is not comparable. There aren't many alternatives when a GC language is a non-starter…
Twitter which is at the outer edge of throughput uses Scala and Java. Language choice of just about anything being viable for what most companies consider high throughput computing. For companies spending 8 figures on hardware it’s something to consider, otherwise it’s basically irrelevant IMO.
Hell, highly optimized numerical simulations are still being written in freaking Fortran.
Re: Does C++ still deserve a bad rap?
#264Earlier quoted context omitted.
C does destructive conversions automatically, if you ask for it. E.g. unsigned n; n = 2.99; // n = 2 n = -1; // n = 2^M-1; n = 1.0E33; // undefined but not catched Both C and C++ follow the same philosopy: "Trust the programmer". The programmer is expected to use his expressive freedom, to solve performance problems and stay away from problematic constructs without being told to so. C is a systems programming languag…
> Both C and C++ follow the same philosopy: "Trust the programmer" I disagree. I think ever since it’s inception from C, C++ has tried to increase type safety and continuously move more of the work to the compiler (latest example is concepts). It does empower the programmer to do what they want: OOP, FP, GP... The philosophy of the language is mostly about abstractions. Abstracting objects, types, resource management…
The philosophy of C++ is about _zero cost_ abstractions.
Re: Does C++ still deserve a bad rap?
#265Earlier quoted context omitted.
complex c = 4; Would you rather have this line not compile because 4 is not a complex number? Because one _could_ argue that 4 is a complex number, and C++ can represent this with an implicit constructor. The issue with C++ is that implicit is the default, not that it exists.
Haskell solves this reasonably well. If your data type implements the Num typeclass, you can use literals like 4. (A typeclass in Haskell is similar to what they call an interface in Java.) There's no automatic conversion happening at all. It's done via overloading literals at compile time. (You can do the same for strings.)
C++20 introduced concepts, and now it's possible to specify type constraints, like integral, in a way similar to Haskell typeclasses.
What it doesn't solve that by default the compiler tries to find an appropriate implicit conversion. Sometimes it's convenient, sometimes it's harder to see what the code actually does.
Re: Does C++ still deserve a bad rap?
#266The thing with programming in general is that everyone will write code differently depending on how they look at the problem.
The best programming language is the one you are most familiar with. Yes you can write faster code in Ruby,Rust,Python etc but often times those languages hide soo much code, leaving you with a sparse understanding of the underlying concepts.
Language wars are not my forte but, I say use the language you are most comfortable with and become very good at using it. What takes you 30min in c++ may take me 5 min and vice versa. Happy coding!
Re: Does C++ still deserve a bad rap?
#267Earlier quoted context omitted.
Is there any language where string handling doesn't suck? (No script languages please, because they cheat by implementing the hard things on C or C++) From memory the less horrible experience i had was with Go, but there's help for the slices on the runtime which let the difficult parts hidden and also the batteries-included std library, which is one of the most well designed standard libraries out there. Buffer mana…
Strings in D are pretty nice, along with the extremely expressive range algorithms. Unicode is a slight pain (it's explicitly supported and works fine but it was designed before UTF8 dominated so there's baggage)
Ranges are an absolute pleasure to use, and besides the great template system, my favorite part of D
Re: Does C++ still deserve a bad rap?
#268Earlier quoted context omitted.
> So first, C++ in a small codebase with a small team, is a very powerful language that really does produce the best code. "Best" is such an undefined term it's word-noise here. "Best" in terms of end-user extensibility? "Best" in terms of debuggability? "Best" in terms of having a single binary which can be copied and run without regard for machine architecture and OS?
It's quite obvious that the poster was referring to codegen.
Of course not.
Re: Does C++ still deserve a bad rap?
#269Earlier quoted context omitted.
> C language has some very limited implicit type conversions What? C will happily compile this: void g() { float f = 3.14; int* ip = &f; } C++ has no such _craziness_. Your strawman actually has pretty good uses: complex c = 3i; ... = c + 4; Would you rather have the last line not compile because 4 is not a complex number? Because one _could_ argue that 4 is a complex number, and C++ can represent this with an implic…
The second case is easily solved by having an overload operator+(complex lhs, int rhs). No need to convert anything.
This fails when you want `4 + c` or `c + 4.f` etc. So you either have a gross number of overloads doing the same thing, or you just put an implicit constructor to `complex`.
Also, I agree that implicit conversions in general should be avoided, but this complex number example feels like the perfect use case.
Re: Does C++ still deserve a bad rap?
#270Earlier quoted context omitted.
Equally, a lot of people just don't know any different. How would you know C++ isn't optimal if you've never tried or thought about anything else. That and the sunk-cost of learning C++ is large.
You can't get a degree without being exposed to a number of lecturer's language-of-choice. I'd be shocked to find someone who had only used c++
Lecturers are often fairly poor programmers, which is sort of within the point I was making. You might learn Java and C++ but you'll probably be writing one in the other no matter what you do first.
I.e. my current lecturer in C programming seemed to imply we were going to be learning about object oriented programming in plain C (specifically inheritance), which does not bode well if he didn't misspeek