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

81–90 of 266 posts

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

#81

Post by andyxor »

solipsism wrote: post #63
andyxor wrote: post #42

Earlier quoted context omitted.

STL and OOP are orthogonal, e.g. you can use STL without ever using the concept of inheritance. Boost is too popular imo, and many people take it for granted when using C++ that it comes with this nice utility library to complement STL, kind of like another python package, no big deal. From what I've seen on multiple projects it creates an explosion of poorly understood (and often poorly implemented) dependencies whi…

What do you call "wisdom" that's passed from person to person, so everyone knows it, but it isn't actually true? A huge amount of Boost is nothing but headers. And it's very easy to use those header-only libraries and avoid the rest. Sure, many people have just pulled in the entirety of Boost... but it's really strange to blame Boost for those bad choices. By the way, a lot of what today is standard C++ had its origi…

well i've seen it used "enthusiastically" for the lack of better word, i.e. once someone on the team starts using one header, with some relatively well proven and robust feature (like smart pointers), it creates a temptation for them and other team members to use anything else available in that giant library "for free".

And some features there could be more experimental in nature and some are either not intended, or not really needed for a simple use case you have at hand, so unless you veto each new #include by a panel, it becomes a giant cluster fsck full of infinite permutations of advanced, and poorly understood features which creates very fragile foundation for the project and maintenance nightmare.

Since the good parts of Boost are already in STL, i always recommend to just stick with (very minimal set of) STL, don't use what you don't need right now, and avoid the temptation to throw every available library or "neat" feature at a problem (which might save a bit of thinking time short term but open a can of worms long term)

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

#82

Post by jandrewrogers »

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…

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 anti-language you have to learn too. Its standard library has many flaws such that many experienced programmers eventually write and use their own alternatives to many parts of it. These are all legitimate hurdles and criticisms, it is neither a pretty nor easy language.

The major benefit of C++ is that with sufficient mastery you can do complex things strictly, safely, and concisely that are difficult-to-impossible in any other systems language due to its flexibility and metaprogramming facilities. Its flaws are very real, but so are its strengths.

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

#83

Post by lmm »

jandrewrogers wrote: post #80
lmm wrote: post #31

Earlier quoted context omitted.

This amounts to saying that we should accept codebases continuing to contain exploitable vulnerabilities indefinitely. Perhaps for codebases that have a finite expiry date that's tolerable, but for a codebase that's expected to be maintained indefinitely I don't see how it can possibly be worthwhile - a rewrite will be a one-time cost, whereas exploitation is an ongoing cost that will surely exceed the one-time cost…

An additional issue is that some sophisticated C++ doesn’t always translate easily into other languages. It isn’t just a fairly direct reimplementation but a legit redesign. That will be a bug factory, especially for the kinds of codes that tend to be difficult to translate, as proving equivalence won’t be trivial.

I'd submit that the kind of code that's difficult to translate - that is, code where it's not clear where the responsibility for the lifecycle of a given piece of memory lies - is already a bug factory.

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

#84

Post by jandrewrogers »

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…

Modern C++ is extremely powerful, more so than any other systems language, but not simple. I’m not even a fan of the language per se, but there aren’t any alternatives currently that are as powerful or expressive and I actually use that power pretty regularly. You can’t express modern C++ in other languages with similar code gen in remotely similar lines of code, which is its unique strength.

In my experience, if you use the full idiomatic toolbox of modern C++, code mostly works the first time. That was never the case when I was writing C, or even legacy C++ (which was terrible).

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

#85

Post by anfilt »

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

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

#86

Post by jandrewrogers »

lmm wrote: post #83
jandrewrogers wrote: post #80

Earlier quoted context omitted.

An additional issue is that some sophisticated C++ doesn’t always translate easily into other languages. It isn’t just a fairly direct reimplementation but a legit redesign. That will be a bug factory, especially for the kinds of codes that tend to be difficult to translate, as proving equivalence won’t be trivial.

I'd submit that the kind of code that's difficult to translate - that is, code where it's not clear where the responsibility for the lifecycle of a given piece of memory lies - is already a bug factory.

