Typical C++, but Why? - Björn Fahller - C++ on Sea 2023

Sdílet
Vložit
  • čas přidán 29. 08. 2023
  • cpponsea.uk/
    ---
    Typical C++, but Why? - Björn Fahller - C++ on Sea 2023
    The C++ type system is both very weak and very strong. In this presentation I will show you how using the strengths of the type system makes your code better. I will show you how types...
    - prevents incorrect code from compiling
    - improves readability of code
    - reduces the risks when changing code
    and I will show you how very simple changes to your code will take you far in the desired direction.
    ---
    Slides: github.com/philsquared/cppons...
    Sponsored By think-cell: www.think-cell.com/en/
    ---
    Björn Fahller
    Björn Fahller is a senior developer at Net Insight, where he is currently coordinating the technical work of teams developing electronics, FPGA, embedded software, distributed control systems and web applications. He is keen on improving the skills of the teams he works in, by learning, and by sharing knowledge. Björn has worked full time with software development since 1994, mostly for networking products, and primarily in C++. He has also created the popular open source C++ libraries, Trompeloeil for mocking, and strong_type for type safety.
    ---
    C++ on Sea is an annual C++ and coding conference, in Folkestone, in the UK.
    - Annual C++ on Sea, C++ conference: cpponsea.uk/
    - 2023 Program: cpponsea.uk/2023/schedule/
    - Twitter: / cpponsea
    ---
    CZcams Videos Filmed, Edited & Optimised by Digital Medium: events.digital-medium.co.uk
    #cpp​ #cpponsea​ #programming​
  • Věda a technologie

Komentáře • 23

  • @tyrosinekinase
    @tyrosinekinase Před 8 měsíci +14

    What a great explanation of simple, understandable techniques for increasing readability and maintainability. We need more of these!

  • @KillerMZE
    @KillerMZE Před 7 měsíci +9

    I recently had a problem like the "a load of bool" section. I solved it using bit flags and or-ing them together. It's easier to read in my opinion, since you easily see which flags are being set, and those that aren't just don't appear

  • @kevanschwitzer8585
    @kevanschwitzer8585 Před 8 měsíci +3

    Nice talk!

  • @yourdadsbestfriend7101
    @yourdadsbestfriend7101 Před 8 měsíci +1

    these are some really nice tips!

  • @maxferger6149
    @maxferger6149 Před 6 měsíci +2

    Re "Too many default" 29:25 for C++ earlier than C++20 you may use a lambda that gets immediately evaluated. Optimizations work AFAIK.
    Example:
    auto server_socket([](){
    server_socket::config conf;
    conf.port = 1666;
    conf.address = "127.0.0.1";
    conf.nonblocking = false;
    return conf;
    }());

  • @szaszm_
    @szaszm_ Před 8 měsíci +5

    26:00 That point about not using span directly needs some justification. I don't see how you could shoot yourself in the foot with span. Just use a span of const T for read only buffers. I don't see anything dangerous in there.

  • @lhpl
    @lhpl Před 8 měsíci +4

    Congratulations! You just reinvented Ada! ;-)

  • @olafschluter706
    @olafschluter706 Před 4 měsíci

    It is funny that it took C++ standardisation 10 years to realise that named initialiser lists, introduced in C with C99, are better than constructors for structs, at least occasionally, so they should be there as an option.

  • @OldMacBonit
    @OldMacBonit Před 6 měsíci +1

    Just use Haskell (or any other language with a strict and expressive type system with a solid theoretical basis so type inference is feasible).

  • @Norman_Fleming
    @Norman_Fleming Před 6 měsíci +1

    I have been away from c++ for a while, I thought constructors should NOT throw. referring to timestamp 10:00

    • @szaszm_
      @szaszm_ Před 5 měsíci +2

      constructors should throw to signal failed object creation. Destructors should not throw.

  • @toniriikonen2544
    @toniriikonen2544 Před 6 měsíci

    It makes me a bit uneasy, thinking about these good type-system properties and then thinking of half the world using JavaScript with zero type-system.

  • @FalcoGer
    @FalcoGer Před 6 měsíci +2

    @13:20 I prefix all my enum class typenames with E. So it'd be ETrim, EPad, and ELineFeed.

  • @LunarLambda
    @LunarLambda Před 5 měsíci +1

    What an excellent advertisement for the Rust programming language

  • @brynyard
    @brynyard Před 8 měsíci +1

    Or you could maybe do something like:
    enum class format { truncate, pad_center, pad_left, pad_right, line_feed };
    void print( std::string_view, std::vector );
    print( "Corn Holio!", { format::truncate, format::line_feed } );

    • @avramlevitter6150
      @avramlevitter6150 Před 8 měsíci +1

      Alternatively, if you have a lot of booleans, you could wrap it all up into a bitset and have them be flags.
      But I think that unless you need to store/pass the conditions as a set, enums are cleaner. The vector would involve searching it for the conditions, you're forced to allocate memory, and nothing stops you from passing { truncate, truncate, truncate, truncate... }

    • @superscatboy
      @superscatboy Před 8 měsíci +3

      print("But the implementation will require an unnecessary loop, and some serious thought as to how inputs like this (which are totally valid to the type system) are handled", {format::truncate, format::line_feed, format::pad_left, format::pad_left, format::line_feed, format::pad_center, format::truncate, format::pad_right, format::pad_center, format::line_feed});

    • @TanigaDanae
      @TanigaDanae Před 7 měsíci

      Some alternative to your approach is to use flag enums
      enum class format : int {
      none = 0,
      pad_left = 1

  • @d_bud
    @d_bud Před 5 měsíci

    "There are other means to get a CVE" Hahahahah!

  • @_clemens_
    @_clemens_ Před 6 měsíci +1

    Wrong argument: I don't like this tip tbh. I don't want to read code a see 50 different types which I need to cross reference to know what they mean.
    Just write units tests for your logic, and easy logic mistakes will be captured easily (and you test on much more than simple type correctness).
    Thats also why I limit the use of "auto" for readibility where it really makes things less complicated.