Richiede uno specifico ordine di compilazione

1

Quando si progetta un linguaggio di programmazione compilato, è una cattiva idea richiedere un ordine specifico di compilazione di unità separate, in base alle loro dipendenze?

Per illustrare cosa intendo, considera C. C è l'opposto di quello che sto suggerendo. Esistono più file .c , che possono tutti dipendere l'uno dall'altro, ma tutte queste unità separate possono essere compilate da sole, senza un ordine particolare - solo per essere collegate insieme in un eseguibile finale più tardi.

Questo è principalmente dovuto ai file di intestazione. Consentono a unità separate di condividere informazioni tra loro e quindi le unità possono essere compilate in modo indipendente.

Se una lingua dovesse disporre di file di intestazione e mantenere solo i file sorgente e oggetto, l'unica opzione sarebbe quella di includere effettivamente le meta-informazioni dell'unità nel file oggetto dell'unità.

Tuttavia, ciò significherebbe che se l'unità A dipende dall'unità B, allora l'unità B dovrebbe essere compilata prima dell'unità A, quindi l'unità A potrebbe "importare" l'oggetto dell'unità B file, ottenendo così le informazioni richieste per la sua compilazione.

Mi sto perdendo qualcosa qui? È davvero l'unico modo per rimuovere i file di intestazione in lingue compilate?

    
posta Aber Kled 22.10.2013 - 23:37
fonte

3 risposte

3

Un modo possibile è generare prima i metadati ("file header") per ogni unità di compilazione. Questo normalmente non richiede alcuna dipendenza e può essere eseguito indipendentemente.

Quindi quando eseguono effettivamente il controllo del tipo / la generazione del codice, ciascuna unità di compilazione può fare riferimento ai metadati di altri per ottenere informazioni sul tipo.

Altrimenti avrai problemi se l'unità di importazione A dell'unità B e l'unità B importano anche l'unità A, non puoi compilarne nessuna prima di compilarne un'altra.

    
risposta data 22.10.2013 - 23:46
fonte
3

L'approccio che stai descrivendo è ciò che fanno linguaggi come Java e C #. Invece dei file di intestazione, i metadati vengono compilati nel file oggetto. Quelle lingue inoltre non compilano separatamente ogni file sorgente in un modulo (a .jar o .dll); prendono tutti i file sorgente che compongono un progetto e li compila tutti insieme, quindi li collegano in un eseguibile o in una libreria.

Una conseguenza è che le dipendenze dei moduli determineranno la sequenza di compilazione. Se il modulo B dipende dal modulo A (riferimenti), allora il modulo A deve essere compilato e collegato per primo, in modo che il modulo B possa fare riferimento ai metadati quando viene compilato. Se le classi in quei moduli hanno realmente un riferimento circolare tra loro, allora quelle classi devono essere nello stesso modulo.

È difficile vedere un altro approccio. Il linker deve conoscere i metadati di un modulo compilato, in modo che le informazioni debbano essere disponibili da qualche parte. O è nel codice sorgente, come un file di intestazione, oppure nel codice dell'oggetto.

    
risposta data 22.10.2013 - 23:52
fonte
1

Sì, è una cattiva idea anche se è molto comune.

Per le situazioni in cui l'applicazione è distribuita su più file di codice sorgente che potenzialmente condividono dipendenze cicliche, non c'è assolutamente nulla che impedisca a un compilatore di leggere e compilare tutto il codice sorgente insieme per evitare la sensibilità degli ordini. Tale compilatore dovrebbe anche offrire una compilazione incrementale per ridurre i tempi di compilazione quando vengono apportate piccole modifiche.

Per altre situazioni in cui esistono librerie o componenti che non devono essere ricompilati e non dipendono dalle applicazioni client, il compilatore dovrebbe leggere i metadati dal binario, generato da una compilazione precedente. Ci sono dipendenze, ma sono naturali e non un problema.

Come sopra, non è molto lontano da ciò che accade realmente in C # e Java. Le dipendenze si presentano a volte, e sarebbe bello se non lo facessero.

La disposizione dell'intestazione C ++ è veramente terribile, ma siamo bloccati con esso. Nessun designer di linguaggi moderni commetterebbe ancora quel crimine.

    
risposta data 19.02.2014 - 11:05
fonte