Heads up about future standards annexing new identifiers
As facilities get added to the standard library, they need names. When this happens, it restricts what other developers can and cannot do in their programs. For example, one cannot do this and expect most anything in the standard library to work: #define allocate(T) . new T [ But you knew about that ]. What you may not have known about was that the standards committee has voted contract enforcement/checking facilities into the draft standard (which will probably be C++20). This includes attributes named: 'expects' and 'ensures'. (all lower case) I have checked all of boost, and with the possible exception of Boost.Contract, we do not have any macros with those names. But you might want to keep your eyes open. -- Marshall P.S. These are not keywords - so it's perfectly fine to have member functions with these names. Variables, too. Probably even free functions - though I haven't tried that. But macros are right out ;-) P.P.S. For people who are interested, the paper is http://wg21.link/P0542
On 7/16/2018 6:08 PM, Marshall Clow via Boost wrote:
As facilities get added to the standard library, they need names. When this happens, it restricts what other developers can and cannot do in their programs.
For example, one cannot do this and expect most anything in the standard library to work:
#define allocate(T) . new T
[ But you knew about that ].
What you may not have known about was that the standards committee has voted contract enforcement/checking facilities into the draft standard (which will probably be C++20). This includes attributes named: 'expects' and 'ensures'. (all lower case)
I have checked all of boost, and with the possible exception of Boost.Contract, we do not have any macros with those names.
But you might want to keep your eyes open.
-- Marshall
P.S. These are not keywords - so it's perfectly fine to have member functions with these names. Variables, too. Probably even free functions - though I haven't tried that. But macros are right out ;-)+
We should not have any macros that are not all uppercase letters. All macro names in Boost libraries should be BOOST_SOMELIB_XXXXX... . This is like C++ programming 101. The fact that a number of compiler vendors do not follow the simple rule of having uppercase letters in macro names does not mean that we should follow their poor example.
P.P.S. For people who are interested, the paper is http://wg21.link/P0542
participants (2)
-
Edward Diener
-
Marshall Clow