CppCon 2015: Herb Sutter "Writing Good C++14... By Default"

No captions available for this video.

Channel: CppCon

Views: 173,152

Keywords: C++14, Herb Sutter, Programming Language (Software Genre), CppCon 2015, Bash Films, Conference Video, Video Services

Id: hEx5DNLWGgA

Length: 89min 5sec (5345 seconds)

Published: Thu Sep 24 2015

Reddit Comments

[u/CUViper]

I have something that I think will be a pain point -- hope someone can reassure me.

Looking at the vector examples, slides 43-46. The rule for invalidation AIUI is that any non-const operation kills any previously acquired pointers. The examples of push_back() and reset() are clear in this regard.

So how about non-const vector::operator[]? I know this is safe for pointers, but can the compiler figure that out? (remembering that this is function analysis, not whole program, so the implementation of operator[] is a black box.)

p0 = &(*sv)[0];
p1 = &(*sv)[1]; // non-const operator[] -- invalidates p0?
*p0 = *p1 = 42; // error on dereferencing p0?

If the analysis flags this as an error, and I think it will, then I think this kind of thing will bite quite frequently. There are a lot of non-const operations that never invalidate, and the tool is going to have to learn that. More annotations?

FWIW, Rust also makes this a little hard because you can't directly borrow two &mut references, but you can get there with slice::split_at_mut().

Update: On the Rust forum, yacoder pointed out [[lifetime(const)]], which is made exactly for annotating functions that are non-const without invalidating. This is in section 10 "Lifetime-const" of the lifetimes pdf.

[u/jbandela]

While watching that talk, I couldn't help thinking. "This is a bad day for Rust."

C++ just removed/greatly diminished one of the major advantages of Rust compared with C++.

[u/boredcircuits]

Reference to a recent reddit thread at 28:45.

[u/sellibitze]

I just arrived at 1h:07m, "Overriding defaults" that involves the example of map's insert function overloads: one taking a single iterator as insertion hint which needs to be annotated with [[lifetime(this)]] to suppress warnings about possible iterator invalidation and another insert that takes a range in form of two iterators from some other container where an annotation is used to say that both iterators should refer to the same range.

This is all nice and dandy. But: Isn't the iterator abstraction inherently unsafe? Previously Sutter argued that pointer arithmetic is bad and that you should use array_view instead because -- among other reasons -- it makes bounds checking fairly easy and cheap. But C++'s iterators are a generalization of the pointer concept that includes "iterator arithmetic". What we would need is a different kind of range abstraction in the superset as a replacement for iterators analogous to array_view to keep things safe. This reminds me of Alexandrescu's "iterators must go" presentation (slides). Sure, you could add bounds checking to the iterators as well, but that would make them larger in size and smart enough in which case having two of them for a range would be redundant.

edit: Oh, at 1h:28m he mentiones the iterator/bounds problem and refers to Niebler's talk about ranges.

[u/redditsoaddicting]

At around 48:00, the error says to not dereference the pointer. However, the problem is with forming the reference rather than dereferencing the pointer. For example, this is fine:

use(*myFun());

Here, the pointer will go out of scope very soon, but not before use is done with what you give it.

[u/sbabbi]

Nice talk, just two questions:

1) Herb says that array_view has a runtime overhead, why is that? Does it do bound-checking at runtime?

2) At 33.10 he shows an example with dangling pointer to local objects. He then mentions that there are static analysis tools that are able to detect that... which tools exactly? I tried to analyze the example with clang-analyzer but it does not detect it.

[u/[deleted]]

hah I love how relieved they sound after every analysis check

[u/highfive_yo]

So basically he is listing rules for enforcing type/bound/lifetime safety which can for example for implemented by static analyzers eg. Visual Studio's static analyzer as showed in the presentation.

I am actually asking myself if this is possible with the current state of clang's static analyzer ? I had that feeling that the presentation was more focused on tools by Microsoft rather than relying on open-source implementations...

[u/[deleted]]

At 49:40 the presenter seems to 'fix' a bug (a unique_ptr returned from a function going out of scope) by saving a reference to it. Wouldn't the unique_ptr still go out of scope leaving the reference invalid?