Day 1 Keynote - Bjarne Stroustrup: C++11 Style

Bjarne Stroustrup

[@sivabudh]

There's something very therapeutic about listening to Dr. Stroustrup. I cannot listen to conference talks while I'm coding, but with Dr. Stroustrup, I can. Lol. I don't know why.

[@gerhardwesp3995]

Great talk! My summary: - 13:20: Use simple and safe interfaces. Define your own types and use them. - 24:00 Using constexpr and operator""(), C++11 can now define new literals so that we can write Speed v = 100m / 9.8s; There is no runtime overhead. This would've saved the Mars Climate Orbiter. - 27:40: Use the RAII (Resource Acquisition Is Initialization) idiom. Try to avoid pointers. If you must use them, put them into the new C++11 smart pointer classes std::unique_ptr, std::shared_ptr right away. - 39:00 Move semantics. Return by value and define a C++11 move constructur, e.g. Matrix(Matrix&& rhs) { rep = rhs.rep; rhs.rep = {}; } - 52:40 Use standard algorithms instead of 'random code' with complicated control structure (this is where the bugs hide!). Example given with std::gather() and std::stable_partition(). - 57:50: Stay high level. Example: C++ std::sort() is safer, easier and 2.5x faster than C qsort(). Low level != efficient! - 1:01:50: Be wary of inheritance. It's been seriously overused. Do use free functions where appropriate. - 1:03:00: We have now threads and futures (async) in C++11. Use them. Example: std::thread t1{f, vec1}; std::thread t2{F{vec2}}; t1.join(); t2.join(); // Use vec1 and vec2.

[@JoshuaBehrens]

Great video. Even the Unit-Value-Example blew my mind.

[@eddiekoski]

I am so glad I saw this talk I used to think those common problems were the only way and making things safe was always ugly in c++ these simple handler idioms are beautiful and make me have hope in c++ syntax.

[@knoxjeff]

You are also correct that best practices in programming languages are progressing to being more readable and maintainable.

[@eddiekoski]

omg thank you i did not know bout those resource handlers :') made me think c++ is nasty and ugly now I know that C++ can be good and clean.

[@ChristopherJWelborn]

the braces were a typo, he said so on the first occurrence ("a compiler won't compile that, its a typo, my slides don't have to compile it, imagine thats a pointer to a Gadget"..something along those lines)

[@satishsinghal101]

Great talk. Sorry to point out a bug in slide 19 which shows up in talk at 14 minutes and 14 seconds. The first two lines of function static int compare_double (const void * p1, const void * p2) should be below double p0 = *(double *)p1; double q0 = *(double *)p2; The lines that currently show in the slide are below: double p0 = *(double *)p; double q0 = *(double *)q; There are no pointers p and q in the function static int compare_double (const void * p1, const void * p2)

[@pathless_path_hindi]

Respect to Dennis!

[@christophlinke6205]

Without Dennis work we have no C++.

[@wustafae]

I just stop to coding, get my tea and watching this nice video.

[@kevinleesmith]

It seems to me that cplusplus is like humanity. God created man man and man has the capacity for good and the capacity for evil. And so cplusplus and in fact all programming languages. Of course what is good and bad is in the eye of the beholder.

[@BumblesTheUnicorn]

I think in the part you were referring to he was saying that 'new Gadget()' was being assigned to an 'int *' would not compile, but yes, I noticed the erroneous curly braces and was wondering if that was newfangled C++11 syntax.

[@woshiqiqiye]

this totally change my mind in cpp,thks a lot

[@doug65536]

1:08:27 std::list guarantees O(1) insertion, deletion, splice. std::vector guarantees O(1) indexing. We need different containers to be able to provide those mutually exclusive guarantees.

[@dedu15]

Need to revist this doc, c++23 style when?

[@kevinleesmith]

Excellent. Vector vs list. Why do we as programmers have to choose (hopefully correct bu not unnecessarily) whether something is implemented as a list or a vector. We should be able to tell the compiler we want a block of stuff but we want the compiler to optimise for read or write or insertion etc, and let the compiler implement it as a list or a vector?

[@eddiekoski]

true to a large part , but remember stroustrups examples of what was previously good code which is now poor and not as fast such as the legacy sorting functions it is fair to say that C++ has improved overtime as well as programming techniques and I will admit I did not know good c++ especially IO but I am getting there.

[@knedlsepp]

How come the return types of f and g on slide 69 at 1:04:57 are not double?

[@theadamdonohoe]

Good to see a native-code party at Microsoft :)

[@christo161]

the graph is here stackoverflow.com/questions/13779719/should-stdlist-be-deprecated (around 45 minutes)

[@knoxjeff]

Any language can be "good and clean," it solely depends on the programmer.

[@dillip4572]

Awesome

[@allyourcode]

Um, why do the slides use braces instead of paren? Is this a new syntax? This is hurting my brain so much...

[@psingh007]

Respect Dennis Ritchie

[@majormajor658]

C++ noob dummie here. At 38:20, is the problem that the result of the operator is returned by dereferencing a pointer? If not, what exactly is to be deleted?

[@NiklasLeorn]

Fuck, the thumbnail and title hinted that this would be a Gangnam style spoof.

[@HiAdrian]

Good. Thank you!

[@hrgwea]

I noticed in the slides there are a lot of curly braces instead of parentheses. Normally I would just assume its a typing error, but since there are so many of them and since its the creator of C++ himself... makes me doubt...