Not at all. Modern C++ can express some memory safety and lifetime models simply and elegantly that are difficult to express in other systems languages. It doesn’t define one for you by default but it also doesn’t limit you to a single model that is clearly inappropriate for some important systems code.

The bug factory, in many cases, is a consequence of having no way to properly express lifetimes in languages that only support a single lifetime model (or no lifetime at all in the case of C), therefore requiring unsafe hacks and workarounds. If, for example, your entire address space is accessed via DMA then Rust’s memory lifecycle model breaks, and this is a canonical design characteristic of all high-performance database engines. You can trivially design C++ constructs that automagically handle lifetimes under these constraints; in other systems languages you have to do a lot of fiddly manual resource management in unsafe code blocks.

The idea that a single memory lifecycle model is appropriate or optimal for all systems applications is objectively wrong. C++ doesn’t implement other formally verifiable safety models but it provides the tools required to elegantly build applications using them and largely hide making them safe.

This is one of the well-known strengths of modern C++: the ability to implement many different formally verifiable memory safety and concurrency models as first-class constructs. Not every application needs it but some, certainly everything I work on, definitely do. I don’t disagree with the objective — I highly value the ability of the compiler to ensure that my code is safe.

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

#87

Post by ncmncm »

HexDecOctBin wrote: post #65
tejohnso wrote: post #59

Earlier quoted context omitted.

Wow, Casey doesn't hold back. Clearly, without hesitating says that 100% of code written in RAII* style sucks. Interesting considering Stroustrup considers RAII to be "the basis of some of the most effective modern C++ design techniques." I'd like to hear Casey's comments on TDD. *RAII style is lumped together with try/catch, smart pointers, tons of malloc/free new/delete

I wonder, has Bjarne Stroustrup even shipped any industrial-grade software? Because he's mostly an academic AFAIK.

Bjarne Stroustrup is a Director at Morgan-Stanley, a major investment bank in New York where software difficulties may cost millions of dollars per minute. He has described his workday as people coming to him with a difficult software engineering problem, about which he asks increasingly detailed questions until light dawns, and they go away ready to re-write the badly designed subsystem causing the trouble.

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

#88

Post by jandrewrogers »

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.

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

#89

Post by brundolf »

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…

> wouldn't it just be easier to switch languages

Unfortunately in many cases no, which is the problem

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

#90

Post by emtel »

nemothekid wrote: post #12
dataflow wrote: post #6

Earlier quoted context omitted.

> The whole point of an optional type is to prevent accidental unchecked access to the value. You might argue it should be that, but it wasn't my impression that it is that. My impression was std::optional is just there to allow for representing the absence of a value. Ideally that should be zero-overhead, which means dereferencing it should degenerate into a normal object access. Hence the current design.

> Ideally that should be zero-overhead Optionals are not zero-overhead in any other language. If you aren't going to bother checking the optional, why not just return any old pointer type? The type system should be used to enforce a contract and bypassing checks on that feels like you are just spitting in the fact of the type checker.

> Optionals are not zero-overhead in any other language.

This is a common misconception, and a pet peeve of mine. Properly designed optional types add neither space nor code-size overhead.

Consider the C function:

    foo(int* ptr) { ... }
If it is part of the API of foo that `ptr` may be null, then foo must not dereference `ptr` without verifying that it is non-null. So the body of foo must be something like:

    foo(int* ptr) {
      if (ptr != NULL) {
        ...
      }
    }
Or, take the non-pointer case:

    foo(struct S s, bool s_present) { ... }
Clearly the intent of this function is that the contents of `s` should not be accessed if `s_present` is false, so the implementation of the function must check `s_present` before inspecting `s`. (Inspecting s incorrectly wouldn't necessarily be UB, like in the previous example, but it's clearly erroneous)

The only thing that a good optional type implementation does is make it a type error to fail to do what everyone agrees both of those functions must do anyway in order to be correct. It need not increase the size of the representations, nor must it emit a single unnecessary instruction when compiled. There are plenty of languages that do this, Rust being a prominent example.

Post reply on HN