Cosa succede se, invece di guardare le specifiche del C ++, si analizza il comportamento (ispezionando il codice sorgente e il test con input di esempio) dei compilatori C ++ esistenti e si utilizza la conoscenza del C ++ per creare un nuovo compilatore? È un buon modo per implementare i linguaggi di programmazione? Quali sono i possibili svantaggi di questo approccio?
Questo succede continuamente nel settore: è il reverse engineering. Il compilatore in questo caso è una scatola nera (non hai idea di come faccia ciò che fa), ma hai una certa conoscenza dei suoi input e output. È quindi possibile creare un nuovo programma che esegua le stesse operazioni sugli ingressi per ottenere output identici.
In generale, non è un ottimo modo per fare qualcosa se si hanno le specifiche, ma ci sono casi in cui è necessario trovare il funzionamento interno di un sistema su cui non si ha controllo, e questa è una pratica perfettamente valida. Ad esempio, potresti perdere importanti dettagli di implementazione e casi d'angolo che non sempre compaiono nel codice, ma che sono chiaramente indicati nei documenti delle specifiche.
Per me, le tue domande suonano in modo molto simile a "e se invece di usare i progetti, progettiamo un ponte osservando altri ponti combinati con la nostra esperienza di guida e di passaggio su una serie di ponti in passato?"
... Non farei un passo su un bridge costruito con quella metodologia.
Le specifiche ci sono per un motivo. Le persone impiegano molto tempo ed energia per generare quei documenti da 100+ a 1000+ pagine in modo che ogni funzione e ogni funzionalità siano inchiodate e idealmente non rimane alcuna ambiguità quando si tratta di decidere come una determinata funzione dovrebbe funzionare.
In sostanza, quelle specifiche sono i progetti per un linguaggio di programmazione. Senza di loro il linguaggio sarebbe buono come quello ipotetico ponte di cui ho appena parlato.
Sì, è possibile decodificare un compilatore. Un esempio fuori dalla mia testa, microsoft ha decodificato il compilatore JavaScript originale (magari poi in livescript).
Perché questo è generalmente cattivo? Bene, considera quello che è successo con JS, Microsoft quasi esattamente duplicato JavaScript, fino agli errori. Ciò significava che ogni stravaganza nell'implementazione che in realtà non era destinata a esserci era ora parte della loro versione. Infatti, in seguito durante il processo di standardizzazione, MS ha forzato alcuni di questi bug nello standard *! Nel tuo esempio, è quasi impossibile decodificare C ++ / C, il comportamento definito dall'implementazione / il comportamento indefinito è dilagante! Non avresti modo di separare comportamenti standard, indefiniti e scorretti. Ciò porterebbe a un'implementazione substandard e eccessivamente complicata da parte tua.
TLDR: possibile, si. Consigliabile, no.
* E successivamente hanno versato denaro in dattiloscritto cercando di annullare alcuni di questi errori
Leggi altre domande sui tag reverse-engineering