Modern C++ Won't Save Us (2019)
101–110 of 266 posts
Re: Modern C++ Won't Save Us (2019)
#102Re: Modern C++ Won't Save Us (2019)
#103I love C++ and I’ve to admit that it will need a subset language soon but the examples given in this article wouldn’t possibly exist in well checked code-bases because you can immediately see usage stinks just by looking at it. I think every C++ is bad article can be summarised like this: 1. C++ has lots of features. 2. Let’s nonsensically combine these features to shoot ourselves on the foot. 3. Uh oh, C++ didn’t he…
Re: Modern C++ Won't Save Us (2019)
#104My comment for too many years is that C/C++ fails to deal with three issues: "How big is it", "Who owns it", and "Who locks it". C++ has, with difficulty, made progress on "How big is it" through templates, but raw pointers keep leaking out. "Who owns it" has been tough to deal with, although "owned pointers" at least try. "Who locks it" has yet to be addressed at the language level, although at least there's now som…
> three issues: "How big is it", "Who owns it", and "Who locks it" The issue with this kind of thinking is the belief that there is a "it", not "they". Say, you are writing a HTTP server [1]. A beginner mindset (what seems to be demonstrated in this post) with start allocating left and right, for every HTTP header, for every piece of string, for every piece of metadata record, etc. Thus, "how big is it" become no big…
It's really quite bad.
BUT
I'm using it professionally and it's useful. It's hard for me to mentally reconcile how good and bad the creator of Godot simulatenously was (is?).
Casey also goes way too far in his take (as usual).
RAII is a method to guarantee safety and correctness. It's useful in many many scenarios.
Game dev and c++ is a great area to hone your performance skills. And it's awesome to really squeeze the power out of a CPU, but doing that is only a small small piece of the game development journey. Ultimately, you must make a product that is entertaining.
PS: Mike Acton's talk is really only tangentially related. He's just talking about uber perf in general.
Re: Modern C++ Won't Save Us (2019)
#105I care about speed. Moderm C++ has a giant lot of features, slowly approaching to eclipsing the number of such in Java. I don't know how fast they work, how optimisable they are, and how much memory they eat. Speed is the main quality of a computer program.
Re: Modern C++ Won't Save Us (2019)
#106I hate how people group C with convos like this. Sure it has problems, but does not have any to the insanity that C++ can, let alone hiding it like C++ can. There is a reason people jokingly say C++ can blow your leg off, while C is just a foot gun. C++ is just a massively bloated language. If you need native code just use C, Rust or even assembly. Stay away from the C++.
C++ is a massively bloated language. But it is also vastly more expressive and more safe than C, and also significantly faster at runtime. It just has a stupidly high barrier to entry.
Also C++ does not have a faster runtime than C. C has hardly any run time requirements. Mainly just setting up the stack, compared to C++'s runtime requirements I don't see how anyone could claim the C++ runtime environment is faster.
Anyways, my point is that C and C++ have diverged far enough these days bundling them together is not really productive nor accurate.
Re: Modern C++ Won't Save Us (2019)
#107Earlier quoted context omitted.
I think it is fair to point out that it requires a comparatively high degree of skill and experience to use C++ well relative to many other languages. Most people do not use C++ well because doing so is quite difficult and requires a large investment of time. This is not helped by the fact that it has an enormous amount of legacy baggage that is technically valid code that no one should ever use — there is an entire…
As someone not very acquainted with C++ I was under the impression that the vast standard library was one of the great selling points of the language. What are some examples of defects that force programmers to rewrite parts of it?
Re: Modern C++ Won't Save Us (2019)
#108My comment for too many years is that C/C++ fails to deal with three issues: "How big is it", "Who owns it", and "Who locks it". C++ has, with difficulty, made progress on "How big is it" through templates, but raw pointers keep leaking out. "Who owns it" has been tough to deal with, although "owned pointers" at least try. "Who locks it" has yet to be addressed at the language level, although at least there's now som…
The quest is still valid but really, the complexity that C++ has given birth to is not worth it anymore. Other languages restarted from a blank state and are probably better bets. I almost switched to D years ago, for a while it looked like Go was going to take over but finally Rust seems to be it. My current work forced me to get into rust, and I don't think I'll go back to C++ anytime soon.
It was a fun ride. So long and thanks for the fish.
Re: Modern C++ Won't Save Us (2019)
#109Earlier quoted context omitted.
When you're writing systems software you need systems software engineers and most of them are far more competent in C/C++ than, say, Rust, Ada, Go, etc. We choose C/C++ because it's what we know and what our colleagues know, but I think a lot of us wish there was a better alternative.
Not to take away anything from your post, but Go is not a systems language. No language with a mandatory garbage collector can make that claim since it makes some systems code effectively impossible to implement.
Re: Modern C++ Won't Save Us (2019)
#110> There are significant challenges to migrating existing, large, C and C++ codebases to a different language – no one can deny this. Nonetheless, the question simply must be how we can accomplish it, rather than if we should try. Um... no. Not every (or even most ) existing large C/C++ codebase should be migrated to another language. "But security vulnerabilities! And crashes!" I admit all that. But a program can be…