My talk at CppCon is now available online: “Writing Good C++14… By Default” (slides) It’s about type and memory safety for C++ — not a small target.
Definitely watch Bjarne’s keynote first. This talk is largely designed to be “part 2” of his keynote.
I’m very excited about the C++ Core Guidelines to promote modern C++14 style and this effort to achieve type and memory safety dovetails with that. Bjarne and I merged our efforts last winter, and with the help of many people brought it to this point where it’s ready to open up, and we hope this work can continue making progress.
Sutter’s Mill 
I really was electrified by Bjarne’s and your talk. Resource and type safety is definitely an issue. I have seen many libraries where even a quick view into the code easily revealed at least the one or other resource leak. What might be in there too – but hidden much “better”?
So, I like the idea of owner to ease the work for an analysis tool (compiler or external based) and I liked to see how far you already got with such a tool. But I found no information how that might work with non-pointer resources or if it is even planned to extend it in that direction. You know, we have HANDLE-s and int-s as resources too.
I would like to have a unique_owner and shared_owner for such resources somewhat like unique_ptr and shared_ptr for pointers. When I tried to sketch such a unique_owner class following the guidelines I wondered how to signal the “deleter” (CloseHandle or such) for the owned resource to the analysis tool.
Did I miss something in the GSL documentation and/or your or Bjarne’s talk? Or would we need a deleter wrapper too that signals a function object to be the equivalent of delete for a non-pointer resource type T? Or is that idea of non-pointer resources owners a bad one?
Comments appreciated!
So I looked through the paper in the core guidelines paper and all of that looks pretty fantastic. I’d love to try that out on Qt to see if the rules and the tool are suffiecently smart that the effort is reasonable.
One pattern, that is very common in Qt, is that parents take ownership of their children. To give a concrete but example, imagine a class like this: (Drastically simplified to only the memory management.)
class Thing
{
Thing(Thing *parent = 0)
{
if (parent)
parent->children.append(this);
}
~Thing()
{
for (auto child, children)
delete child;
}
vector children;
};
Now the semantics of that are, pretty obvious. If a thing has a parent, then that parent takes care of deleting its children. Otherwise the user has to take care of that Thing.
In pratice, for e.g. widgets in windows, pretty much everything has a parent and thus is automatically deleted, except for top level windows. So it does actually work pretty well.
Now, since Qt values source and binary compability a lot, we can’t really change the API, but still I would like to change it so that the tools can detect memory errors in Qt code.
The first step would probably to uses two constructors:
Thing() // needs to be assigned to a owner, or stack allocated.
Thing(NotNull) // needs to be assigend to a raw pointer
Looking at the paper I couldn’t find any way to express the comments in code or annotations for the tools though.
Any thoughs on this?
This is easily the best c++ news since I started to use it. And that was by 2002. So it is not a light assertion. Boost, C++11 and much, much more has happened since then. But this is… simply unbelievable. Great thanks to everyone, and thanks for pushing this forward.
Great presentation. Your talk and the demos with Neil brought a lot of excitement to C++. The ability to be guaranteed memory safety in C++, really takes the wind out of a lot of competitors (I am looking at you Rust) and helps with introducing C++ into new areas. Great work. Looking forward to trying out the tools when they are released.
Compile times are a serious problem in large scale C++ projects. Loading the compiler with all the diagnostics will slow compilation down even further. An external tool might be a better home for such code analysis.
Your presentation was fantastic, currently is my favorite one on CppCon2015.
Type and Memory Safety, without verbosity or heavy annotations, in current C++ is great!
Thank you guys for the effort.
Last monday I cross-compiled Rust for our ARM target and was planning on how to try to introduce it in our company.
Now my priority has changed for tommorow(monday), I have to introduce GSL in production. We use GCC 4.4.1 but with “experimental” C++11 we could use at least the non_null implementation with minor changes to replace nullptr. As you see by the compiler version, people in that big company are not very accepting to changes, hopefully to introduce a library will be a lot easier than to introduce another programming language.