非推奨は有害と見なされますか？[閉まっている]

私は自分のコードのいくつかを-std=c++0xGCC のフラグでコンパイルしているところです。すべての若い人たちがやっていることを漠然と追いかけたいので（芝生にとどまっている場合）、警告がたくさん出ましたauto_ptr廃止されることについて。もちろん、私はそれauto_ptrがC ++ 0xで廃止されることを知っていましたが...

廃止は時間と労力の無駄ではありませんか？廃止されない理由（例としてauto_ptrを使用）：

• まだサポートが必要な大量のコードがあり、何百万もの警告を生成しても、警告をオフにしたくなるだけです。

• auto_ptr 少しナッフですが、実際にはブリキに書かれていることを行います。

• 私たちが本当に物事を非難したいなら、私は指名しprintf()ます。しかし、その後に続く悲鳴を想像してください。auto_ptrあまりにも多くの友人はいませんが、少なくとも私のC ++コードではprintf、まったく使用されていないを超えて使用されています。

• 委員会はこれを正しく行ったという悪い記録を持っています-彼らは名前空間のスコープで静的を廃止し、今では廃止されていないようです- auto_ptr同様のカムバックをしても私は驚かないでしょう

• 最後に、委員会の言うことは何でも、コンパイラの実装者はそれらを無視します-彼らは単に彼らの顧客コードを壊す危険を冒すことができません、彼らができるすべては刺激的な警告を出すことです。

だから私の質問-（auto_ptrsだけでなく、C ++だけでなく）非推奨を良いアイデアと考えていますか？そうであれば、なぜですか？

非推奨の理由（一般的に）：

• それは、何かが悪い習慣であることを人々に明確に示しています（そして、うまくいけば代替案を提案します）。
• 非推奨期間は、コンパイラーが完全に削除する前にコードを変更する機会を人々に与えます。

最後の点についても私は同意しません。コンパイラは、委員会を無視していない、と彼らは最終的には廃止され、物事を削除するには（たとえば、>?=および<?=GCCで-彼らは*削除、その後廃止され）。

重要な点は、さまざまな理由でいくつかのものを削除する必要があると思います。そして、非推奨がそれを行う唯一の正気な方法だと思います。この特定のケースでauto_ptrは、に置き換えられたため、削除する必要がありますunique_ptr。乗り換えは十分に簡単であり、人々はそうするのに十分な時間があるでしょう。

（*）はい、拡張機能であり、標準ではないことは知っていますが、ポイントは、コードが依然依存しているかどうかに関係なく、コンパイラーベンダーが非推奨になると最終的に削除することです。

十分に複雑なAPIには、しばらく使用されるまで発見されない欠陥がある可能性があります。私たちのオプション：

• そのままにしておきます。これは、APIが時間とともに進化するにつれて、ますます多くの問題を収集し続けることを意味します。新しいバージョンと改良されたバージョンが追加された場合でも、古いバージョンも同様に維持する必要があります。
• 警告なしに削除します。これは多くのコードを壊す可能性があります。
• 廃止し、後のバージョンで削除してください。これにより、既存のコードを修正するための時間が与えられますが、残骸の量は制限されたままになります。

非推奨は、これらの選択肢の最も簡単なものです。

いや 非推奨は本当に良いことです。テクノロジーが古い役に立たない手荷物に縛られるのを防ぎます。

C ++の分野では、forステートメント内の変数宣言を正しくサポートしていないというMicrosoftの「機能」を覚えています。それは約10年間続き、多くのコードを移植性のないものにしました。これは、廃止されて良かった1つの「機能」です。

より一般的には、80年代に不格好な古いAPIを「非推奨」としてマークしてから5〜7年間、それらをヤンクする前から、Appleには習慣がありました。私はWWDCのAppleエンジニアと古代のQuickTime C APIのいくつかを廃止することについて話していましたが、1990年頃に開発されたモデルに対する継続的なサポートが、期待できることを完全に妨げていたため、彼らがそうしていると聞いて本当にうれしく思いました最新の64ビットマルチコアCPUで実行します。

実際には、auto_ptrをダンプするのにコンパイラの作成者は時間がかかり、おそらく10年か20年の間、下位互換モードをサポートするでしょうが、それは良いことです。

私たちが本当に物事を非難したい場合、私はprintf（）を指名します

printf便利な機能です。入出力ストリームよりも短い方法でフォーマットすることができます。そして、それはC関数です。C ++が存在し、使用されているまさにその理由は、C ++と互換性があるためprintfです。

だから、非難の十字軍に参加する他の誰か？

委員会は、現在想定されている廃止の意味の問題のいくつかを認識しています。非推奨の意味を参照してください。

言語とAPIは前進する必要があります。古い機能に依存するコードが大量にある場合でも、何かを行うための新しいより良い方法があり、古い機能をサポートするためのコストが高すぎます。

また、非推奨により、今後この機能が削除されるという警告が表示されます。これにより、開発者が新しいAPIに対応している場合、開発者がコードを更新する時間ができます。これは、完全な削除という選択肢よりもはるかに優れています。減価償却はエラーではなく警告であることを忘れないでください。

そして、これが更新したくない古いプログラムである場合、古いAPI（この場合はコンパイラー）の使用を妨げるものは何もありません。

現状では、非推奨には少なくとも2つの意味があります。

• 将来のバージョンで削除される予定です
• より良い代替案を作成し、機能は冗長になりました（ただし、完全に役に立たないわけではありません）。初心者は、言語を学習する際にこれをスキップする方が良いでしょう。ただし、すぐには削除されません。

静的は後者のカテゴリに分類されると思いますが、auto_ptrを本当に削除するに値するのか、それを言語で保持するほうがよいのかは時間だけがわかります。

代替への移行が1営業日以内に行える場合、廃止は有害ではありません。古い関数を新しい関数で簡単に検索/置換するか、互換性レイヤーを簡単に設定できます。

非推奨のためにソフトウェアの大部分を書き換える必要がある場合、それは有害です。

良い例は、おそらくPHPのmysql APIです。基本的には、すべてのmysql_ *をmysqli_ *に置き換え、それらにリンクIDを指定するだけで完了です。

悪い例の1つは、OpenGLからのglBegin、glEnd、およびすべての行列計算のものの廃止と削除です。OpenGL3以降でコードを動作させる場合は、頂点バッファーを使用するためにレンダリングコード全体を書き直す必要があります。

もっと良い方法があることを人々に知らせる良い方法だと思います。私は、機能が消えるだけでなく、良い廃止を好む。