CppCon 2018: John Woolverton “Interfaces Matter”

—
—
The allocation, use, and passing of memory has always had a performance cost and this has had a major impact on the evolution of the standard library and ultimately the language itself. We are rediscovering forgotten lessons from C and it is helping reshape what modern C++ looks like.

For a long time C++ has tried to work at a higher level with memory, hoping to move beyond the simple constructs C provided. The standard library promised a universe where containers are general purpose and implement the optimum algorithms, freeing engineers to focus on higher levels of design.

Delivering this vision has proved difficult. Creating a string class that performs well has been an ongoing challenge for library implementers, and as they have moved through multiple designs, the lessons learned have shaped the language itself and are instructive to anyone writing high performance code.

We will take a look at the historical attempts to address performance in the standard library and the shift away now taking place from one size fits all and non-owning interfaces, and look at the rediscovered lessons to working with memory effectively.
—
John Woolverton
Engineer, Bloomberg
—
*-----*

[seditt]

27:30 The part about tracking lifetimes. Idk why people act like it is so hard to track the lifetime of an Object. I get that is not totally what the speaker is referencing but so many others I talk to do to extreme levels. People these days seem to be under the assumption that Raw ptr for instance is a Memory leak in itself, like you are just allocating memory and pissing it away . You have to use Smart pointers or terrible things will happen yet rarely if ever do I EVER have memory leaks in my code and when I do they are detected almost immediately. If it is your code base there is zero excuse for not tracking object lifetime and leaking memory because RAII and custom object destructors makes that process about as simple as it comes. If it is someone else's code base such as for instance a large company like Googles code base that has age you should still be capable of tracking your objects lifetime with ease.

Idk, just a little rant I guess. It's just a topic that bugs me because the overhead and shear ugliness of code from smart pointers is really not worth it. Objects that are in a "Global" scope as in part of the main application and not in an object as a Member variable somewhere could benefit from smart pointers to use the Applications exit as a clean up however one should never need to use smart pointers in most other places as the overhead they require is unneeded. There is indeed overhead despite the fact that almost everyone pushing them wants to suggest there is none.