Deprecação considerada prejudicial? [fechadas]

Acabei de compilar parte do meu próprio código com a -std=c++0xbandeira no GCC, pois quero acompanhar vagamente o que todos os jovens estão fazendo (desde que permaneçam no meu gramado) e acabei recebendo uma série de avisos sobre auto_ptrser preterido. Claro, eu sabia que isso auto_ptrfoi preterido em C ++ 0x, mas ...

A depreciação não é uma perda de tempo e esforço? Motivos para não descontinuar (com auto_ptr como exemplo):

• existe um oceano de código por aí que ainda precisa ser suportado, produzir milhões de avisos apenas tentará as pessoas a desativar os avisos.

• auto_ptr é um pouco tolo, mas na verdade faz o que diz na lata.

• se realmente queremos depreciar as coisas, eu nomeio printf(). Mas imagine os gritos que se seguiriam. auto_ptrnão tem muitos amigos, mas pelo menos no meu código C ++ é usado mais do que printf, o que não é usado.

• o comitê tem um péssimo histórico de acertar isso - eles preteriram a estática no escopo do espaço para nome e agora parece ter sido reprovado - eu não ficaria surpreso se auto_ptrfizesse um retorno semelhante

• por fim, o que quer que o comitê diga, os implementadores do compilador os ignoram - eles simplesmente não podem arriscar violar o código de seus clientes, tudo o que podem fazer é emitir avisos irritantes.

Então, minha pergunta - você considera a depreciação (de qualquer coisa, não apenas auto_ptrs e não apenas em C ++) uma boa idéia, e se sim, por quê?

Razões para descontinuar (em geral):

• Indica claramente às pessoas que algo é uma má prática (e, esperançosamente, sugere uma alternativa).
• O período de descontinuação oferece às pessoas a chance de alterar seu código antes que o compilador o remova completamente.

Também discordo do último ponto. Os compiladores não ignoram o comitê e acabam removendo itens que foram descontinuados (por exemplo, >?=e <?=no GCC - eles foram descontinuados e depois removidos *).

Penso que o ponto importante é: algumas coisas devem ser removidas, por várias razões, e acho que a depreciação é a única maneira sensata de fazer isso. Nesse caso específico, auto_ptrdeve ser removido como foi substituído por unique_ptr. Mudar é fácil, e as pessoas terão tempo de sobra para fazê-lo.

(*) Sim, eu sei que eles são extensões e não são padrão, mas o ponto é que os fornecedores de compiladores acabam removendo as coisas quando entram na depreciação, se o código ainda depende delas ou não.

Qualquer API suficientemente complicada provavelmente terá falhas que não serão descobertas até depois de terem sido usadas por um tempo. Nossas opções:

• Deixe as coisas como estão. Isso significa que a API continuará a reunir mais e mais fragmentos à medida que evolui ao longo do tempo. Mesmo se versões novas e aprimoradas forem adicionadas, as antigas precisarão ser mantidas também.
• Retire-o sem aviso prévio. É provável que isso interrompa muito código.
• Preteri-lo e removê-lo em uma versão posterior. Isso dá tempo para corrigir o código existente, garantindo que a quantidade de cruft permaneça limitada.

A depreciação é a melhor dessas alternativas.

Nah. A depreciação pode ser uma coisa muito boa. Evita que as tecnologias fiquem presas com a bagagem velha e inútil.

Apenas na área de C ++, lembro-me do "recurso" da Microsoft de não suportar corretamente a declaração de variável dentro de uma instrução for. Isso durou cerca de uma década e tornou muitos códigos não portáveis. Essa é uma "característica" que, felizmente, foi preterida.

De maneira mais geral, a Apple tem um hábito desde os anos 80 de marcar APIs antigas e desajeitadas como "obsoletas" por 5 a 7 anos antes de arrancá-las. Eu estava conversando com um engenheiro da Apple na WWDC sobre a depreciação de algumas das antigas APIs do QuickTime C, e fiquei muito feliz ao saber que elas estavam fazendo isso, porque o suporte contínuo a um modelo desenvolvido por volta de 1990 estava obstruindo completamente o que seria de esperar para fazer em modernas CPUs multicore de 64 bits.

Na prática, os escritores de compiladores levarão muito tempo para despejar o auto_ptr, e eles provavelmente oferecerão suporte a alguns modos de compatibilidade com versões anteriores por uma década ou duas, mas é uma boa coisa.

se realmente queremos depreciar as coisas, nomeio printf ()

printfé uma função útil. Ele permite formatar as coisas de maneira mais curta que os iostreams. E é uma função C. O motivo pelo qual o C ++ existe e é usado é porque é compatível com o C. Portanto, preterir printfparece menos útil.

Então, mais alguém para uma cruzada anti-depreciação?

O comitê está ciente de alguns dos problemas do suposto significado atual de depreciação. Veja o significado de descontinuação .

Idiomas e APIs precisam seguir em frente. Embora possa haver uma tonelada de código, dependendo de algum recurso antigo, pode haver uma maneira nova e melhor de fazer algo e o custo de suporte ao recurso antigo é muito alto.

A descontinuação também avisa que, no futuro, o recurso será removido. Isso dá aos desenvolvedores tempo para atualizar seu código se estiverem acompanhando a nova API. Isso é muito melhor do que a alternativa: remoção definitiva. Lembre-se de que a depreciação é um aviso, não um erro.

E se esse é um programa antigo que você não deseja atualizar, nada o impede de usar a API antiga (ou, neste caso, o compilador).

Tal como está, a depreciação tem pelo menos dois significados.

• Ele será removido em uma versão futura
• Criamos alternativas melhores e agora o recurso é redundante (mas não totalmente inútil). Os novatos poderiam ignorar isso enquanto aprendiam o idioma; no entanto, não será removido tão cedo.

Acho que a estática se enquadra na última categoria, mas apenas o tempo dirá se o auto_ptr realmente merece ser removido ou se é melhor mantê-lo no idioma.

A depreciação não é prejudicial se a mudança para uma alternativa puder ser feita em 1 dia útil: por exemplo. É fácil configurar a pesquisa / substituição simples da função antiga pela nova ou uma camada de compatibilidade.

Se você precisar reescrever grandes partes do software por causa da reprovação, isso é prejudicial.

Um bom exemplo seria provavelmente a API mysql do PHP, basicamente você simplesmente precisa substituir todos os mysql_ * por mysqli_ * e fornecer um ID de link para eles e pronto.

Um mau exemplo é a depreciação e remoção de glBegin, glEnd e todo o material de computação de matriz do OpenGL; se você deseja que seu código funcione no OpenGL3 ou superior, você deve reescrever todo o código de renderização para usar os buffers de vértice.

Eu acho que é uma boa maneira de deixar as pessoas saberem que existe uma maneira melhor. Eu prefiro uma boa depreciação do que uma função simplesmente desaparecendo.