----- Original Message -----
From: Nevin Liber
\My concern was about the ease "deprecated and removed" appear together. For example, gets() was deprecated in C99. Removed in the C2011 standard.
How many revs of the C standard are there between deprecation of gets() and removal? It is less than *one*, because gets() was not deprecated when C99 was first published.
Don't even try to compare gets with auto_ptr... One is HUGE security hole and another one some stuff that should be used carefully, it isn't more dangerous that strncpy and far less dangerous that sprintf that goes nowhere.
It will have been two revs of the C++ standard between deprecation and removal of auto_ptr, and it has been well known that auto_ptr was going to be deprecated in C++0x years before that became C++11. --
When C++11 was released and how well it is supported by now? Ok when I started for example Boost.Locale few years ago No major widely available compiler had provided unique_ptr. I'm using Ubuntu LTS 14.4 (a distro one year old with long support) and gcc-4.8 does not support regular expressions yet! At another place I'm using up-to-date RHEL 6.x... it comes with gcc-4.4 and guess what is C++11 support level is there? And yet no-major compiler (besides MSVC 2015 or something like) really support C++11 char16_t/char32_t (I mean all stuff including facets) There is HUGE difference between the standard release time and what world actually uses... MSVC does not even support properly C99 yet and it was released more than a decade ago and it is C much simpler language. So it would take a very long time until industry will move to C++11 and until all major main-stream compilers would have decent C++11 support. So removing very useful stuff that isn't really that bad and that is used in library interfaces (so its removal breaks APIs) it what is what Linus Torvalds would say "brain damaged" decision. Artyom Beilis