Устаревание считается вредным? [закрыто]

Я только что скомпилировал свой собственный код с -std=c++0xфлагом в GCC, так как я хочу смутно следить за тем, что делают все молодые люди (при условии, что они остаются на моей лужайке), и я получил массу предупреждений о том, 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 ++ я помню «особенность» Microsoft - неправильно поддерживать объявление переменных внутри оператора for. Это продолжалось около десяти лет и сделало много кода непереносимым. Это одна "особенность", я рад, что она устарела.

В целом, с 80-х годов Apple имела привычку помечать неуклюжие старые API как «устаревшие» в течение 5-7 лет, прежде чем их дергать. Я только что говорил с инженером Apple на WWDC об устаревании некоторых из древних API-интерфейсов QuickTime C, и был очень рад услышать, что они делают это, потому что постоянная поддержка модели, разработанной в 1990 году, полностью препятствовала тому, что можно было ожидать. делать на современных 64-битных многоядерных процессорах.

На практике авторам компилятора потребуется много времени, чтобы создать дамп auto_ptr, и они, вероятно, будут поддерживать какой-то режим обратной совместимости в течение десятилетия или двух, но это хорошая вещь, imo.

если мы действительно хотим отказаться от вещей, я назначаю printf ()

printfэто полезная функция. Это позволяет форматировать вещи намного короче, чем iostreams. И это функция C. Причина, по которой C ++ существует и используется, заключается в том, что он совместим с C. Поэтому устаревание printfкажется менее полезным.

Итак, кто-нибудь еще готовится к крестовому походу против амортизации?

Комитет осведомлен о некоторых проблемах нынешнего предполагаемого значения амортизации. Увидеть значение амортизации .

Языки и API должны двигаться вперед. Даже если в зависимости от какой-то старой функции может быть тонна кода, может быть новый и лучший способ что-то сделать, а стоимость поддержки старой функции слишком велика.

Амортизация также дает предупреждение, что в будущем эта функция будет удалена. Это дает разработчикам время для обновления своего кода, если они идут в ногу с новым API. Это намного лучше, чем альтернатива: прямое удаление. Помните, что амортизация - это предупреждение, а не ошибка.

И если это старая программа, которую вы не хотите обновлять, то ничто не мешает вам использовать старый API (или, в данном случае, компилятор).

В нынешнем виде амортизация имеет как минимум два значения.

• Это будет удалено в будущей версии
• Мы создали лучшие альтернативы, и теперь эта функция избыточна (но не совсем бесполезна). Новичкам лучше пропустить это, изучая язык; однако, это не будет удалено в ближайшее время.

Я думаю, что static относится к последней категории, но только время покажет, действительно ли auto_ptr заслуживает удаления или лучше оставить его на языке.

Устаревание не вредно, если переход на альтернативу может быть сделан за 1 рабочий день: например. простой поиск / замена старой функции на новую, или слой совместимости легко настроить.

Если вам нужно переписать большие части программного обеспечения из-за устаревания, то это вредно.

Хорошим примером может быть PHP mysql API, в основном вам просто нужно заменить все mysql_ * на mysqli_ * и предоставить им идентификатор ссылки, и все готово.

Один плохой пример - устаревание и удаление glBegin, glEnd и всего, что связано с вычислениями матрицы из OpenGL. Если вы хотите, чтобы ваш код работал на OpenGL3 или выше, вам нужно переписать весь код рендеринга для использования вершинных буферов.

Я думаю, что это хороший способ дать людям понять, что есть лучший способ. Я предпочитаю приятное устаревание, а не просто исчезновение функции.