Problemi con l'eredità del STL

Question

In http://www.stepanovpapers.com/notes.pdf, Alexander Stepanov menzioni:

È interessante notare che gli unici esempi di eredità che rimasero in STL ereditare dalle classi vuote. Originariamente, c'erano molti usi di ereditarietà all'interno dei contenitori e persino iteratori, ma dovevano essere rimossi a causa dei problemi causati.

Quali sono i problemi tecnici che hanno impedito l'utilizzo dell'ereditarietà nell'STL?

Answer 1

Penso che inserirò alcuni commenti direttamente da Alexander Stepanov (http://www.stlport.org/resources/StepanovUSA.html).

Domanda:

STL è piena di usi creativi di modelli, come simbolici tipi esportati da classi o l'adattamento di configurazione di un insieme di algoritmi sovraccaricati sul tag iteratore. Certamente, nessun libro di programmazione C++ standard parla di questi idiomi. Come sei arrivato a questi idiomi di codice C++?

Risposta:

sapevo esattamente quello che stavo cercando di realizzare. Quindi ho ottimizzato la lingua finché non sono riuscito a cavarmela. Ma mi ci sono voluti molti anni per scoprire tutte le tecniche. E ho avuto molte false partenze. Ad esempio, Ho passato anni a cercare di trovare un po 'di utilizzo per l'ereditarietà e i virtuals, prima di capire perché quel meccanismo era fondamentalmente imperfetto e non si dovrebbe usare . Sono molto felice che nessuno possa vedere tutti i passaggi intermedi - la maggior parte di loro erano molto sciocchi. Mi ci vogliono anni per inventare qualcosa di decente. Ha anche aiutato che Bjarne fosse disposto a mettere certe funzionalità nella lingua solo per abilitare alcune delle mie espressioni idiomatiche con . Una volta si riferiva ad esso come "just in time language design".

Avanti, mi permetto di indirizzarvi verso questa grande risposta:

https://stackoverflow.com/a/1039904/210971

OOP non è il Santo Graal. È un'idea carina, ed è stato piuttosto un miglioramento dello rispetto alle lingue procedurali negli anni '70 quando era stato inventato lo . Ma onestamente non è tutto ciò che è rotto per essere. In molti casi è goffo e prolisso e in realtà non promuove il codice o la modularità riutilizzabile .

Ecco perché la comunità C++ è oggi molto più interessata alla programmazione generica e perché tutti stanno finalmente iniziando a rendersi conto che la programmazione funzionale è abbastanza intelligente. OOP da solo non è una bella vista.

E ora qualcosa da me:

regole OOP determina il modo in cui (ereditarietà, polimorfismo, ecc) un programmatore pensa interazione tra le cose (oggetti, entità, triboli, etc.).

Questo è chiaramente visibile in questo semplice esempio Java da tempo prima di aggiungere il supporto per i generici (ma questi non sono così prolissi come in C++).

List v = new ArrayList(); 
v.add("test"); 
Integer i = (Integer)v.get(0); // Run time error 

Sebbene il codice viene compilato senza errori, esso genera un'eccezione runtime (java.lang.ClassCastException) durante l'esecuzione della terza riga di codice. Questo tipo di problema può essere evitato utilizzando i farmaci generici ed è la motivazione principale per l'utilizzo di farmaci generici.

List<String> v = new ArrayList<>(); 
v.add("test"); 
Integer i = v.get(0); // (type error) compilation-time error 

Alexander Stepanov riconosciuto che l'approccio generico può risolvere questo problema, contribuire a fornire separazione logica (astrazione) tra strutture dati e algoritmi. Questo è il motivo per cui c'è tanta enfasi su iteratori, funtori e molti altri idiomi che si adattano molto bene al mondo generico.