How to Adopt Modern C++17 into Your C++ Code : Build 2018
Вставка
- Опубліковано 28 лип 2024
- Just how different is "Modern C++" from "legacy C++"? Is my codebase ready for C++17? Do I need a full rewrite of my app to modernize my code? If you're looking for answers to some of these questions, join us for a session on how to effectively leverage modern C++17 features in your existing C++ projects; and no, you don't need to rewrite your app.
wow, finally, a conference talk with good audio quality
This talk is incredibly good and clear. Thank you so much!
Awesome! I learned something as a long-time C++ coder.
Re-watching it second time... Well delivered material, thank you.
Love the presentation - both style and content
I like that he highlight the c++ backward compatibility
It remind me of Rust and its Rustacean. However, love it. Love the video
Great talk
I think operator* for optional is undefined behavior for empty state, if you want an exception you use .value() ala vector's operator[] and .at()
You are correct.
So the slide at 16:35 is actually wrong about this? The try/catch there is trying to handle an exception that won't actually be thrown? Instead that code is UB in the empty case?
excellent! practical! no abstract non-sense!
At 9:30, wouldn't the function that he describes be affected by return value optimization?
whoever won the spark is lucky, it's endless fun!
Nice topic :)
[About std::variant]"... except for some strange cases in which it can become empty, but that's not part of the feature." Ok, that's a great way to scare away people. Sounds VERY safe to use. Haha
Excellent
link to slide deck pls?
People always say auto makes code more readable, but for me it does the opposite. I don't like being uncertain of what type an object is.
In 2020-21 many modern IDE s will tell you the type as tooltip. The compiler and IDE know the type. Error messages may also tell you the type .. although this is less preferable form. When I first saw [auto] many years ago I was 10% hesitant, now I am less than 5% hesitant. Of course if you were reading printed copy or non IDE copy, this lack of support will make auto understanding more difficult.
@@PeterKropotkin42069 I may begin working on a recommendation for printing.. show auto as full type for printing purposes ... auto verbose print. Next I will have to present to standards committee. So much work. (I do not know what a scrub is other then the sink) Are we not all scrubs for using a computer? Full size, tablets, or cellphone? Comment creators included? My last grasp at dignity may be that I am not on sites showing aspects of a self focused person, but discussing computer and math concepts with a community. Even the compiler has help messages that are intended to be useful, rather than stating only {accepted, rejected}
@@videofountain what is the point when I can easily just specify the type myself? I genuinely don't understand. It is because you type 4 letters instead of n letters? Never heard of auto-complete? Its easier to read, easier to comprehend, and easier to write safe code if the type is always sitting there staring you in the face.
@@PeterKropotkin42069 ... Peter ... [auto] may lower the barrier to entry. .. Keywords int long bool string are quick to type. Some other types take [n] keystrokes and may not be familiar to well .... beginners. C++ is an expert friendly language. The type of the lambdas are intentionally not knowable .. so that battle is lost .. if you use a lambda.
@@videofountain C++ was my first language. All it took was reading one text book in my spare time to mostly understand all the general concepts there were to know (The book was Accelerated C++ by Andrew Koenig & Barbara E. Moo btw for anyone interested).
If you don't understand the concept of 'types' yet then you should be starting with Python until you are ready for the task instead of just leaving the types in C++ up to the compiler. The whole power of C++ comes from the fact that you are closer to the hardware, get to specify exactly how bits of memory are managed and have a full unabashed view of what each type really is.
I can't see auto doing anything but confusing newcomers. How do you look up the documentation on a data type or object you don't know or have to rely on tool tips (of all things) to know?
At 29:38, why factory() function returns an unique_ptr instead of just an object? Thanks
I think the snippet is a bit too simplistic, but you could imagine that "widget" is some base class.
The only way for the factory to return a subclass of widget would be through a heap allocated object.
Heap allocation for "gadget" in this snippet however does not really make sense I don't think.
Because the factory is giving ownership of the object to the caller.
I find the syntax of shared pointers so cumbersome compared to raw pointers. And the limitation to non circular refs makes it seem a bit hacky.
Kendra Dog It feels not only like that it is a hack. If we want ref_counter we should use swift the language integrates seamlessly with 'smart_ptrs' and was designed by a guy that knows what he is doing (He is the inventor of LLVM wich uses heavily C++).
The problem is that you can't use SWIFT without reference counting. And thats why it's still an application langauge and you don't see hard and never will see algorithms implemented in it (like compression, graph analysis, database implementation). Reference counting is slow, even with compiler help eliminating a few.
Lothar Scholz The thing is everything should be a smart pointer thats a least what i find that the try to say wich makes it also very slow.
What he says is, we need to hire cheaper and more stupid programmer who never learned careful memory management programming and debugging and managers who cut down the time for debugging and testing because the agile development cycle is now 4 just weeks. It's not only slow, he also forgets to mention that each shared pointer is now 16 byte (4 pointers) + about 32 byte per shared object (the reference control block to which the 2nd pointer points). Add this to all the other size increases thanks to excessive unoptimized C++ templates and std::string and other space consuming stuff and we really have a competitive reason to use "dinosaur-C++".
@@llothar68
If you have a reason to heavily lean on optimization and such, you should write your own STL and that's been true for a long time. When you don't have reason to do this you will use modern c++ and all of its features. Nothing has changed in that sense for last 10 years.
good watch
Hello, can anyone please explain what the 's' does in the code a = "xyzzy"s; on the slide with "any". I see it is a method to convert char * to std::string, but could anyone point to the documentation how it is done?
std:string literal suffix ... month later ... please try those keywords as a search
I see Herb Sutter, I give a thumbs-up
std::optional will not through on dereference (according to cppreference). I mean, it could, but it would be a bad implementation. It’s undefined behaviour.
Herb probably said this for simplicity. Or this is what Microsoft does unless you beat it over the head with some compiler flag.
I wonder if this was something that changed between when the feature was proposed and when it was standardized. It seems like Herb's slide at 16:35 is trying to catch an exception that can't actually be thrown there, and it needs to be corrected to call .value().
So... is it a good idea to make a strong type language a weak type language via autoing everything? Do we really need unit test for a strong type oo language? Doesn't making it weak types require you to always unit test?
c++ is still a strong typed language. Using 'auto' takes advantage of type deduction done by your compiler. The benefits of type deduction is it's a bit easier to write (you have to get used to seeing the type on the right instead of the left), and you cannot declare a variable without initializing it first.
int x; // C++ allows you to do this? What is the value of x right now? Be careful!
auto y = 5; // The compiler knows this is an int because 5 is an int. Strongly typed!
auto z; // Does not compile! The compiler doesn't know what type this is.
By using auto and type deduction you can avoid the pitfalls of uninitialized variables while still being as strongly typed as you were before.
I cant see any GUI having a million widgets :D
I'm seeing a lot of ideas shared with Rust.
With Typescript aswell
I don't like the emphasis in all this new stuff on avoiding explicit typing. auto, IMO, is just crazy to figure out errors waiting to happy. No one, reading that code later, knows what type I meant that to be. If I indicate the type, then both I and the compiler know that this thing needs to be of this type. That's the entire point of type safety.
There's no reward for writing the code fastest. It's about code that is robust over time. The less explicit you are, the less the compiler is watching your back year after year. It's a retrograde step IMO.
Obviously I appreciate that it's useful in some of the crazy templating stuff that goes on how, where people are jumping through all kinds of hoops to make things happen. But just in general usage to avoid actually actually saying the type. That's just not a good choice.
Couldn't agree more. If you just saw the code on the right hand side at minute 6 (like in a code review, for example), you'd have a hard time to understand what is going on.
I am waiting for c++ to be stable for me to start learning it... Stability and "standard-ness" are keys!
stable? What the heck are you talking about?
@@akj7 ...}’ and ‘std::ostream {aka std::basic_ostream}’)
I mean "standarised"... No need to get mad, but many concepts get deprecated once in while...
One year ago I compiled a code containing this very line: "if (ostr != cout) {/*doSomething*/}"
And now, it is asking me to templat-ise the declaration:
error: >>no match for ‘operator!=’ (operand types are ‘std::ostream {aka std::basic_ostream
@Peterolen thank you for making that point clear.
@Soyel What I meant is the fact that code which is only year or so old got broken because it calls a library that happens to be updated according to c++14... The point is why even that importan to go from c++11 norms to higher ones just to add some few almost meaningless features!!
This looks a lot like typescript
:)
4:24 I DON'T CARE! There are at least 4 different ways to initialize an object. Please pick one and mark the others as deprecated
There are more than 4. So lets count.
T x;
- If x is global, it is zero-initialized and then default-initialized (1)
- If T is a class and has a default constructor, its default constructor is called (2)
- If T is an array, its members are default-initialized (3)
T()
- Value-initializes a temporary object
- If T is a class with an implicitly defined or defaulted default constructor, it is zero-initialized (4)
- If T is a class with a deleted or user-provided default constructor, it is default-initialized (5)
- If T is a class with no default constructor but with a constructor taking a initializer_list, it is list-initialized (6)
- If T is an array, its members are value-initialized (7)
- In other cases the temporary is zero-initialized (8)
T x = T()
- Same as above, but then copy-initializes x from the temporary (9)
T{}
- Same as 4-8, except
- If T is an aggregate type, the temporary is aggregate-initialized (10)
T x = { list }
- If T is an aggregate, then
- If list is a single object of type T then x is copy-initialized (11)
- Otherwise, x is aggregate-initialized (12)
- If T is a class, then
- If list empty and T has a default constructor, x is default-initialized (13)
- If T is a specialization of initializer_list, x is copy-initialized from list (14)
- If T has a constructor that takes an initializer_list as its only mandatory argument, x is thus initialized (15)
- Otherwise, all constructors of T are considered for overload-resolution based on the arguments in list. (16)
- If T is a character array and list is a single string literal, it is initialized from the string literal (17)
- If list has one element and either T is not a reference type or is a reference type whose referenced type is same as or is a base class of the type of the element, ... uhm... then it is copy-initialized (18)
- If T is a reference type that is not compatible with the type in list, it is direct-initialized from prvalue that is generated and copy-initialized from list (19) Okay, you know what? To hell with this fucked up language. I'm a programmer. Not linguist on mushrooms like the c++ designers.
I would be glad if I can get some assistance with visual studio c++ 17. I continue to get errors after following simple instructions. I know you this should not take you long. I do not mind you remoting in using team viewer if you would not mind. I am in school online and had death in my family and have gotten far behind. I am going to school for self driving cars and do not want to miss my chance of completing this course. I am really seeking help. I am not looking for anyone to do my work just to help me with the errors that I am having. Thank you in advance.
Is my code ready for another relase of Visual Studio? Complies to ANSI - check. Gives 0 warnings - check. Follows latest reocmmendations to date - check. Has portable project settings - check. Upgrading to another VS. 100% failure. Importing older projects is as useless as ever. I hate Microsoft.
This is not making me regret that I dumped C++ 20 years ago and switched to better designed languages.
What languages did you switch to? I must say, I don't see C++ as poorly designed, but more like a complex language with a lot of things you need to be careful with.
I guess python and C are top of my SW list. But I focused on improving my grasp of algorithms and language features and have had to use several different languages in production. No one tells me what to use these days and I always fall back to python for getting things done. I have high hopes for Jai - the build and compile time execution seem compelling. My work is in cryptographic hardware design and C++ is treacherously complex for writing resilient crypto code. The difference between making it work and only making it work the way it's intended to is substantial.
Python and C are both even worse than C++
@@DavidJohnston_deadhat I'm sorry to say I cannot agree. I think that of the low level languages, cpp is one of the ones that allows me to follow most programming paradigms and allow me to write optimized clear code, especially with the modern STL and language features introduced in c++17. I love C too, python is awesome for many things including IoT, data science and machine learning.
I have to disagree though C++ is clearly lacking library support in many areas (e.g. networking, xml, graphics, gui, serialization, database). They are working on it but it goes slowly.
Very old talk, he gave this on the Cpp Con in 2016.
There is no real C++17 specific stuff. Don't waste your time.
Lothar Scholz But the date on the video on the bottom left clearly showed May, 2018.
Talk in english referres also to the content, he said the same at Cpp Con 2016 and surely at multiple other events. And there is nothing new in this content.
std::variant, std::any, std::string_view, std::optional... Because those were totally not introduced in C++17.
I think C++ 98 was just fine,
huge software was written with it and is set instone.
in order to maintain it people need to know c++98 and C ANYWAYS.
On top of all the existing complexity (it is complex) they added this extra layer of stuff that "help" you do the same things you did before with YET another way.
Unnecessary, the only benefit is the new $$$ Bjarne and his gang are going to make selling "NEW" books or making lectures over semantics.
C++ can be very simple, and can be very complicated it all depends on the programmer.
With Go I don't need to buy a book, just saying.
But it does not have generics
it's also slower and lacks dozens of features that are found in modern C++
and it does not have generics
Neither do you in C++. Just use a rare thing called Google.