[@Bozemoto]

It's new in c++11, you can use initializer list in more situations now.

[@andrewherrera7735]

@@Bozemoto That's why I like c++. Most people trip up when they see complex things, so you end up looking like a god when you know what is going on.

[@LordXelous]

You may find many listeners native to Redmond, Washington, don't cope well with his accent... if they did they may have worked for a certain company and produced better code over the last two/three decades.... Need I say more?

[@FentonReid]

Bjarne

[@Matias-Larsson]

Never mind, found out it was Redmond, Washington :D

[@cvbcresearchclarencev.b.c.]

Ok. A class without practice for the hope to be wrong.

[@TheLightmotiv]

Disappeared Graph? Maybe written in C++11?

Some of the things Bjarne describes as if they were innovative solutions to real problems have had much more elegant and obvious solutions in other languages for at least two decades. It feels a bit sad to see this. Move semantics... As an old colleague used to say: C++ is a very good assembler...

[@espressothoughts]

What's your language preference and why?

carlos chavarria I prefer Python, which obviously has a quite different sweet spot than C++. The primary reason is that Python brings me the ability to rapidly solve most problems I run into. Of course, Python programs are typically slower and be less resource efficient than the "perfect" program written in C++ to solve the same problem, but I usually reach a high quality solution with sufficient performance so much faster in Python. Development and maintenance effort is always an issue. There is certainly a space for languages such as C & C++ though, and Python is designed to be used in conjunction with C or C++, rather than instead of. If you're planning to use such a combination approach, it's doubtful that the added complexity of C++ over C is an advantage.

[@megaTherionXX]

+Magnus Lyckå I think you're wrong, as Bjarne mentioned their are a lot of different fields and for example due many issues in much embedded programming you cannot just use python or any other non deterministic language. Another thing is that if you work with real-time issue's, python isnt doing a good performance either and yet C++'s complexibility is much much needed (as Bjarne did point out, safe types etc.). For other areas of expertise which dont need much speed or efficiency, like for UIs or where anything is driven by user events, of course use python, use javascript or whatever suits your needs - no need for C++ here.

I don't know a lot of people who use Python for traditional (non-Web) user interface code, but I don't think you contradict anything I said, so I don't know why you think I'm wrong. :-) If we're e.g. on arduino, there is little to discuss, but I've seen a lot of fat server programs, with many kloc of poorly tested C++ code, performing much worse than it could. If you think through such applications, and accept slightly different specs than you initially intended, you'll typically be able to build most of them using off the shelf libraries (often open source), a fairly small amount of unique business logic, and some glue to get all the bits work together. Then you get something much simpler to maintain, and the glue is typically much easier to write in e.g. Python than C++, and it will be easier to undersand and maintain, and performance will be a lot better than the typical legacy spaghetti. I'm really not saying anything controversial here: There are mainly three ways of building large applications today: Either you run on the JVM, whether you write your main app code in Java, Scala or Clojure, or you use CLR/.NET and most probably write C#. The third option is the open source / linux approach where people use a plethora of tools, but C and C++ are typically used for writing drivers and specialized libraries. The era of C++ as a generic systems language for large applications of general computers, frontend or backend, is pretty much over. Sure it's being done, but mainly for legacy projects. This isn't primarily a matter of language features, but a matter of how we've come to approach software reuse, i.e. by reusing complete services, frameworks and libraries, and by utilizing open standards for logging, network transports, etc.

[@megaTherionXX]

+Magnus Lyckå Well maybe not completly wrong, you just made it sound as C++ is obsolete - this is (sadly?) absolutly not true. Sure if you talk primarily about web coding and repetitive "my-great-forum/shop" system applications then yes Python might be absolutly be a great language here. For everything more systematic its not being used, especially in fields where you do not want to have things like duck-typing etc. Imagine industrial applications, auto-motive etc. I just happen to work in that field, working with industrial machines, I can tell you nobody want you to program python there - even if it would be just slightly theoretical possible, it wont be accepted... and yes funnily enough its a lot harder to write good C++ code than good Python code - but this is just in the nature of things, you are writing native application and not some script where an interpreter can waste all time in guessing what you want it to do. Also you often are very constraint with memory and have to keep a low memory footprint, not just in the microcontroller world.... we also write C++ applications for thin clients which are kind-of like terminals for bigger machines. And there is nothing like open-source code for *this* world, its really hard to find anything useful you could use in the net, especially for MCUs which are not used by everybody like for example HCS12/Freescale. (And no we're writing C on them, not C++ of course) So that is why I responded with "you're wrong" because there is no certinly just some space, it is literally the industrial standard you are talking about, while python is a good language if you do some relaxed tinkering or going to university and learn programming...

[@AtomicBl453]

You just have to keep up-to-date man!

[@TheLightmotiv]

What is C++? C++ is a beast where the hidden side effects occupy 90% of the time, money and effort and only 10% of the effort are for the project. For well performing C++ software in larger projects at least 10 years of experience are required. One problem is that this C++ committees consist only of ivory tower geeks. I am tired of being told from the geeks that the ugly C++ side effects are considered as the bad use of the stupid programmer who are not sitting in the committees.

[@BrandNewByxor]

He talks a lot about how tests aren't preferable around 56mins. I think he means assert statements mixed into the code. Unit tests however are essential.

[@MarvinBlum]

18:35 ;)

[@samaursa]

Check out std::dequeue

[@griesrt]

hahahahahaha