Keynote: Safety in C++: All the Safeties! - Sean Parent - C++ on Sea 2023

Поділитися
Вставка
  • Опубліковано 7 жов 2024

КОМЕНТАРІ • 9

  • @paulfloyd9258
    @paulfloyd9258 Рік тому +4

    "Never reads uninitialized memory". Hmm. That's tough. All structs always 1-byte packed, no padding. No SIMD optimized string functions. How about "No outcome ever depends on uninitialized memory"?

    • @SeanParent
      @SeanParent 11 місяців тому +2

      The typical way to address this is to ensure that all memory is zero initialized. This is all at the language level of abstraction not the processor, so it is sufficient for the language not to leak information about the content of padding.

    • @paulfloyd9258
      @paulfloyd9258 11 місяців тому +1

      @@SeanParent It'll take a while to put all those worms back into the can. Will MSAN still report errors when reading such unintentionally initialized memory?

  • @bobweiram6321
    @bobweiram6321 9 місяців тому

    Ada was designed with safety in mind without minimal impact on performance and resource efficiency. Unlike C++, the programmer just writes Ada code without concerning themselves with how its semantics impacts its execution and size.

  • @qqi239z123
    @qqi239z123 11 місяців тому

    If a project has thousands of functions and each and every one of them can return a failure indication (or throw an exception) no tool can help. Every project should have some basic underling guarantees to reduce the number of failure points first, but it is not happening this way.

  • @inf0phreak
    @inf0phreak Рік тому +2

    Wow. He actually *did* mention the R word at around 24:40. I honestly expected him to continue to carefully talk around the elephant in the room.

  • @ABaumstumpf
    @ABaumstumpf Рік тому +1

    Signed integer overflow.... defining that behaviour does not make it any worse cause the compiler already is allowed to assume that it NEVER can happen which means if your code experiences overflow you ALREADY can not do anything about that. Hell because the compiler is allowed to assume it is also allowed to remove ANY AND ALL CODE that tries to check if such an overflow occured.
    The one thing this undefined behaviour does it give the compiler a bit more playroom with optimisation.
    Worse than just these problems occurring at runtime are the various things that cause "ill-formed no diagnostic required" - aka the compiler can (and mostly does) know that your code is not valid C++ but does not need to tell you and can do whatever bullshit.

    • @isodoublet
      @isodoublet Рік тому +3

      " defining that behaviour does not make it any worse cause the compiler already is allowed to assume that it NEVER can happen "
      It's the fact that it's UB that allows the compiler to assume it won't happen.

  • @raymundhofmann7661
    @raymundhofmann7661 Рік тому +1

    Interesting that governments are concerned about "memory safety" while the proposed garbage collected managed or interpreted languages as alternative are a bloated mess killing the climate and increasing the CO2 footprint by wasting CPU and memory.