By Alisdair Meredith
One of the principles that has significantly contributed to the successful evolution of C++ over many years is the goal of full backward compatibility and support for existing code written, compiled, and distributed with earlier versions of the language. The commitment to preserving not just source compatibility, but also ABI (binary) compatibility is strong. However, as the language evolves and accumulates new features, we can reveal issues with existing features, and we wish to remove harmful or misleading behavior or to reduce the complexity of growing redundancy.
The C++ Standard has adopted a process to advertise that we would like to remove or change a feature in some future Standard, allowing developers to adapt to such revised rules and to update their code at a time of their choosing, rather than as a cost of updating to the latest Standard. We call this process deprecation.
Eventually, the time comes to remove those deprecated features, even at the cost of sacrificing compatibility with code that has not taken the chance to update. Since backward compatibility is important, we move slowly, over a period of years and multiple Standards, but eventually we will break things.
This session will inform the audience of all the ways their code might break or change meaning when upgrading their code to C++26 and of some remaining deprecated features that could be a consideration for the anticipated C++29.
Advertisement
