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

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

КОМЕНТАРІ • 99

  • @tomkirbygreen
    @tomkirbygreen 2 місяці тому +65

    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 2 місяці тому +6

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

    • @AtomicAndi
      @AtomicAndi 12 днів тому

      @@herbsutter4340 Every time I watch a Herb talk, I feel better about C++. I guess that's what herbs are for.

    • @muhammadharris4470
      @muhammadharris4470 10 днів тому

      Just say rust 😂(safety and security)

    • @binary132
      @binary132 9 днів тому

      Yeah, Herb rules! It’s great to have a strong visible advocate for C++ when everyone is a critic.

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

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

    • @CoDEmanX47
      @CoDEmanX47 13 днів тому

      The convoluted syntax and that it might take 6 years before this is all available in C++29 is off-putting. You can do all this in Zig today, using a single keyword and easy-to-read code. I don't really see the simplification to C++.

  • @NeuwDk
    @NeuwDk 2 місяці тому +14

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

  • @ngideo
    @ngideo 8 днів тому +3

    I don't really use C++ but I love me a good talk from Herb.

  • @habits12
    @habits12 13 днів тому +2

    I really liked the knife metaphor and what may distinguish c++ from Rust in practice. Rust seems to make it a bit of a pain when you want knifes, whereas c++ lets you opt in for knifes easily when you need them. A great talk, I'm excited for the future of c++ again.

  • @emiliancioca
    @emiliancioca 12 днів тому

    Absolutely amazing talk! Thank you as always to Herb, Andrei, and all the great cpp folk involved pushing this topic forward :)
    I'm wondering if there's been any discussion around ingesting+outputting comments with the reflection utilities?
    Use case for ingesting -> Same as Unreal engine, the comments become tooltips in the UI for properties in the editor.
    Use case for outputting -> Allow generated classes/functions/members to have first-class tooltips as well in the IDE while discovering the generated code, choosing the right overloaded function, etc.
    As mentioned, if it's in the source, someone will ask for it :P

  • @AlfredoCorrea
    @AlfredoCorrea 7 днів тому

    1:29:35 the presence of a size function doesn't mean that the valid indices go from 0 to size - 1; even if the container is contiguous and random access. A container could start at 1 if it is designed to do so. For example, Boost.MultiArray can be declared (at runtime) to start at any index (typically 0, or 1, but other values are possible, for example -n/2)

  • @hbobenicio
    @hbobenicio 13 днів тому

    Awesome talk as always! Herb's and Andrei combo was incredible too! Loved it

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

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

  • @aulerleandro
    @aulerleandro 2 місяці тому +13

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

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

      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 😃

    • @CN_SFY_General
      @CN_SFY_General 10 днів тому

      C++98 and C++03 are excellent languages.

  • @pyajudeme9245
    @pyajudeme9245 13 днів тому +2

    C++20 was/is really amazing. Writing code with piping syntax and all that lambda stuff makes it as productive (short) as Python code (but much faster :-) ).

    • @ITSecNEO
      @ITSecNEO День тому

      Sadly the Compiler adoption is way too slow ._.

  • @guillaumewenzek4210
    @guillaumewenzek4210 12 днів тому +1

    If you want to play with a language similar to C++ but where all meta programming has been moved from templates to comptime reflection, there is Zig.

    • @ITSecNEO
      @ITSecNEO День тому

      Zig looks really interesting, the only problem I see is that it's not even 1.0, and even if 1.0 is reached we have to wait another long long time to see useful libraries. Even Rust is not mature enough after 10 years since release ...

  • @PaulMetalhero
    @PaulMetalhero 13 днів тому

    Herb, your work is amazing. Thank you very much!

  • @bryce.ferenczi
    @bryce.ferenczi 2 місяці тому +6

    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 2 місяці тому

      @@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 2 місяці тому +9

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

    • @herbsutter4340
      @herbsutter4340 2 місяці тому +14

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

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

      @@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?

  • @MatthewChaplain
    @MatthewChaplain 12 днів тому

    This is going to be great for things like static polymorphism where current patterns like type erasure require you to write the same thing three times and to generalize the fiddly bits like copying, allocation, SOO, etc.

  • @guai9632
    @guai9632 6 днів тому

    I'd like to hear more about thing removed rather than added

  • @OperationDarkside
    @OperationDarkside 13 днів тому

    This man knows how to excite

  • @milasudril
    @milasudril 13 днів тому

    Reflection on documentation comments. I could use field documentation to also generate a form with useful labels and tooltips. If it is also possible to generate additional files during compilation, doxygen becomes redundant.

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

    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 2 місяці тому +7

      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 місяці тому +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[]`.

  • @timokreuzer381
    @timokreuzer381 8 днів тому +1

    "We want to ... use undefined behavior, wehen we want it" - Yeah, great idea. Until you update your compiler and it decides to break your code by "optimizing" away your "intended" use of undefined behavior.

  • @sucim
    @sucim 11 днів тому

    I see direct applications for the reflection in config parsing! This would bring an end to hardcoding extracting e.g. JSON into a struct and I love it! Only downside is that it will only be usable in probably 5-10 years (for microcontrollers, GPUs etc.)

  • @mezdejek
    @mezdejek 4 дні тому

    Did they fix that std::bind placeholders so they are no longer needed? Can I write now something like:
    using namespace std;
    function< void (int) > handler = bind( object, &Object::Method );
    ?

  • @guai9632
    @guai9632 5 днів тому

    I see Alexandrescu I hit like

  • @speedstyle.
    @speedstyle. 13 днів тому

    1:12:58 _"I don't know if it's a year or a decade away before it can write the`create_instrumented_type` function"_ LLMs can already write this level of code, I've used them for similar Rust macros

  • @letsbegin_staytrue
    @letsbegin_staytrue 12 днів тому

    Hip hip hurray 🎉🎉🎉🎉🎉

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

    Its all fun and games until theres a compile error

    • @muhammadharris4470
      @muhammadharris4470 10 днів тому

      And the error caused by a template issue. Next level of hell.

    • @destiny_02
      @destiny_02 2 дні тому

      It's all fun and games until the compiler itself segfaults

  • @olivkt
    @olivkt 13 днів тому

    Wow, I usually rely on Python when such reflection is required , e.g. setattr and getattr. I am still hesitating to teach cpp20 as nowadays students really cannot understand this fuss about headers and sources.But these features look amazing.

  • @timokreuzer381
    @timokreuzer381 7 днів тому

    The constexpr factorial example is really bad. It only works, when you pass a compile time constant. But even when you forget to mark the result as constexpr, the warning goes away and it compiles just fine. The result is bogus. How is this supposed to help fix actual bugs? The common solution to all safety related issues seems to be one of "use this new stl container" or "just write correct code, then it will be safe".

  • @muhammadharris4470
    @muhammadharris4470 9 днів тому

    3 years is a long cycle, ideally 6 month iterative feature additions 🤔

  • @BillKerney
    @BillKerney 2 місяці тому +10

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

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

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

    • @krumbergify
      @krumbergify 14 днів тому +2

      @A beautiful language is much easier to understand than a messy one with lots of strange corner cases. In that sense beauty and pragmatism go together.

    • @KX36
      @KX36 13 днів тому +2

      And that's how we get horrific syntax locked into the standard for all eternity ;)

    • @hasanrasulov3502
      @hasanrasulov3502 9 днів тому

      so, standart can take decades to be in any production code😅

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

    Uffff the property thing, uffff love it :D

  • @PrzemyslawSliwinski
    @PrzemyslawSliwinski 13 днів тому

    So, since 1994, we have a virtual C++ machine within a C++ compiler?

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

    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 2 місяці тому +1

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

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

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

    • @krumbergify
      @krumbergify 13 днів тому +1

      Try the Meson build system

    • @fernwaerts
      @fernwaerts 9 днів тому +1

      @@KeyT3ch Although a standard tool would be a real gamechanger. Every other modern language does it and I strongly believe that it is a weakness of the C++ ecosystem that we don't. Java has Maven (or Gradle which is built on Maven), JS/TS have npm,yarn or a tool that is compatible to them package wise, Rust has cargo, Python pip. To have a standard tool makes development so much easier as new developers can quickly add dependencies with just a command line execution without the need of learning a new language (cmake, conan...).

    • @guai9632
      @guai9632 5 днів тому

      @@fernwaerts gradle isn't build on maven, it can grab libs from maven repos. that's it. and since maven didn' manage to do metadata right, gradle has its own format now, which can also reside in a maven repo. it would be nightmare if maven was part of the jdk

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

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

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

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

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

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

  • @timokreuzer381
    @timokreuzer381 7 днів тому +2

    The assumption of the C++ committee seems to be "Developers are smart, just give them the tools to write safe code and they will write safe code." But my experience is rather this: "Developers are stupid and lazy. Allow them to write unsafe code and they will write code that is broken in ways you couldn't even imagine is possible."

    • @rutabega306
      @rutabega306 2 дні тому +1

      They dont have a choice. The two super powers of C++ are speed and backwards compatibility.
      If you make unsafe impossible, you break speed. If you make safe default, it often means you break old programs.

    • @ITSecNEO
      @ITSecNEO День тому +1

      @@timokreuzer381 And yes, your second statement is the reality. That's the reason for the Rust hype. With my C background I would love to stay in the C family with C++, but it's so hard to justify C++ if we have languages with better tooling and better default safety features. But man, I would love a C++ where we have all the modern features and throw all the old crap out. Syntax wise, C++ is one of my favourite languages, probably cause I like C so much haha

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

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

  • @ChrisAverageYT
    @ChrisAverageYT 13 днів тому +4

    34:00 So am I reading this right that all existing code that intentionally doesn't initialize some variables will get slower by just recompiling? And to get the performance back we'll have to comb through all code and decorate it with [[indeterminate]]? That... doesn't sound good at all.

    • @AxelStrem
      @AxelStrem 7 днів тому +1

      yeah and what happened to "not paying for what you don't use" mantra
      honestly this update sounds weird

    • @mikel-zzzz
      @mikel-zzzz 6 днів тому

      yeah I was hopping someone would ask him about that... sad no-one did...

    • @destiny_02
      @destiny_02 2 дні тому

      NO, if you watch the video till the end (1:22:01) you'll realise it's not true. The "filling uninitialised memory with pattern" only takes place "just before" you do an uninitialised read (which is generally a bug, and was already UB).
      Normal use case of uninitialised variables where you declare first and initialize at later point in time will continue to work without any performance impact as long as you initialize it before reading from it.
      for whatever reason if you want to do uninitialised reads (just why?), only then you need to use [[indeterminate]]

  • @JohnUrbanic-m3q
    @JohnUrbanic-m3q 13 днів тому +3

    It is very hard to take seriously a discussion on simplification from the people that brought us to the current state. At this point, I don't think any of these guys are capable of putting themselves in the shoes of a beginning programmer, to whom this Frankenstein of a language has become incoherent.
    I am experienced and still despair any time I have to look into the standard library code. And that is without these new features. Please, stop helping!
    That is the reason that Scott Meyers has given up writing his books, and I can see why nobody else even tries. There are half a dozen accepted ways to do a loop over an array. There is no other language with this degree of schizophrenia.

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

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

  • @CN_SFY_General
    @CN_SFY_General 10 днів тому +1

    Most C++ users will not accept any attempt to limit the C++ language's ability to address (read & write) the lower metal state of processors. If someone wants to fix a memory leak or illegal memory access, a new language based on the current C++ or Java will be developed and evolve afterward.

    • @pikachulovesketchup666
      @pikachulovesketchup666 7 днів тому +1

      Why not add "unsafe" code markers and enforce security by default ? There can also be some "-fallow-shoddy-code" flag. Operator [] should always do range check (there can be unsafe_at() version), uninitialized variables should never be allowed (unless you use unsafe code block) and implicit number promotions/conversions should be disabled by default (unless you want legacy behaviour in unsafe block or opt out with compiler flag).

    • @destiny_02
      @destiny_02 2 дні тому

      ​​@@pikachulovesketchup666because c++ philosophy is performance by default, safety when required.
      bounds checking every [] access can dramatically slow down some code by factors of 2-3x. you shouldn't pay for what you didn't ask for. if you wanna ask for, .at() exists.

  • @MargaretOlivia2u
    @MargaretOlivia2u 11 днів тому +1

    Investments are the roots of financial security; the deeper they grow, the stronger your future will be."

  • @PaulTopping1
    @PaulTopping1 2 місяці тому +18

    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 місяці тому +5

      @@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 2 місяці тому +1

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

    • @pippzzz
      @pippzzz 13 днів тому

      You’re not alone!

    • @bobby9568
      @bobby9568 10 днів тому

      C++ has turned into crap because over the years they are just adding things while keeping backwards compatibility. Companies are the worst by expecting people to know C++.

    •  7 днів тому

      Circle was the way to go...

  • @doBobro
    @doBobro 8 днів тому +2

    "Why not zero-init?" IMHO the correct question: "Why a compiler doesn't make it error?" It's hilarious how c++ reluctantly continues to allow obviously incorrect programs.

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

    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 2 місяці тому

      @@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…

    • @milasudril
      @milasudril 13 днів тому

      Accept implicit conversions to and from strings. With reflection, it is possible to generate a json (de)-serializer for structs, so you could assign any struct to a string, and vice versa.

    • @KX36
      @KX36 13 днів тому

      I hate implicit conversations.

    • @mechanical_poet7673
      @mechanical_poet7673 12 днів тому +1

      Aren't pretty much all defaults wrong in C++? const, explicit, breaks in switch cases... All of those should really have been the default rather than opt-in.

  • @vilelive
    @vilelive 7 днів тому

    Is C++26 exchanging performance for type and memory safety?

    • @destiny_02
      @destiny_02 2 дні тому +2

      NO, if you watch the talk till end, he gives more details about proposal for initialisation with pattern.
      TL;DR in a code with no uninitialised reads (such reads are generally a bug), this safety proposal will have no impact on performance.
      the compiler will only fill the memory with pattern before any uninitialised read happens, this can be used to detect at runtime by sanitizers and debuggers. And realistically the compiler will warn you before that and you'll have 3 choices:
      1. uninitialised read is likely a bug, fix your code (preferred)
      2. ignore warning and let the compiler do pattern initialisation
      3. if the uninitialised read is intentional (rare case), mark the variable declaration with [[indeterminate]] attribute.

  • @thaache6
    @thaache6 9 днів тому

    *Hightime for C++ to have some AI/ML related and Quantum Computing features..*
    - by, common human

  • @bobby9568
    @bobby9568 10 днів тому +2

    This guy is sponsored by Under Armour LOL does he comes from the gym? Enjoy C++? Difficulty high, whilst managers are getting paid 10x more and work 100x less.

  • @sirnawaz
    @sirnawaz 12 днів тому +1

    45:44. LOL, the way he said "even I can't write this code correctly," implying that he considers himself almost infallible when it comes to coding...