Alex (Waffl3x)
Compiler Engineer/Code Sourcerer at BayLibre
Contributor of GCC's implementation of C++ P0847R7 Deducing this
Member of The ISO C++ committee (ISO/IEC JTC1 / SC22 / WG21)
Co-Author of P3668 Defaulting Postfix Increment and Decrement Operations
Sessions
Everyone wants to improve the code quality of GCC yet many small patches, suggested improvements, and larger refactoring projects remain unaddressed. In some cases without any updates in over 20 years! It becomes very discouraging to attempt to develop these patches when there is no set guidelines for what is acceptable. To that end, we will take a brief look at past efforts to identify the pain points of developing, reviewing, and finally approving these patches. From here we look at what we can do to reduce friction for developers and maintainers, with a focus on quantifying impacts on GCC's compile duration, run time performance and debug-ability.
In continuation from my talk on quantifying abstractions by objective costs, we also need to evaluate the more subjective costs and benefits of this work, as well as where that work should be directed. Ideally this will form the basis of a design document that developers can refer to for guidance, further reducing friction between developers and maintainers by making expectations more clear.
We will talk about and evaluate:
- acceptability and like/dislike of different abstractions and practices
- what is most important to refactor/rewrite/modernize, and the risks of doing so
- refresh our state on goals, ImprovementProjects, and rearch plans (some of this is very old)
- figure out what changes we really want
- and very importantly, what we do NOT want our code base to become
To help stimulate discussion, I will prepare examples of code with potential refactors (some intentionally bad).