3 ms·

> I find it surprising that the writers of those government documents seem oblivious of the strengths of contemporary C++ and the efforts to provide strong safe

by pornel 3y ago

> I find it surprising that the writers of those government documents seem oblivious of the strengths of contemporary C++ and the efforts to provide strong safety guarantees No, Bjarne needs to realize that RAII and smart pointers are an old concept now, and they have shown to be insufficient, for decades now. The bar for safety has been raised, and the Modern C++ is so behind, they don't even understand the issue, and still talk like it's about the C sins, or programmers not using it properly, or "but what about other bugs?". The contemporary C++ is still a safety-third design where safety always loses to performance and backwards compatibility. The std::span has been standardized without .at(), and they're just getting around to adding it. Bounds checking by default on `operator[]` is one thing where C++ could be on par with Rust right now, but that is going to be relegated to an optional profile.

deleted 3y ago
[deleted]
b20000 3y ago
not all applications need safety it is wrong to force safety onto the programmer especially if there is a cost to be paid to obtain it
- coldbrewed 3y ago
  That's an easy statement to make but in practice it's no longer acceptable; the Internet has become far too hostile and code that's "never going to be connected to the Internet" constantly does.
  - logicchains 3y ago
    [flagged]
  - b20000 3y ago
    not all devices are connected to the internet and writing software in c++ does not imply the software is unsafe
junon 3y ago
Anecdotally, I feel like I wrote safer C code because at least I fully understood the behavior of the few standard library functions I used - both the good and the bad. C++ always had that question mark of if you were fully understanding all of the invariants the library placed on you to uphold. That being said, I've fallen in love with Rust and have no intention of ever going back to C or C++.
- PartiallyTyped 3y ago
  I have a big gripe with rust and other modern languages like zig, and it’s difficult to reconcile it. The gripe is that after using them for a while, anything else like java, python, c++ or C is underwhelming, boring and tedious, an exercise in how long you can uphold standards until you fall back to language defaults.
  - pjmlp 3y ago
    What these languages show, is something anyone used to compiled BASIC, Pascal dialects like Object Pascal, Modula-2 and such, already knew back in the day. We had languages that were a pleasure to use for high level programming abstractions, while at the same time, provided the necessary features to go all the way down, even inline Assembly if it must be. Without the culture that tooling much be hard, rather developers are users as well. Thankfully a new generation of developers is bringing this culture back.
    - PartiallyTyped 3y ago
      > Without the culture that tooling much be hard, rather developers are users as well. I don't follow this. Could you elaborate? I think the current culture is that tooling must be smart, accessible, and very well written, e.g rust (cargo, rustc, clippy, rust-analyzer), go coming with everything, same for gleam. Even zig is a better build system for C programs than most buildsystems for C.
      - pjmlp 3y ago
        I am talking about the C tooling culture, specially when comparing how compilers, linkers and makefiles are exposed, versus the Xerox PARC programming model that was largely adopted by other ecosystems. Think TP, Delphi, VB, .NET, Smalltalk, Common Lisp, Clipper, Eiffel, MacOS AppToolbox, Java,...
pjmlp 3y ago
The problem is that he is shouting to windmills, because the community at large doesn't care about all the features and tooling he keeps mentioning. Also some of that tooling is still quite buggy, e.g. VC++ and clang lifetime checkers. Same applies to Herb Sutter's efforts, as of his recent blog post. It doesn't matter how much tooling there has been available on the C and C++ ecosystem, a large majority will keep programming as they always did unless forced by external factors to change their ways. Lint was created in 1979, and to this day many developers refuse to adopt static analysis on their C and C++ projects, let alone more modern tooling. Technology cannot change community culture.

by pornel 3y ago

deleted 3y ago

[deleted]

b20000 3y ago

not all applications need safety it is wrong to force safety onto the programmer especially if there is a cost to be paid to obtain it

coldbrewed 3y ago
That's an easy statement to make but in practice it's no longer acceptable; the Internet has become far too hostile and code that's "never going to be connected to the Internet" constantly does.
- logicchains 3y ago
  [flagged]
- b20000 3y ago
  not all devices are connected to the internet and writing software in c++ does not imply the software is unsafe

junon 3y ago

Anecdotally, I feel like I wrote safer C code because at least I fully understood the behavior of the few standard library functions I used - both the good and the bad. C++ always had that question mark of if you were fully understanding all of the invariants the library placed on you to uphold. That being said, I've fallen in love with Rust and have no intention of ever going back to C or C++.

PartiallyTyped 3y ago
I have a big gripe with rust and other modern languages like zig, and it’s difficult to reconcile it. The gripe is that after using them for a while, anything else like java, python, c++ or C is underwhelming, boring and tedious, an exercise in how long you can uphold standards until you fall back to language defaults.
- pjmlp 3y ago
  What these languages show, is something anyone used to compiled BASIC, Pascal dialects like Object Pascal, Modula-2 and such, already knew back in the day. We had languages that were a pleasure to use for high level programming abstractions, while at the same time, provided the necessary features to go all the way down, even inline Assembly if it must be. Without the culture that tooling much be hard, rather developers are users as well. Thankfully a new generation of developers is bringing this culture back.
  - PartiallyTyped 3y ago
    > Without the culture that tooling much be hard, rather developers are users as well. I don't follow this. Could you elaborate? I think the current culture is that tooling must be smart, accessible, and very well written, e.g rust (cargo, rustc, clippy, rust-analyzer), go coming with everything, same for gleam. Even zig is a better build system for C programs than most buildsystems for C.
    - pjmlp 3y ago
      I am talking about the C tooling culture, specially when comparing how compilers, linkers and makefiles are exposed, versus the Xerox PARC programming model that was largely adopted by other ecosystems. Think TP, Delphi, VB, .NET, Smalltalk, Common Lisp, Clipper, Eiffel, MacOS AppToolbox, Java,...

pjmlp 3y ago

The problem is that he is shouting to windmills, because the community at large doesn't care about all the features and tooling he keeps mentioning. Also some of that tooling is still quite buggy, e.g. VC++ and clang lifetime checkers. Same applies to Herb Sutter's efforts, as of his recent blog post. It doesn't matter how much tooling there has been available on the C and C++ ecosystem, a large majority will keep programming as they always did unless forced by external factors to change their ways. Lint was created in 1979, and to this day many developers refuse to adopt static analysis on their C and C++ projects, let alone more modern tooling. Technology cannot change community culture.