Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Modern C++ Won't Save Us (2019)

alexgaynor.net

Post reply on HN
Print view View original

161–170 of 266 posts

Re: Modern C++ Won't Save Us (2019)

#161

Post by TeMPOraL »

zone411 wrote: post #15

Clang gives a warning for the first example: :7:25: warning: object backing the pointer will be destroyed at the end of the full-expression [-Wdangling-gsl] https://godbolt.org/z/zTnjbhMqr

Yeah, and clang-tidy gives another; I just typed the first example and got both -Wdangling-gsl and "Std::basic_string_view outlives its value [bugprone-dangling-handle]" from clang-tidy.

It doesn't invalidate the point of the article, that these things perhaps should be easier to avoid, or impossible to express. You can code safe-ish C++ with high warnings settings and enough liters and static analysis tools backing you, but it's not ideal experience.

Re: Modern C++ Won't Save Us (2019)

#162

Post by flohofwoe »

HexDecOctBin wrote: post #158
nightowl_games wrote: post #104

Earlier quoted context omitted.

Game dev here. Try reading the Godot code base. It's tiny allocations all the way through. 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…

Well, I'd be surprised if the design/"entertainment" focussed part of the game is bring written in C or C++. Actually, you know what, I would not be surprised, just disappointed :) EDIT: Unless its a small indie studio, of course. In that case, do whatever works for you. Go nuts, have fun!

A fairly common way is to first implement experimental gameplay logic in a scripting- or visual-language, and once it works, extract the performance-critical parts into "proper" C++. Basically, the common lower level gameplay building blocks are written in C++, glued together by some higher level mechanism (like noodle graphs or a scripting language, and common features move into C++ as needed). Unless it's Unity, in that case, replace C++ with C#.

Re: Modern C++ Won't Save Us (2019)

#163

Post by rhn_mk1 »

127 wrote: post #129

Here's the point of view from someone who has only written 1 piece of production software with both C++ and Rust. Trying to write C++ I was constantly fighting accidental memory copies. With Rust all of this was trivial and everything works as I expect. This is pretty much the reason I chose Rust over C++. As a beginner I have no idea how I would begin to elegantly write immutable data, parallel code. With Rust it's…

While I agree with most of what you wrote, CMake feels supercharged compared to the build system part of Cargo.

Cargo is failing hard on the integration front, both on integrating things, and being integrated. build.rs is a minimal substitute of a build system: "deal with it yourself". The way Cargo wants to have total control, on the other hand, makes it hard to integrate with existing projects: those which don't use Rust at the top level.

The only great thing about Cargo's build system is that it works well on the happy path of Rust-only, crates.io-only software.

Re: Modern C++ Won't Save Us (2019)

#164

Post by klibertp »

crazypython wrote: post #28

Dlang ( https://dlang.org ) avoids all these mistakes through careful language design and compiler-enforced checks.

D is garbage collected language. I've spent the past weekend writing some toy programs in D, and it was very pleasant experience, mainly because of the GC - I didn't have to think about allocating arrays or strings, I could just use them. There are ways to circumvent the GC, like RefCounted, but the baseline is different in D and C++.

Re: Modern C++ Won't Save Us (2019)

#165

Post by flohofwoe »

jandrewrogers wrote: post #88
anfilt wrote: post #85

I 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.

C++ cannot be safer than C as long as it remains backward compatible, which would mean becoming a fundamentally different language. You can't fix a leaky pot by adding another leaky pot on top (err, or something...).

Also "significantly faster at runtime" seems like a stretch. C++ doesn't have any fundamental features over C that would affect performance (for instance, it doesn't fix the pointer aliasing problem).

Re: Modern C++ Won't Save Us (2019)

#166

Post by pornel »

DethNinja wrote: post #76

I 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…

Bugs in the article are trivially obvious, because they're in 3-line code examples, explicitly pointed out.

The problem is, the same bugs happen in actual large codebases, without the priming to look for this particular issue out of hundreds of possible issues.

It's a difference between an article saying "This is Waldo" (duuh!) and a "Where's Waldo?" game, where you don't even know how many Waldos are there.

Re: Modern C++ Won't Save Us (2019)

#167

Post by TeMPOraL »

coding123 wrote: post #21

I used to write a lot of C++ (like 14 years ago at this point). I haven't really paid any attention to it in that time. I am looking at the code examples and what I see is a language trying to adopt features from Java, Rust and others - but where in those other respective languages there's like just 1 thing going on in a single line of code. In these C++ examples you have the namespacing stuff, templates/generics, im…

> You step back and go whoa - that worked?

I did a lot of C++ pre-C++11, and then jumped back straight into C++17, and I confirm the experience of other commenters - in modern C++, "it works the first time" is normal. It wasn't in the old C++, usually when my code didn't crash after compilation, it was a sign there was a gnarly bug hidden :). But the improvements over the past ~15 years made a huge difference.

