2 HN users recommended this talk3 months2016–2018score 3
Years with an HN recommendation, 2007–2026
HN people recommend it as the starting point for modern C++ and for the language's safety story.
Bjarne Stroustrup's CppCon 2015 keynote on using C++14 to write better code, not just different code. It introduces the C++ Core Guidelines and the machine-checkable rules and GSL library behind them.
“If you want to start with modern c++ watch this” (HN, 2016)
There are some great talks by Neil MacIntosh about the kinds of static analysis they are building into the tool. CppCon 2015: Neil MacIntosh “Static Analysis and C++: More Than Lint" [link] CppCon 2015: Neil MacIntosh “Evolving array_view and string_view for safe C++ code" [link] For something of this magnitude I wouldn't consider the project late until mid summer. Stroustrup's keynote at CppCon is a great overview of the semantics they want to support and the errors that the tooling with will prevent. [this video]
Overview of the semantics and safety errors C++ tooling will catch.
You should watch those cppcon again, because Stroustrup and Herb are saying there many times that smart pointers are NOT should be use instead of raw pointers. Use smart pointers where It's about ownership. You should watch this video: [this video]
Clarifies that smart pointers are for ownership, not a replacement for raw pointers.
It's hardly modern C++ what you will see in this talk. Mike Acton even said that they only use C++ because it's game industry standard but he would prefer C. If you want to start with modern c++ watch this: CppCon 2015: Bjarne Stroustrup “Writing Good C++14” [this video]
There is this cppcon presentation by Stroustrup where he is talking about the GSL annotations [this video] but too bad that it all depends on this unreleased big black box proprietary code analysis tool.
Background upfront: I'm the guy behind the C++ interpreter and ROOT's new interfaces. I'm the co-author of the only surviving C++ reflection proposal and the author of the std::variant proposal. I have contributed to the C++ Core Guidelines ( [link] [this video] ). * HEP stores about 0.5 exabytes of data in ROOT format, that's almost exclusively serialized objects that do not know anything about TObject. * XRootD is not really specific for ROOT files. A better example would maybe be our JavaScript de-serialization library, [link] * No way will the python binding be dropped. I wonder where you got that rumor from. About one third of our users is using it. * HEP is limited by CPU resources, which is part of the reason why HEP decided to use a close-to-bare-metal language for the number crunching part. * We just made the use of python and R multivariate analysis tools with ROOT data more straightforward. * We have people from genomics etc coming to ask for help, because they cannot find a system that scales as well as ROOT does. And then we have a different perception of the direction out there. I see that Hadoop was nice but slow, Spark is nice but slow, so now things are moving to C++, see e.g. ScyllaDB. There is no reason for us to move away from it, but every reason to make it more usable. And yes, I agree that this is an issue. But many physicists do not.
Linked alongside the C++ Core Guidelines contribution.
i remember that Bjarne Stroustrup held a talk in cppcon15 where he talked a lot about the GSL library [1] - it would add type annotations that can be checked by a tool, so as to check for potential memory problems (to me that sounds like a poor man's borrow checker). One year later: i see the template library [1] but i don't see the analysis tool. Does anybody know what happened with this initiative? [1] [this video] [2] [link]
Stroustrup's GSL talk cited when asking about the analysis tool.
Stroustrup has proposed a way to add safety to C++. It's called "C++ Core Guidelines", and "GSL". [link] [link] I watched his talk -- wondering if anyone is using it. [this video] Using GSL gives adds some safety to pointers and memory allocation -- while providing the bare-metal performance that C is known for. (It still feels very low-level.)
Stroustrup's talk on adding safety to C++ via Core Guidelines.
The major issue with C++, is what also helped the language gain market adoption, copy-paste compatibility with most of C89 code. So security conscious C++ developers tend to use enum class , string, vector and array classes, RAII, iostreams, wrapping data access in classes with invariants,... Developers with more C oriented mindset, tend to just code away like "C with C++ compiler" programming style. Hence the need being discussing since the last three CppCon, to stop using C style programming in modern C++. CppCon 2015: Kate Gregory “Stop Teaching C" - [link] CppCon 2015: Bjarne Stroustrup “Writing Good C++14” - [this video] CppCon 2017: Bjarne Stroustrup “Learning and Teaching Modern C++” - [link] Of course, preventing copy-paste compatibility with C, already solves many of those issues from the get go.
One of the CppCon talks urging against C-style programming in C++.
Video list and Hacker News comment labels from HackerTube (prompted by @karpathy), released under ODC-By 1.0, built on the open-index/hacker-news archive. Hacker News data is provided by Y Combinator; comments remain the work of their authors. Video titles, channel names and thumbnails belong to their creators and are shown via YouTube. HackerTube Watch is an unofficial edition. Data export of 2026-10-31.
Plays via YouTube's privacy-enhanced embed
8 Hacker News comments
From the HN archive; up to 20 kept per video, favoring different commenters. Recommendations first.
Citations, criticism and jokes
Read more
Read more