Peering Forward - C++’s Next Decade - Herb Sutter - CppCon 2024

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

КОМЕНТАРІ • 34

  • @tomkirbygreen
    @tomkirbygreen Місяць тому +34

    I love the positivity in this talk. We’ve spent the past few years worrying about (security and safely) and it’s eaten up a lot of conference time and head-space. This talk whilst being deeply pragmatic and entertaining looks on to new and exciting frontiers in the decade(s) to come.

    • @herbsutter4340
      @herbsutter4340 Місяць тому +3

      Thanks. There really IS a lot to be positive about!

  • @MrModez
    @MrModez Місяць тому +10

    This is insane, so many possibilities with reflection/generation! Can't wait for the complete standardization and compiler implementation!

  • @aulerleandro
    @aulerleandro Місяць тому +8

    Great presentation. If all this will be in C++26, then c++ will start to believe again in the future of C++.

    • @herbsutter4340
      @herbsutter4340 Місяць тому +10

      Thanks, I'm glad you like it! It's work by a lot of great people. Just a caution though, I did try to emphasize that the _first parts_ of this look on track for C++26 and said "fingers crossed" a few times 😃

  • @NeuwDk
    @NeuwDk Місяць тому +7

    Great talk! I'm really excited to try out C++26 and will definitely play with the new reflection and code generation constructs

  • @bryce.ferenczi
    @bryce.ferenczi Місяць тому +5

    I'm pretty keen for some form of JIT to come through at some stage. Compiling a GPU kernel for all the various data types results in massive binaries. Being able to have some template function, and then JIT for the datatype that is actually used in the user program would save a lot of binary bloat.

    • @Roibarkan
      @Roibarkan Місяць тому

      @@bryce.ferenczi Interesting. In Cppcon 2020,Ben Deane and Kris Jusiak presented some experimental JIT functionality that was once attempted to be standardized (by Hal Finkel, I believe): ua-cam.com/video/I3ov8HcdVKw/v-deo.html

  • @DataPastor
    @DataPastor Місяць тому +8

    Now it's time to open source cpp2 0.8 and onwards with a permissive licence.

    • @herbsutter4340
      @herbsutter4340 Місяць тому +11

      Thanks!
      Re open source: Cppfront is already open source! Just not for commercial use.
      Re also allowing commercial use: Coming soon😉

    • @DataPastor
      @DataPastor Місяць тому +1

      @@herbsutter4340 looking forward! Actually is there a cpp2 book in the making? It would also be helpful. Although the updated documentation is also great.

    • @gregandark8571
      @gregandark8571 Місяць тому +1

      Why cpp2 is important?

  • @franciscogeiman1776
    @franciscogeiman1776 Місяць тому +2

    Amazing talk, lot of programming pearls! Instrumented types is mindblowing...

  • @xwize
    @xwize Місяць тому +6

    Its all fun and games until theres a compile error

  • @Roibarkan
    @Roibarkan Місяць тому +2

    1:28:09 I wonder why Herb chose to constrain this to contiguous containers and not to all sized-ranges (e.g. std::dequeue or a zip_view of vectors)?
    In 1:29:29 he mentions all that’s needed is the std::size customization, which implies it will work for non contiguous sized ranges.

    • @herbsutter4340
      @herbsutter4340 Місяць тому +5

      Ah, good point -- in fact it does work just fine for contiguous views and ranges today. I shouldn't say "containers" only here. Will fix next time I give the talk, thanks.

    • @caseycarter7736
      @caseycarter7736 Місяць тому +2

      @@herbsutter4340 You might say "sized ranges with subscripting", which the Standard Library doesn't really have a concept for. Despite that the library implements it for all random access ranges it provides - it's built right into `view_interface - none of the range concepts require `operator[]`.

  • @cristianinujazznight3044
    @cristianinujazznight3044 Місяць тому +2

    Uffff the property thing, uffff love it :D

  • @Roibarkan
    @Roibarkan Місяць тому +3

    40:53 Herb’s talk from Cppcon 2017: ua-cam.com/video/4AfRAVcThyA/v-deo.html

  • @Roibarkan
    @Roibarkan Місяць тому +3

    1:26:22 Herb’s talk from 2022: ua-cam.com/video/ELeZAKCN4tY/v-deo.html

  • @Roibarkan
    @Roibarkan Місяць тому +3

    51:48 Hana on CTRE from CppCon 2019: ua-cam.com/video/8dKWdJzPwHw/v-deo.html

  • @BillKerney
    @BillKerney Місяць тому +6

    "I care less about the syntax being beautiful, I want the functionality now" lol

    • @herbsutter4340
      @herbsutter4340 Місяць тому +6

      I love beauty, but I'm also a pragmatist! 😁

  • @Roibarkan
    @Roibarkan Місяць тому +5

    22:20 Louis Dionne on STL safety in LLVM libc++: ua-cam.com/video/pQfjn7E4Qfc/v-deo.html

  • @Roibarkan
    @Roibarkan Місяць тому +2

    1:08:17 “it could also be C++” - this sounds like syn::parse in rust procedural macros!!!

  • @PaulTopping1
    @PaulTopping1 Місяць тому +9

    I appreciate the forward progress but am I the only one who sees that the reflection code looks so unintuitive? The whole language has become so complicated. Efforts like Cppfront help but we need a new C++ inspired programming languages to rise from C++'s ashes. And, no, it isn't Rust.

    • @Roibarkan
      @Roibarkan Місяць тому +2

      @@PaulTopping1 hopefully the reflection features will be composable enough that it would be possible to create reflection-using libraries which hide/encapsulate the gorry details and give us power. Again, I'm thinking/imagining things like the syn::parse library in rust

    • @KhalilEstell
      @KhalilEstell Місяць тому

      @@Roibarkan +1 to this. It is a bit complicated at first but it'll get easier the more you look at it. Reflection is already a complicated topic, just like how new grads struggle with the concept of metaprogramming or even simpler, recursion. So this complicated syntax is really a tool for advance users. The usage of it like with the class(thing) interface should make it easier and more ergonomic in code.

  • @axthd
    @axthd Місяць тому +2

    C++ needs its own build system.
    Build file written in a language similar to c/c++.
    Common tasks should be simple like
    1. Adding library
    Like if I want glfw, it should be possible to add glfw folder with new build file, add a line in main build file like libs += glfw path.
    How to build, what libs to add, what headers to made available will be communicated by build file inside glfw folder.

    • @etherstrip
      @etherstrip Місяць тому +1

      This already exists, today. This should not be part of the language.

    • @KeyT3ch
      @KeyT3ch Місяць тому +1

      There are various ways that do this in C++, conan, vcpkg, bazel, CPM.cmake, build2 etc etc.

  • @axthd
    @axthd Місяць тому +3

    Should remove implicit conversations.
    One argument constructor should be by default explicit.
    If some one needs it to be implicit, he has to mention, not the other way around.
    *AComplexClassObj = 5* it shouldn't be valid.
    That looks like JavaScript to me.

    • @Roibarkan
      @Roibarkan Місяць тому

      @@axthd I personally agree with you, but want to share a talk from SwedenC++ about the other side of the coin, on the potential benefits of embracing implicit conversions: ua-cam.com/video/bb9hPtuVaTU/v-deo.html. Potentially cool…