Good clear points. On another hand, it's a bit depressing how 20 years of the language went into just getting rid of redundant typing in C++03 for loops with a bunch of new concepts and new syntax. And it skips all the gotchas along the way.
Great talk. Good reminder of what we've got in our arsenal. And audiences are nice! One thing I can come up with at this moment that is not mentioned in the talk would be Argument Dependent Lookup. You can't be ignorant of it to play with templates. It's fire!
I think you're right. In this case, the move operation calls the Double_Data::Double_Data(const Double_Data&) overload (i.e. the copy constructor) (assuming NRVO didn't kick in first).
Why is it an "amazing feature of std::array" that it doesn't have a constructor? It makes my code very inelegant: imagine a class constructor that takes a std::array as argument, then you can not pass it a braced list of the elements. Constexpr: is "constexpr pi = 4*atan(1.0)" going to work in C++29 or so?
If you want to keep track on that progress, here is the proposal for constexpr cmath functions www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1383r0.pdf otherwise constexpr third party math libraries do exist currently. I doubt your exact syntax will ever work, but if you add auto/double etc after constexpr, then you are just a constexpr function call away. The real issue you should be complaining about is that `if constexpr` doesn't work outside of method scopes; that's the real tragedy of constexpr's current implementation.
Great talk! Can't agree with `const` being one of the best features though. The way the language let's you express read-only memory is just plain horrible.
Nice talk but wrong in so many ways that I am not interested to discuss. It its a very opinionated talk about what are the strength of C++. Lot's of love for auto but no mentioning what so ever for smart pointers, which are way more important to write sound code. And being standardised isn't really helping in writing good software. It is just helping in writing portable software. And it is somewhat dismissed by available compilers not implementing standards. Most of the time you need to figure out by experiment what your C++ compiler is able to do. Programming languages where there is only one compiler available, which is constructed by the people designing the language, set their standards by implementation. I prefer that way. I never was disappointed by a rust or swift compiler - but I found that I was very dependent on the specific version of gcc or clang to use C++ "standard" features. E.g. C++ has modules since C++20, but even setting your compiler standard to c++23 won't make it work with cmake, as the way to process modules and link to them is very compiler specific. As of now it isn't something to rely on for production code, at least not of production code supposed to be portable. If one goes into the list of supported C++ features of gcc or clang on the internet, one will find a mess. Standards do not help C++ as compiler vendors seem to adopt to them just as they feel like it.
Good clear points. On another hand, it's a bit depressing how 20 years of the language went into just getting rid of redundant typing in C++03 for loops with a bunch of new concepts and new syntax. And it skips all the gotchas along the way.
Great talk. Good reminder of what we've got in our arsenal. And audiences are nice!
One thing I can come up with at this moment that is not mentioned in the talk would be Argument Dependent Lookup. You can't be ignorant of it to play with templates. It's fire!
Way to make C++ standards history and feature introduction engaging Jason!
This was really entertaining. Thanks Jason.
11:50 you think he's joking but that's an actual and legitimate strategy for bringing templates into C....
Why is the video of the speaker not shown? In Jason's other talk I can see Jason...
@@cppnorth thank you for the event
Would Minecraft Jason be enough? :)
At 52:08, do we get a default move ctor / move assignment operator? Aren't they not declared by the compiler when the user explicitly declares a dtor?
I think you're right. In this case, the move operation calls the Double_Data::Double_Data(const Double_Data&) overload (i.e. the copy constructor) (assuming NRVO didn't kick in first).
Why is it an "amazing feature of std::array" that it doesn't have a constructor? It makes my code very inelegant: imagine a class constructor that takes a std::array as argument, then you can not pass it a braced list of the elements.
Constexpr: is "constexpr pi = 4*atan(1.0)" going to work in C++29 or so?
If you want to keep track on that progress, here is the proposal for constexpr cmath functions www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1383r0.pdf otherwise constexpr third party math libraries do exist currently. I doubt your exact syntax will ever work, but if you add auto/double etc after constexpr, then you are just a constexpr function call away. The real issue you should be complaining about is that `if constexpr` doesn't work outside of method scopes; that's the real tragedy of constexpr's current implementation.
Great talk!
Can't agree with `const` being one of the best features though. The way the language let's you express read-only memory is just plain horrible.
At minute 25 I think calculate_pi should return 22./7, not 22/7.
have you reached minute 30?
Also slide 26.9
You are correct. This bug is discussed later in the talk.
Nice talk but wrong in so many ways that I am not interested to discuss. It its a very opinionated talk about what are the strength of C++. Lot's of love for auto but no mentioning what so ever for smart pointers, which are way more important to write sound code.
And being standardised isn't really helping in writing good software. It is just helping in writing portable software. And it is somewhat dismissed by available compilers not implementing standards. Most of the time you need to figure out by experiment what your C++ compiler is able to do. Programming languages where there is only one compiler available, which is constructed by the people designing the language, set their standards by implementation. I prefer that way. I never was disappointed by a rust or swift compiler - but I found that I was very dependent on the specific version of gcc or clang to use C++ "standard" features. E.g. C++ has modules since C++20, but even setting your compiler standard to c++23 won't make it work with cmake, as the way to process modules and link to them is very compiler specific. As of now it isn't something to rely on for production code, at least not of production code supposed to be portable. If one goes into the list of supported C++ features of gcc or clang on the internet, one will find a mess. Standards do not help C++ as compiler vendors seem to adopt to them just as they feel like it.