Deprecation considered harmful? [closed]

Question

I've just been compiling some of my own code with the -std=c++0x flag in GCC, as I want to vaguely keep up with what all the young folks are doing (provided they stay of my lawn), and I ended up with a load of warnings about auto_ptr being deprecated. Of course, I knew that auto_ptr was deprecated in C++0x, but...

Isn't deprecation a waste of time and effort? Reasons for not deprecating (with auto_ptr as an example):

• there is an ocean of code out there that still needs to be supported, producing millions of warnings will only tempt people to turn warnings off.

• auto_ptr is a bit naff, but it does actually do what it says on the tin.

• if we really want to deprecate things, I nominate printf(). But just imagine the squeals that would ensue. auto_ptr doesn't have too many friends, but in at least my C++ code it is used more than printf, which isn't used at all.

• the committee have a bad record of getting this right - they deprecated static at namespace scope, and now it seems to have been undeprecated - I wouldn't be surprised if auto_ptr made a similar come-back

• lastly, whatever the committee say, the compiler implementers ignore them - they simply can't risk breaking their customers code, all they can do is issue irritating warnings.

So my question - do you consider deprecation (of anything, not just auto_ptrs, and not just in C++) a good idea, and if so, why?

Answer 1

Reasons for deprecation (in general):

• It clearly indicates to people that something is bad practice (and hopefully suggests an alternative).
• The deprecation period gives people a chance to change their code before the compiler removes it outright.

I also disagree about the last point. Compilers don't ignore the committee, and they do eventually remove things that are deprecated (e.g. >?= and <?= in GCC -- they were deprecated then removed*).

I think the important point is: some things should be removed, for various reasons, and I think deprecation is the only sane way to do that. In this specific case, auto_ptr should be removed as it has been superseded by unique_ptr. Changing over is easy enough, and people will have plenty of time to do so.

(*) Yes I know they are extensions and not standard, but the point is that compiler vendors do eventually remove things once they enter deprecation, whether code still relies on them or not.

Answer 2

Any sufficiently complicated API will likely have flaws that are not discovered until after they've been used for a while. Our options:

• Leave things as they are. This means the API will continue to gather more and more cruft as it evolves over time. Even if new and improved versions are added, the old ones will need to be kept maintained as well.
• Remove it without warning. This is likely to break a lot of code.
• Deprecate it and remove it in a later version. This gives time to fix existing code, while ensuring that the amount of cruft stays bounded.

Deprecation is the sanest of these alternatives.

Answer 3

Nah. Deprecation can be a really good thing. It keeps technologies from getting stuck with old useless baggage.

Just in the C++ arena, I remember Microsoft's "feature" of not correctly supporting variable declaration inside a for statement. That went on for about a decade and made a lot of code non-portable. That's one "feature" I'm glad was deprecated.

More generally, Apple has had a habit since the 80s of marking clunky old APIs as "deprecated" for 5-7 years before yanking them. I was just talking with an Apple engineer at WWDC about deprecating some of the ancient QuickTime C APIs, and was really delighted to hear they were doing that, because continued support for a model developed around 1990 was completely obstructing what one would expect to be able to do on modern 64-bit multicore CPUs.

In practice, it's going to take compiler writers a long time to dump auto_ptr, and they'll probably support some backwards-compatibility mode for a decade or two, but it's a good thing imo.

Answer 4

if we really want to deprecate things, I nominate printf()

printf is a useful function. It allows for formatting things ways shorter than iostreams. And it's a C function. The very reason C++ exists and is used is because it's compatible with C. So deprecating printf seems less useful.

So, anyone else up for an anti-deprecation crusade?

The committee is aware of some of the problems of the current supposed meaning of deprecation. See the meaning of deprecation.

Answer 5

Languages and APIs have to move forward. Even though there might be a ton of code depending on some old feature, there might be a new and better way to do something and the cost of supporting the old feature is just too much.

Deprecation also gives warning that in the future, the feature will be removed. This gives developers time to update their code if they are keeping up with the new API. This is much better than the alternative: outright removal. Remember that depreciation is a warning, not an error.

And if this is an old program that you don't want to update, then nothing is stopping you from using the old API (or in this case compiler).

Answer 6

As it stands, deprecation has at least two meanings.

• It is going to be removed in a future version
• We created better alternatives and now the feature is redundant (but not entirely useless). Newcomers would better skip this while learning the language; however, it is not going to be removed any time soon.

I think static falls into the latter category, but only time will tell if auto_ptr really deserves to be removed or if it's better to keep it in the language.

Answer 7

Deprecation is not harmful if moving to an alternative can be done in 1 work day: eg. simple search/replace of the old function with the new, or a compatibility layer is easy to set up.

If you need to rewrite large parts of the software because of the deprecation, then it's harmful.

A good example would be probably the PHP's mysql API, basically you simply need to replace all mysql_* with mysqli_* and provide a link id to them and it's done.

One bad example is the deprecation and removal glBegin, glEnd, and all matrix computation stuff from OpenGL, if you want your code work on OpenGL3 or above, you'll need to rewrite the whole rendering code to use vertex buffers.

Answer 8

I think it is a good way of letting people know that there is a better way. I much prefer a nice deprecation rather than a function just disappearing.