That said, even though modern C++ is a safety razor, you're still playing with a sharp object. Most of the footguns of yore are still there. Compilers got better at telling you when you're doing something stupid (I can't imagine writing C++ without turning on almost all available warnings), but if you stray away from (or abuse) the modern components, you'll have a bad day. Usually around unintentional dangling references.

The other day I did a quick refactor and managed to crash the app. Reason? I used a unique_ptr after moving from it. Compilers and liters usually catch such dumb mistakes, except in this one case they didn't (neither MSVC, nor Clang, nor clang-tidy). So you still end up overcompensating with tests, hedging against edge cases of your tooling. But it's much, much better than it was before.

> In these C++ examples you have the namespacing stuff, templates/generics, implicit operators and constructor calls.

Yeah, I have two separate pieces of opinion on it.

One, C++ is a peculiar language in which any new addition involves extreme amount of "language lawyering". I imagine the Committee and authors of high-profile libraries to be like people from Suits (the TV show) - figuring out ways to "thread the needle", navigating around all the accumulated rules to make it possible to implement a new feature, possibly with a new DSL, using only the existing features of the language. That's how you end up with ridiculously crazy mess in the templates[0].

Two, C++ is a poster child of Greenspun's Tenth Rule[3]. Standard library has drawn a lot of inspiration from Lisp over the years, and templates are essentially used as a half-working macro system these days. Some Lisp experience is actually useful here, because it lets you discover things you could do with a programming language that you never imagine you could. Knowing both the end goal and how it could be expressed in a language that was designed for it makes it easier to understand the crazier template constructs in C++.

> it just screams to me like wouldn't it just be easier to switch languages?

Maybe. If I were in charge of version 2.0 of the C++ codebase I'm working on, I'd probably consider Rust or .NET. But modern C++ is good enough, and we have good testing & QA culture, so there's no reason to change it. And for people like me, for whom C++ was their gateway to programming, it's actually somewhat pleasurable to work with.

--

[0] - Template metaprogramming is essentially its own separate language since at least C++11, but the community still isn't keen on treating it as such. I'm actually hoping C++ will adopt metaobject protoco... er[1], I mean metaclasses[2] - together with concepts (already in C++20), it might give a chance to "refactor the rules" as it is. Backwards compatibility is the sword of Damocles here, the promise to make a mess forever hanging above any improvement to the language, but the language lawyers are formidable, so maybe they'll make it work.

[1] - See the second opinion. Also https://mastodon.technology/@temporal/104120750692741713.

[2] - http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p070...

[3] - https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule - "Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp."

Re: Modern C++ Won't Save Us (2019)

#168

Post by tialaramex »

tpoacher wrote: post #123
Animats wrote: post #24

My 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…

> As a result, "unsafe" is too often used as an escape hatch when someone can't spend the time to get it right. Isn't that exactly the same as C++ then?

Every time somebody got lazy and used "unsafe" in Rust that's unavoidably annotated in the code. If the compiler can't prove it's safe and you don't label it "unsafe" it won't compile at all.

Even coming in years later, a maintenance programmer can identify this code is suspect, whereas these other parts are safe.

Whereas if you get lazy in C++ you can do whatever unsafe things you want, anywhere, and it leaves no trace.

Re: Modern C++ Won't Save Us (2019)

#169

Post by Const-me »

dbrueck wrote: post #57
FpUser wrote: post #41

Those C++ bad, complex, unsafe etc. etc articles are starting to get boring. If one wants to shoot him/herself in a foot it is fine. C++ offers countless possibilities. It (and plethora of libraries) also offers quick way to write sophisticated and performant applications without much fuss. Make your choice. I personally use C++ to great advantage and find it very productive and safe. And while being good programmer…

In a way, I agree. To me, C++ is an absolute train wreck of a language and choosing it for a new project borders on malpractice. But if people want to use it and it doesn't affect me, there's a limit to how much energy I'm willing to spend trying to talk them out of it... especially if they are a potential competitor, in which case I might nod encouragingly when I hear they're using it.

> choosing it for a new project borders on malpractice

Did it multiple times recently and I’m fairly confident in my choice. Here’s the main reasons.

1. Interoperability. If you’re writing a web service which only needs TCP sockets and local files, standard libraries of all modern languages get you covered. However, many desktop applications need to consume large C or C++ APIs implemented by operating systems. Maintaining FFI wrappers is expensive in the long run.

2. Library ecosystem. For HPC only Fortran has comparable one, for game development only C# has. The rest of the languages aren’t even close for these areas.

3. SIMD intrinsics are awesome for performance. They slowly appear in other languages, but so far, the support in C and C++ is just better. Probably because the support is first-party, by Intel and ARM.

4. Tooling is good. I use debugger, CPU and GPU profilers almost every day.

Re: Modern C++ Won't Save Us (2019)

#170

Post by zabzonk »

flohofwoe wrote: post #165
jandrewrogers wrote: post #88

Earlier quoted context omitted.

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.

C++ cannot be safer than C as long as it remains backward compatible, which would mean becoming a fundamentally different language. You can't fix a leaky pot by adding another leaky pot on top (err, or something...). Also "significantly faster at runtime" seems like a stretch. C++ doesn't have any fundamental features over C that would affect performance (for instance, it doesn't fix the pointer aliasing problem).

The poster child for C++ being faster than C is std::sort() vs qsort(). The latter requires a function pointer dereference for each call to the user-supplied ordering function - the former does not. There are many similar opportunities for C++ to be faster than C.
Post reply on HN