廃止は有害と見なされますか？
若い人々が何をしているかを漠然と追いたいので（彼らが私の芝生にとどまっていれば）、私は自分のコードの一部をGCCの_-std=c++0x_フラグでコンパイルしているところです。廃止予定の_auto_ptr_に関する警告が大量に表示されます。もちろん、C++ 0xでは_auto_ptr_が廃止予定であることは知っていましたが、...
廃止は時間と労力の無駄ではありませんか？非推奨にならない理由（例としてauto_ptrを使用）：
まだサポートする必要のあるコードの海があります。何百万もの警告を生成しても、警告をオフにしたくなるだけです。
_
auto_ptr_は少し厄介ですが、実際には缶に書かれていることを実行します。本当に廃止したい場合は、
printf()を指定します。しかし、続いて起こる悲鳴を想像してみてください。 _auto_ptr_にはあまり友達はありませんが、少なくとも私のC++コードではprintfよりも多く使用されており、まったく使用されていません。委員会はこれを正しく行うという悪い記録を持っています-彼らは名前空間スコープでstaticを非推奨にし、現在は非推奨ではないようです-_
auto_ptr_が同様のカムバックを行っても私は驚かないでしょう最後に、委員会の発言が何であれ、コンパイラの実装者はそれらを無視します-彼らは単に顧客のコードを壊す危険を冒すことはできません。
だから私の質問-（auto_ptrsだけでなく、C++だけでなく）非推奨は良い考えだと思いますか？そうであれば、なぜですか？
サポート終了の理由（一般）：
- それは明らかに何かが悪い習慣であることを人々に示します（そしてうまくいけば代替案を提案します）。
- 非推奨期間は、コンパイラが完全に削除する前に、コードを変更する機会を人々に与えます。
最後の点についても同意しません。コンパイラーは委員会を無視しません、そして最終的には非推奨となったものを削除します（例えば、GCCの>?=および<?=-それらは非推奨となり、削除されました*）。
重要なポイントは次のとおりだと思います。さまざまな理由により、いくつかの項目を削除する必要があります。非推奨にするのが唯一の健全な方法だと思います。この特定のケースでは、auto_ptrはunique_ptrに置き換えられたため、削除する必要があります。乗り換えは簡単で、人々はそうするための十分な時間を持っています。
（*）はい、それらは拡張機能であり、標準ではないことを知っていますが、重要なのは、コードが依然依存しているかどうかにかかわらず、コンパイラベンダーは廃止に入ると最終的に削除するということです。
十分に複雑なAPIには、しばらく使用されるまで発見されない欠陥がある可能性があります。私たちのオプション：
- そのままにしておきます。これは、APIが時間の経過とともに進化するにつれて、APIがどんどん壊れていくことを意味します。新しいバージョンや改善されたバージョンが追加された場合でも、古いバージョンも維持する必要があります。
- 警告なしに削除してください。これは多くのコードを壊す可能性があります。
- それを非推奨にして、新しいバージョンで削除してください。これは既存のコードを修正する時間を与え、同時に残骸の量が制限されたままであることを保証します。
非推奨は、これらの代替案の最も健全なものです。
いや。廃止は本当に良いことです。それはテクノロジーが古い役に立たない手荷物で行き詰まるのを防ぎます。
C++の領域では、forステートメント内の変数宣言を正しくサポートしないというMicrosoftの「機能」を覚えています。それは約10年間続き、多くのコードが移植不可能になりました。これは、廃止されて良かった「機能」の1つです。
より一般的には、Appleは、80年代以降、不格好な古いAPIを5〜7年間「非推奨」としてマークしてから、それらをヤンクしました。私は、Appleエンジニアは、WWDCで古代のQuickTime C APIのいくつかの廃止について説明しました。1990年頃に開発されたモデルに対する継続的なサポートは、期待できることを完全に妨げていたため、そうしたことを聞いて本当に嬉しかったです。最新の64ビットマルチコアCPU。
実際には、auto_ptrをダンプするのにコンパイラー作成者に長い時間がかかります。おそらく、10年か2年は下位互換性モードをサポートしますが、それはいいことです。
本当に物事を廃止したい場合は、printf（）を指定します
printfは便利な関数です。 iostreamよりも短い方法でフォーマットできます。そして、それはC関数です。 C++が存在し、使用されているまさにその理由は、Cと互換性があるためです。そのため、printfの廃止はあまり役に立たないようです。
だから、誰か他の人が非推奨の反対運動に賛成ですか？
委員会は、現在の廃止予定の意味のいくつかの問題を認識しています。 非推奨の意味 を参照してください。
言語とAPIは前進する必要があります。いくつかの古い機能に応じて大量のコードが存在する場合でも、何かを行うための新しいより良い方法があり、古い機能をサポートするためのコストが高すぎる可能性があります。
非推奨は、将来、機能が削除されることを警告します。これにより、開発者は新しいAPIに追いついている場合にコードを更新する時間を確保できます。これは、代替手段よりもはるかに優れています。完全な削除です。減価償却費は警告ではなく、エラーであることを忘れないでください。
そして、これが更新したくない古いプログラムである場合、古いAPI（またはこの場合はコンパイラー）の使用を妨げるものは何もありません。
現状では、非推奨には少なくとも2つの意味があります。
- 将来のバージョンで削除される予定です
- 私たちはより良い代替案を作成しましたが、この機能は冗長です（しかし完全に役に立たないわけではありません）。初心者は、言語を学習している間はこれをスキップするほうがよいでしょう。ただし、すぐには削除されません。
Staticは後者のカテゴリに分類されると思いますが、auto_ptrを本当に削除する価値があるかどうか、またはそれを言語で保持する方が良いかどうかを判断するのは時がきます。
代替案への移行が1営業日で実行できる場合、廃止は問題ありません。古い関数を単純な検索/新しい関数で置き換えるか、互換性レイヤーを設定するのは簡単です。
非推奨となったためにソフトウェアの大部分を書き換える必要がある場合、それは有害です。
良い例はおそらくPHPのmysql APIです。基本的には、すべてのmysql_ *をmysqli_ *に置き換え、それらにリンクIDを指定するだけで完了です。
悪い例の1つは、OpenGLからの非推奨および削除glBegin、glEnd、およびすべての行列計算に関するものです。OpenGL3以降でコードを機能させる場合は、頂点バッファーを使用するようにレンダリングコード全体を書き直す必要があります。