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


19

Come molti di voi sanno, i concetti , l'approccio di C ++ per limitare i possibili tipi per un argomento modello non è stato incluso in C ++ 11.

Ho imparato che il linguaggio di programmazione D 2.0 ha una funzione simile per la sua programmazione generica. La sua soluzione mi sembra abbastanza elegante e semplice.

Quindi la mia domanda è perché C ++ non può usare un approccio simile .

  • L'obiettivo del concetto C ++ potrebbe essere più grande di quello che fornisce l'implementazione di D?
  • O l'eredità del C ++ gli impedisce di adottare un simile approccio?
  • O qualsiasi altro?

Grazie per le tue risposte

ps Per vedere alcuni esempi della potenza di programmazione generica di D, fare riferimento a questo: /programming/7300298/metaprogramming-in-c-and-in-d/7303534#7303534


2
Questa domanda avrebbe dovuto essere migrata su programmers.se. (Ho votato a favore, ma 3 voti erano per "non costruttivo").
iammilind,

3
Penso che la domanda potrebbe non essere scritta nel modo più costruttivo, ma che ci sia valore. Mi piacerebbe che qualcuno spiegasse come D gestisce i concetti ed è in grado di confrontarlo con i due approcci principali che il comitato C ++ ha adottato i concetti prima che decidessero di rinviare del tutto la funzionalità ... Se questo deve essere chiuso, allora dovrebbe il minimo è spostato ai programmatori
David Rodríguez - dribeas,

2
@ David: ho votato per la riapertura (e quindi forse, può essere spostato sul sito dei programmatori)
Nawaz,

1
D'accordo con David. Non vedo alcun motivo per dire preventivamente "non costruttivo" prima che qualcuno possa anche provare a costruire qualcosa. con 0 risposte, la "costruttività" è 0/0 quindi indeterminata.
Emilio Garavaglia,

1
@ jj1: puoi fornire una breve spiegazione dell'approccio di D a quelli di noi che non conoscono la lingua?
David Rodríguez - dribeas,

Risposte:


9

Lo standard di C ++ è un documento normativo, che stabilisce regole che rimarranno (per lo più non interessate) nei documenti futuri. Pertanto, il comitato ha adottato un approccio molto cauto nei confronti dei suoi aggiornamenti.

Le aggiunte alla libreria standard sono state in qualche modo facili. Numerose biblioteche erano in Boost da molto tempo: era stato dimostrato che funzionavano.

Le aggiunte ai concetti di base nel linguaggio sono tuttavia molto più difficili da sperimentare, poiché richiede innanzitutto la modifica di un compilatore. Una funzione C ++ 03 (l'esportazione di 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 (diversi anni-uomo) con un guadagno molto scarso. Nessun altro compilatore ha mai provato a implementarlo. Non è una situazione comoda.

Funzionalità come constexpro static_asserterano facili (e già emulate dalle librerie). Le lambda sono abbastanza ben comprese e implementate in una varietà di altre lingue, ci sono già state ampie ricerche, quindi era principalmente una questione di sintassi.

D'altra parte i concetti sono stati giudicati troppo nuovi e non testati . Sono stati appena specificati in tempo, non c'erano 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 scadenza urgente, e a provare a includerle in un compilatore per vedere come interagiscono con altre funzionalità della lingua. C'è in particolare la questione della separazione di concetti e mappe concettuali: dovrebbero essere raggruppati come uno o no?

FYI: Al momento esiste una filiale di Clang dedicata a questa sperimentazione, guidata da Larisse Voufo dell'Università dell'Indiana.


Commento secondario: la parola chiave export era in realtà una funzione c ++ 98 (la standardizzazione originale). La rettifica del 2003 riguardava principalmente le funzioni della biblioteca.
ex0du5,

@ ex0du5: giusto, il '03 è una revisione minore dello standard C ++ 98, che riguardava principalmente correzioni.
Matthieu M.,

3

Per lo standard del 2011, i concetti di C ++ erano ciò su cui si stava lavorando e alla fine sono stati abbandonati da quello standard, perché non erano "abbastanza cotti". Il lavoro continua sui concetti C ++ che possono portarli a diventare il prossimo standard. 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ò accade o meno. Per quanto ne so, non vi era alcuna proposta in tal senso per lo standard 2011, quindi non c'era alcuna possibilità che lo trasformasse in quello standard indipendentemente dai suoi meriti, ma ciò 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 farli funzionare come così come fanno in re (anche se l'introduzione di cose come constexprcertamente aiuta).

Quindi, davvero, penso che la risposta breve sia che non esiste alcun motivo tecnico per cui qualcosa di simile ai vincoli del modello di D non possa essere in C ++.

La domanda è se tale proposta verrà presentata per il prossimo standard e come si confronterà con qualsiasi proposta simile venga fatta (ad es. Proposte relative a concetti). Supponendo che possa essere fatta una proposta accettabile, mi aspetterei pienamente che qualcosa di simile ai concetti o ai vincoli del modello di D entrerà nello standard successivo semplicemente perché c'è molto desiderio. La domanda è se qualcuno può presentare una proposta che sia sufficientemente solida e "sufficientemente preparata" per essere accettabile.


2

Intendi i vincoli del modello di D?

Per quanto ne so, i concetti C ++ erano 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 determinate cose in un modo diverso che C ++ 03 consente (quindi, il boost stesso può essere riscritto sfruttando la nuova sintassi).

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

Nel frattempo, la sintassi D è diversa rispetto a C ++ e D stessa mantiene alcune capacità di valutazione delle espressioni al momento della compilazione che C ++ non può sempre avere senza rompere un codice legacy (qualcosa che D non ha, con una storia più breve). Lo stesso C ++ ora ha static_asserte costexpr, ciò consente di migliorare le capacità di valutazione del tempo di compilazione. Potrebbe essere in futuro raggiungerà un livello simile.


2

Ecco un QA con Herb Sutter, parla di concetti al limite dei 15 minuti.

http://channel9.msdn.com/Shows/Going+Deep/Herb-Sutter-C-Questions-and-Answers

Se ti piace, eccone un altro: http://channel9.msdn.com/Shows/Going+Deep/Conversation-with-Herb-Sutter-Perspectives-on-Modern-C0x11

Ora per quanto riguarda la 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 guardi al primo standard C ++ e segui le revisioni, ci sono alcune funzionalità obsolete, ma anche quelle devono essere ancora supportate. Quindi ha senso progettare concetti per adattarsi al 100% al 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 attuare. È stato deciso che questa funzione richiede più tempo per maturare fino a quando non viene inclusa nello standard.


2

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


Forse hai appena espresso ciò che è sbagliato, ma il problema non è un codice legacy, il problema è che qualsiasi nuova funzionalità sarà presente nella lingua per decenni e deve essere supportata. Ciò significa che ogni nuova funzionalità deve essere scelta con molta attenzione.
Let_Me_Be,

@Let_Me_Be: Esatto, il problema è nel codice legacy che avremo dieci anni in più se entriamo in concetti ora.
David Thornley,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.