Deprecazione considerata dannosa? [chiuso]

Ho appena compilato un po 'del mio codice con la -std=c++0xbandiera in GCC, poiché voglio tenere il passo vagamente con quello che fanno tutti i giovani (purché rimangano del mio prato), e ho finito con un carico di avvertimenti A proposito di auto_ptressere deprecato. Certo, sapevo che auto_ptrera deprecato in C ++ 0x, ma ...

La deprecazione non è una perdita di tempo e fatica? Motivi per non deprecare (con auto_ptr come esempio):

• c'è un oceano di codice là fuori che deve ancora essere supportato, la produzione di milioni di avvisi tenterà solo le persone a disattivare gli avvisi.

• auto_ptr è un po 'stupido, ma in realtà fa quello che dice sulla scatola.

• se vogliamo davvero deprecare le cose, lo nominerò printf(). Ma immagina solo gli strilli che ne conseguirebbero. auto_ptrnon ha troppi amici, ma almeno nel mio codice C ++ è usato più di printf, che non è affatto usato.

• il comitato ha una brutta reputazione di ottenere ciò giusto - hanno deprecato la staticità nell'ambito dello spazio dei nomi, e ora sembra essere stato non dichiarato - non sarei sorpreso se auto_ptrun ritorno simile

• infine, qualunque cosa il comitato dica, gli implementatori del compilatore li ignorano: semplicemente non possono rischiare di violare il codice dei loro clienti, tutto ciò che possono fare è emettere avvisi irritanti.

Quindi la mia domanda: consideri la deprecazione (di qualcosa, non solo auto_ptrs, e non solo in C ++) una buona idea, e se sì, perché?

Motivi dell'ammortamento (in generale):

• Indica chiaramente alle persone che qualcosa è una cattiva pratica (e si spera suggerisca un'alternativa).
• Il periodo di ammortamento offre alle persone la possibilità di modificare il proprio codice prima che il compilatore lo rimuova completamente.

Sono anche in disaccordo sull'ultimo punto. I compilatori non ignorano il comitato e alla fine rimuovono le cose che sono deprecate (ad esempio >?=e <?=in GCC - sono state deprecate e poi rimosse *).

Penso che il punto importante sia: alcune cose dovrebbero essere rimosse, per vari motivi, e penso che la deprecazione sia l'unico modo sano per farlo. In questo caso specifico, auto_ptrdovrebbe essere rimosso in quanto è stato sostituito da unique_ptr. Cambiare è abbastanza facile e le persone avranno tutto il tempo per farlo.

(*) Sì, lo so che sono estensioni e non standard, ma il punto è che i fornitori di compilatori alla fine rimuovono le cose una volta immesse la deprecazione, indipendentemente dal fatto che il codice si basi ancora su di esse.

Qualsiasi API sufficientemente complicata avrà probabilmente difetti che non vengono scoperti fino a quando non sono stati utilizzati per un po '. Le nostre opzioni:

• Lascia le cose come sono. Ciò significa che l'API continuerà a raccogliere sempre più cruft man mano che si evolve nel tempo. Anche se vengono aggiunte versioni nuove e migliorate, anche quelle precedenti dovranno essere mantenute.
• Rimuovilo senza preavviso. È probabile che questo rompa molto codice.
• Deprecarlo e rimuoverlo in una versione successiva. Ciò consente di correggere il codice esistente, garantendo al contempo che la quantità di cruft rimanga limitata.

La deprecazione è la più sana di queste alternative.

Nah. La deprecazione può essere davvero una buona cosa. Impedisce alle tecnologie di rimanere bloccate con il vecchio bagaglio inutile.

Proprio nell'arena C ++, ricordo la "caratteristica" di Microsoft di non supportare correttamente la dichiarazione delle variabili all'interno di un'istruzione for. Ciò è andato avanti per circa un decennio e ha reso un sacco di codice non portatile. Questa è una "caratteristica" Sono contento che sia stato deprecato.

Più in generale, dagli anni '80 Apple ha l'abitudine di contrassegnare le vecchie e grezze API come "deprecate" per 5-7 anni prima di strapparle. Stavo solo parlando con un ingegnere Apple al WWDC di deprecare alcune delle antiche API QuickTime C, ed ero davvero felice di sapere che lo stavano facendo, perché il supporto continuo per un modello sviluppato intorno al 1990 stava ostacolando completamente ciò che ci si aspetterebbe di poter fare da fare su moderne CPU multicore a 64 bit.

In pratica, gli autori del compilatore impiegheranno molto tempo a scaricare auto_ptr e probabilmente supporteranno una modalità di retrocompatibilità per un decennio o due, ma è una buona cosa imo.

se vogliamo davvero deprecare le cose, nominerò printf ()

printfè una funzione utile. Permette di formattare le cose in modo più breve degli iostreams. Ed è una funzione C. Il vero motivo per cui esiste C ++ è perché è compatibile con C. Quindi deprecare printfsembra meno utile.

Quindi, qualcun altro ha voglia di una crociata anti-deprecazione?

Il comitato è a conoscenza di alcuni dei problemi dell'attuale presunto significato di deprecazione. Vedi il significato di deprecazione .

Le lingue e le API devono andare avanti. Anche se potrebbe esserci un sacco di codice a seconda di alcune vecchie funzionalità, potrebbe esserci un modo nuovo e migliore per fare qualcosa e il costo di supportare la vecchia funzionalità è troppo.

La deprecazione inoltre avvisa che in futuro la funzionalità verrà rimossa. Ciò offre agli sviluppatori il tempo di aggiornare il loro codice se si tengono al passo con la nuova API. Questo è molto meglio dell'alternativa: rimozione totale. Ricorda che l'ammortamento è un avvertimento, non un errore.

E se questo è un vecchio programma che non vuoi aggiornare, allora nulla ti impedisce di usare la vecchia API (o in questo caso il compilatore).

Allo stato attuale, la deprecazione ha almeno due significati.

• Verrà rimosso in una versione futura
• Abbiamo creato alternative migliori e ora la funzionalità è ridondante (ma non del tutto inutile). I nuovi arrivati ​​farebbero meglio a saltare questo mentre imparano la lingua; tuttavia, non verrà rimosso presto.

Penso che la statica rientri in quest'ultima categoria, ma solo il tempo dirà se auto_ptr merita davvero di essere rimosso o se è meglio tenerlo nella lingua.

La deprecazione non è dannosa se si può passare a un'alternativa in 1 giorno lavorativo: ad es. la semplice ricerca / sostituzione della vecchia funzione con la nuova o un livello di compatibilità è facile da configurare.

Se è necessario riscrivere gran parte del software a causa della deprecazione, è dannoso.

Un buon esempio potrebbe essere probabilmente l'API mysql del PHP, in pratica devi semplicemente sostituire tutto mysql_ * con mysqli_ * e fornire loro un ID link e il gioco è fatto.

Un cattivo esempio è la deprecazione e la rimozione di glBegin, glEnd e tutte le cose di calcolo della matrice di OpenGL, se vuoi che il tuo codice funzioni su OpenGL3 o versioni successive, dovrai riscrivere l'intero codice di rendering per usare i buffer di vertici.

Penso che sia un buon modo per far sapere alla gente che esiste un modo migliore. Preferisco di gran lunga una bella deprecazione piuttosto che una funzione che sta semplicemente scomparendo.