Perché la compatibilità con le versioni precedenti di C ++ è importante / necessaria? [chiuso]

Se comprendo correttamente la tua posizione (dalla domanda e dai commenti sotto la risposta di VJovic), avresti preferito invece un C ++ 11 per lo più compatibile, un nuovo linguaggio basato (lo chiamerò NC ++) su C ++ 03 ma sorgente incompatibile con esso ma collegabile con esso.

Ecco alcuni punti da considerare:

• non è possibile implementare C ++ 11 usando l'ABI C ++ 03 esistente (i provider di compilatori non garantiscono che il codice di collegamento compilato in modalità C ++ 03 e in C ++ 11 funzioni) ed è sicuro che sarebbe lo stesso per NC ++. Quindi dovresti avere nuovi compilatori C ++ 03 che mirano all'NC + NC + così come al compilatore NC ++ per l'implementazione della tua idea.

• hai lo stesso problema con la libreria standard. Avresti bisogno di una nuova implementazione della libreria C ++ 03 in grado di essere interoperabile con la tua libreria NC ++.

• la transizione da C a C ++ può essere fluida poiché C è principalmente un sottoinsieme C ++. Quando il codice C si avvale delle funzionalità C99 non presenti in C ++, la transizione è meno fluida. In particolare intestazioni condivise devono essere codificate nel sottoinsieme comune di C ++ e C che non è naturale se si desidera sfruttare C99. Nel tuo caso, le intestazioni condivise dovranno essere codificate nel sottoinsieme comune di C ++ 03 e NC ++, che temo sarà poco pratico se il tuo obiettivo in NC ++ è quello di sfruttare la possibilità di rompere la compatibilità del codice sorgente per avere un " lingua "più pulita"

Bjarne Stroustrup voleva creare un linguaggio utile basato su C perché era

1. È già popolare nella community s / w
2. Programmazione di basso livello supportata e alcune funzioni di alto livello
3. Un sacco di codice era già scritto in C

Non era previsto un budget di marketing aggressivo per rendere C ++ popolare da solo come lingua individuale.
Invece di reinventare la ruota e introdurre una nuova sintassi, Stroustrup ha scelto di costruire il nuovo linguaggio sulla base esistente (Like C è stato sviluppato sulla base di una lingua precedente).

C ++ non è completamente retrocompatibile con C, ovunque sia necessario ha tracciato una linea. per es.

• typecasting implicito non sicuro non è consentito C ++
• inline , enum e const sono stati introdotti con C ++ e successivi adottato da C

Are there conceptual reasons or technical problems (e.g. compiling existing templates) that make such a change undesirable or even impossible?

Alcune funzionalità sono deprecate e ricevi un avviso (con il livello di controllo degli errori appropriato) e se abiliti l'opzione che trasforma gli avvisi in errori, ottieni l'effetto desiderato.

Ora immagina quando molte funzionalità potrebbero essere rimosse o modificate drasticamente. Ciò renderebbe molti programmi non compilanti. Per i progetti di grandi dimensioni è inaccettabile. Chi varcherebbe il codice 300kLOC-2MLOC per correggere tutti i guasti?

Con la retrocompatibilità, l'aggiornamento del compilatore è molto più semplice. Devi ancora correggere qualche codice, ma il numero di errori è accettabile.

Per la tua modifica:

Come si compila / collega la propria applicazione, dipende dal sistema di compilazione.

Se si utilizzano i makefile, è abbastanza semplice (non così semplice nei sistemi complessi) aggiungere nuove regole per creare librerie separate. il codice c verrebbe compilato usando il codice gcc, c ++ usando la versione specifica di g ++ e il nuovo codice c ++ 11 compilato (di nuovo) con una possibile versione g ++ diversa, in librerie condivise separate. L'applicazione finale quindi collegherebbe a quelle librerie. Ovviamente, devi assicurarti che tutti i compilatori utilizzino lo stesso ABI .

In pratica parleresti in modo definitivo di una nuova lingua - cosa che sta già accadendo con le numerose sostituzioni C ++ proposte nel corso degli anni. Penso che stia dicendo che nessuno di loro è riuscito a sostituire C ++.

Entrambi i tuoi locali sono sbagliati. I puntatori intelligenti sono un successo in termini di prestazioni e C è ben lungi dall'essere obsoleto: le chiamate di sistema Windows e UNIX sono definite in termini di C. In effetti, quasi tutti i sistemi operativi in uso ampio oggi, ad eccezione di Symbian, utilizza le interfacce C. Quindi, se vuoi avere una lingua che supporti la programmazione a livello di sistema, non puoi allontanarti da nuovi, eliminare, puntatori grezzi e tutte le cose che ritieni dogmaticamente siano cattive.

Penso che il punto di vista di Bjarne sia stato che C e C ++ avrebbero dovuto essere unificati come un'unica lingua. Penso che ciò potrebbe implicare che il suo punto di vista è che C ++ dovrebbe essere una sostituzione di C, e come tale compatibilità con C è importante in tale vista.