CppCon 2016: Neil MacIntosh “The Guideline Support Library: One Year Later'

preview_player
Показать описание


At CppCon 2015 we introduced the Guideline Support Library (GSL): a set of portable vocabulary types for use constructing safe and efficient C++ programs. This talk looks at how the library has evolved in the course of one year. The talk will provide a brief review of the current set of facilities in the library, where it is available, how to build and contribute. Then the talk will look at how the library changed in response to feedback and contributions from the user community, as well as from the ISO C++ Working Group as parts of the library move through the standardization process for inclusion in the C++ standard library. The talk will cover lessons learned about how to optimize key parts of the library - such as the span<T> type - in the compiler, and what had to change in the library implementation to support this. It will present some examples of these optimizations and discuss performance of span<T>. Finally, the talk will include a status report on notable places the library is being used and preview what might be next for the GSL.

Neil MacIntosh
Principal Software Engineer, Microsoft
Neil is the lead for the C++ static analysis frameworks used widely within Microsoft, including PREfix, PREfast, and EspXtension, as well as the /analyze feature of the Microsoft C++ compiler. He is currently focused on making all these tools work better with portable C++14 code rather than nonstandard annotations. He also maintains Microsoft's implementation of the Guideline Support Library (GSL).


*-----*
*-----*
Рекомендации по теме
Комментарии
Автор

gsl::span to do checks on operator[] seems excessive. Especially, considering it has at() as well! I understand why it is done - to catch errors in old c-style code by default. But now there is no clean way to opt-out. Yes, one can replace s[index] with s.data()[index], but this is cryptic, verbose and a bit hard to search for later.
It should be added that span being slower then vector is not what people expect from a "thin wrapper". One might have written code with vector, *deliberately choosing* operator[] over at(). Moving to span to have all checks reenabled is certainly unexpected and unwanted.

YourCRTube