1 – Trigraphs
Trigraphs were removed from C++17 because they are not needed anymore. They were used in C/C++ in 80-s. Because the old coding table not supported all needed symbols ISO/IEC646 like: # , [ , ]. etc.
| Trigraph | Equivalent symbol |
| ??= | # |
| ??/ | \ |
| ??’ | ^ |
| ??( | [ |
| ??) | ] |
| ??! | | |
| ??< | { |
| ??> | } |
| ??- | ~ |
Also even before C++17 GCC compiler show warning when trigraphs were used, because using trigraphs can turn to unexpected behavior, for example:
|
1 2 3 4 5 6 7 8 |
int main() { int a = 10; //WTF?????/ a++; std::cout << a << std::endl; return 0; } |
2 – Keyword register
Keyword register was deprecated even in C++11 standard. Only in C++17, it was decided to remove it. Because for new compilers it is not used. If you decide to declare a variable with the register, it’s just hinted to a compiler. It can use it or not. Even if you didn’t declare the variable as the register, the compiler can put it to a processor register.
But the keyword is reserved for future versions of C++.
3 – increment operator for bool
Operator ++ for bool was deprecated from C++98 and only in C++17, it was removed.
4 – Dynamic exception specifications
Dynamic exception specifications were deprecated in C++11 and removed in C++17.
Next code is not valid:
|
1 2 3 4 5 6 7 |
int qwe(int x) throw(int) // error: throw(int) is not allowed { if (x == 2) { throw 1; } return 0; } |
throw() is still present but marked as deprecated, equivalent of noexcept, noexcept(true).
5 – Remove auto_ptr
auto_ptr was introduced in C++98 and it was deprecated in C++11. It was suppressed by new types of smart pointers like unique_ptr or shared_ptr.
6 – Other functionality
- random_shuffle()
- unary_function()
- binary_function()
- bind1st()
- bind2nd()
- ptr_fun()
- mem_fun()
- mem_fun_ref()
- pointer_to_unary_function()
- pointer_to_binary_function()
7 – iostream aliases
Were removed deprecated iostream::ios_base aliases:
io_state, open_mode, seek_dir, streamoff, streampos.
8 – Allocator support in std::function
Removed allocator from std::function. Because it takes an allocator argument, but the semantics are unclear, and there are technical issues with storing an allocator in a type-erased context and then recovering that allocator later for any allocations needed during copy assignment.
Related document P0302R1.