On 9 January 2015 at 01:26, Nelson, Clark wrote:
>
> The question is, once someone writes code that uses a new/better
> facility in place of a deprecated/removed facility, would they
> really want or need to keep around the code that uses the removed
> facility? How would they benefit by doing so?

Only if they want the code to compile in C++03 mode, using the
deprecated features. But you can reliably determine that by looking at
__cplusplus rather than any feature macro, because all implementations
provided the new/better facilities long before they started defining
feature-test macros.

> It seems that what we really want is feature-test macros for the
> new facilities that made these obsolete. Personally, I don't even
> know in what standard they were introduced; I can only guess that
> it was probably C++11. Do we want to continue to expand that table?

__cpp_lib_removed_auto_ptr

Obsoleted by std::unique_ptr in C++11.

__cpp_lib_removed_binders

Obsoleted by std::bind in C++11.

__cpp_lib_removed_function_objects

These were only ever utilities for providing member typedefs, but
fewer facilities rely on those typedefs existing in C++11 (because we
have decltype and std::result_of). Even if you need the typedefs (e.g.
because you are using std::not1, which will be obsoleted by
std::not_fn in C++17) you can define them yourself instead of deriving
from std::unary_function or std::binary_function.

__cpp_lib_removed_random_shuffle

Obsoleted by std::shuffle in C++11.