Perché il C ++ non può adottare l'approccio di D per la sua implementazione concettuale?

Lo standard di C ++ è un documento normativo, che stabilisce regole che rimarranno (per lo più inalterate) nei documenti futuri. Pertanto la commissione ha adottato un approccio molto prudente per quanto riguarda i suoi aggiornamenti.

Le aggiunte alla libreria standard erano piuttosto facili. Un certo numero di librerie erano in Boost da molto tempo: era stato dimostrato che funzionavano.

Le aggiunte ai concetti chiave nella lingua sono tuttavia molto più difficili da sperimentare, perché prima richiede la modifica di un compilatore. Una funzione C ++ 03 (l'esportazione dei modelli) era stata specificata senza il supporto del compilatore ... il risultato era orribile. Gli implementatori del frontend del compilatore EDG lo hanno segnalato come un compito enorme (molti anni uomo) per un guadagno molto scarso. Nessun altro compilatore ha mai provato a implementarlo. Non è una situazione comoda.

Funzioni come constexpr o static_assert erano facili (e già emulate dalle librerie). Lambda è abbastanza ben capito e implementato in una varietà di altre lingue, c'è già stata una ricerca approfondita, quindi era principalmente una questione di sintassi.

D'altra parte i concetti sono stati giudicati anche nuovi e non utilizzati . Erano stati specificati a malapena in tempo, non c'erano state prove del concetto ... e quindi sono stati respinti, piuttosto che aspettarli (o fare un errore).

Perché non seguire D? Non si può dire che non lo farà. Il comitato ha incoraggiato le persone a ripensare da zero, senza scadenze urgenti, e a provare le loro mani a includerle in un compilatore per vedere come interagiscono con altre funzionalità nella lingua. C'è in particolare la questione della separazione di concetti e mappe concettuali: dovrebbero essere raggruppati come uno o no?

FYI: Attualmente esiste una branca di Clang dedicata a questa sperimentazione, guidata da Larisse Voufo dell'università dell'Indiana.

Per lo standard del 2011, i concetti del C ++ erano ciò su cui si stava lavorando, e alla fine sono stati abbandonati da quello standard, perché non erano "abbastanza cotti". Il lavoro prosegue sui concetti del C ++ che possono portarli a diventare lo standard successivo. Potrebbe essere, tuttavia, che alcune persone lavoreranno su una proposta per il prossimo standard che è simile ai vincoli del modello di D. Resta da vedere se ciò accada o no. Per quanto ne so, non esisteva una proposta del genere per lo standard del 2011, quindi non c'era alcuna possibilità che lo facesse in quello standard indipendentemente dai suoi meriti, ma quello che lo farà o non lo farà nel prossimo standard è completamente sconosciuto a questo punto.

Non sono a conoscenza di alcun motivo importante per cui qualcosa di simile ai vincoli del modello di D non possa essere implementato per C ++, sebbene dato che C ++ è generalmente più limitato in ciò che può fare in fase di compilazione, potrebbe essere più difficile renderli funzionano abbastanza bene come fanno in D (anche se l'introduzione di cose come constexpr aiuta sicuramente).

Quindi, in realtà, penso che la risposta breve sia che non esiste una ragione tecnica per cui qualcosa di simile ai vincoli del modello di D non possa essere in C ++.

La domanda è se una tale proposta verrà presa per lo standard successivo e in che modo verrà confrontata con qualsiasi proposta simile sia fatta (ad esempio, proposte relative a concetti). Supponendo che possa essere fatta una proposta accettabile, mi aspetterei che qualcosa di simile ai concetti o ai vincoli del modello di D lo renderà lo standard successivo semplicemente perché c'è molto desiderio per questo. La domanda è se qualcuno può presentare una proposta che sia abbastanza solida e "abbastanza cotta" per essere accettabile.

Intendi i vincoli del modello di D?

Per quanto ne so, i concetti C ++ sono stati proposti per conto di boost :: concept. Il problema, qui, è che boost è una libreria scritta per C ++ 03. C ++ 11 ha altre funzionalità di sintassi che consentono di implementare alcune cose in un modo diverso, C ++ 03 consente (quindi, il potenziamento può essere riscritto sfruttando la nuova sintassi).

Il comitato standard ha abbandonato i concetti perché ci sarebbe voluto troppo tempo per specificarli (ritardando di nuovo l'approvazione del c ++ 11). Probabilmente andranno nella prossima versione di C ++.

Nel frattempo, la sintassi di D è diversa da quella in cui C ++ e D mantengono alcune capacità di valutazione dell'espressione in fase di compilazione C ++ non può sempre avere senza rompere il codice legacy (qualcosa che D non ha, avendo una storia più breve). Lo stesso C ++ ora ha static_assert e costexpr , che consente di migliorare le capacità di valutazione del tempo di compilazione. Potrebbe essere in futuro raggiungerà un livello simile.

Ecco un QA con Herb Sutter, parla di concetti al 15 ° minuto.

link

Se ti piace, eccone un altro: link

Ora come alla tua domanda. Perché non la versione D? Bene perché usarlo? Il C ++ è un linguaggio molto complesso e stabile. Ogni funzione deve essere selezionata con estrema attenzione, perché di solito deve essere supportata per decenni. Se osservi il primo standard C ++ e segui le revisioni, ci sono alcune funzionalità deprecate, ma anche quelle devono essere ancora supportate. Quindi ha senso progettare concetti al 100% in forma di C ++.

Per quanto riguarda il motivo per cui non è stato incluso in C ++ 0x. Bene perché era enorme. La proposta era lunga 100 pagine e molto difficile da implementare. È stato deciso che questa funzione ha bisogno di più tempo per maturare fino a quando non è inclusa nello standard.

Molto semplicemente, C ++ ha un bagaglio storico molto più grande di D. Sarebbe molto più facile implementare un sacco di cose se non fosse per il fatto che C ++ ha enormi quantità di codice storico che deve continuare funzionare correttamente e come previsto. D non ha questo problema.