Perché le macro non sono incluse nella maggior parte dei linguaggi di programmazione moderni?

So che sono implementati in modo estremamente pericoloso in C / C ++. Non possono essere implementati in un modo più sicuro? Gli svantaggi delle macro sono davvero abbastanza gravi da superare l'enorme potenza che forniscono?

Penso che il motivo principale sia che le macro sono lessicali . Ciò ha diverse conseguenze:

• Il compilatore non ha modo di verificare che una macro sia semanticamente chiusa, ovvero che rappresenti una "unità di significato" come fa una funzione. (Considera #define TWO 1+1: cosa significa TWO*TWO? 3.)

• Le macro non vengono digitate come le funzioni. Il compilatore non può verificare che i parametri e il tipo restituito abbiano un senso. Può solo controllare l'espressione espansa che utilizza la macro.

• Se il codice non viene compilato, il compilatore non ha modo di sapere se l'errore si trova nella macro stessa o nel luogo in cui viene utilizzata la macro. Il compilatore segnalerà il posto sbagliato per metà del tempo, oppure dovrà riportare entrambi, anche se uno probabilmente va bene. (Considera #define min(x,y) (((x)<(y))?(x):(y)): cosa dovrebbe fare il compilatore se i tipi di xe ynon corrispondono o non implementano operator<?)

• Gli strumenti automatizzati non possono lavorare con essi in modi semanticamente utili. In particolare, non è possibile avere elementi come IntelliSense per le macro che funzionano come funzioni ma si espandono in un'espressione. (Ancora una volta, l' minesempio.)

• Gli effetti collaterali di una macro non sono così espliciti come lo sono con le funzioni, causando potenziale confusione per il programmatore. (Considera ancora l' minesempio: in una chiamata di funzione, sai che l'espressione per xviene valutata solo una volta, ma qui non puoi sapere senza guardare la macro.)

Come ho detto, queste sono tutte conseguenze del fatto che le macro sono lessicali. Quando provi a trasformarli in qualcosa di più appropriato, finisci con funzioni e costanti.

Sì, le macro possono essere progettate e implementate meglio che in C / C ++.

Il problema con le macro è che sono effettivamente un meccanismo di estensione della sintassi del linguaggio che riscrive il codice in qualcos'altro.

• Nel caso C / C ++, non esiste un controllo di integrità fondamentale. Se stai attento, le cose vanno bene. Se commetti un errore o se usi in modo eccessivo le macro, potresti avere grossi problemi.

  Aggiungete a ciò che molte cose semplici che potete fare con le macro (stile C / C ++) possono essere fatte in altri modi in altre lingue.

• In altre lingue come vari dialetti Lisp, le macro sono meglio integrate con la sintassi del linguaggio principale, ma è ancora possibile riscontrare problemi con le dichiarazioni in una "perdita" di macro. Questo è affrontato da macro igieniche .

Breve contesto storico

Le macro (abbreviazione di macro-istruzioni) sono apparse per la prima volta nel contesto del linguaggio assembly. Secondo Wikipedia , le macro erano disponibili in alcuni assemblatori IBM negli anni '50.

Il LISP originale non aveva macro, ma furono introdotte per la prima volta in MacLisp a metà degli anni '60: https://stackoverflow.com/questions/3065606/when-did-the-idea-of-macros-user-defined-code -trasformazione-appaiono . http://www.csee.umbc.edu/courses/331/resources/papers/Evolution-of-Lisp.pdf . In precedenza, "fexprs" offriva funzionalità simili a macro.

Le prime versioni di C non avevano macro ( http://cm.bell-labs.com/cm/cs/who/dmr/chist.html ). Questi furono aggiunti tra il 1972 e il 1973 tramite un preprocessore. Prima di ciò, C supportava solo #includee #define.

Il macro-preprocessore M4 è nato nel 1977 circa.

Le lingue più recenti sembrano implementare macro in cui il modello operativo è sintattico piuttosto che testuale.

Quindi, quando qualcuno parla del primato di una particolare definizione del termine "macro", è importante notare che il significato si è evoluto nel tempo.

Le macro possono, come osserva Scott , consentire di nascondere la logica. Naturalmente, anche funzioni, classi, librerie e molti altri dispositivi comuni.

Ma un potente sistema macro può andare oltre, permettendoti di progettare e utilizzare sintassi e strutture che normalmente non si trovano nella lingua. Questo può essere davvero uno strumento meraviglioso: linguaggi specifici del dominio, generatori di codice e altro ancora, il tutto nel comfort di un unico ambiente linguistico ...

Tuttavia, può essere abusato. Può rendere il codice più difficile da leggere, comprendere e eseguire il debug, aumentare il tempo necessario ai nuovi programmatori per acquisire familiarità con una base di codice e portare a costosi errori e ritardi.

Quindi per i linguaggi destinati a semplificare la programmazione (come Java o Python), tale sistema è un anatema.

Le macro possono essere implementate in modo molto sicuro in alcune circostanze - ad esempio in Lisp, le macro sono solo funzioni che restituiscono il codice trasformato come una struttura di dati (s-espressione). Ovviamente, Lisp beneficia in modo significativo del fatto che è omoiconico e del fatto che "il codice è dati".

Un esempio di quanto possano essere semplici le macro è questo esempio Clojure che specifica un valore predefinito da utilizzare in caso di un'eccezione:

(defmacro on-error [default-value code]
  `(try ~code (catch Exception ~'e ~default-value)))

(on-error 0 (+ nil nil))               ;; would normally throw NullPointerException
=> 0                                   ;l; but we get the default value

Anche in Lisps, il consiglio generale è "non usare le macro a meno che non sia necessario".

Se non stai usando un linguaggio omoiconico, le macro diventano molto più complicate e le varie altre opzioni hanno alcune insidie:

• Macro basate su testo - ad esempio il preprocessore C - semplici da implementare ma molto difficili da usare correttamente in quanto è necessario generare la sintassi di origine corretta in forma testuale, comprese eventuali stranezze sintattiche
• DSLS basato su macro - ad esempio il sistema di template C ++. Complessa, può a sua volta comportare una sintassi complicata, può essere estremamente complessa per i compilatori e gli autori di strumenti da gestire correttamente poiché introduce una significativa nuova complessità nella sintassi e nella semantica del linguaggio.
• API di manipolazione AST / bytecode - ad es. Generazione di riflessione Java / bytecode - teoricamente molto flessibili ma possono diventare molto dettagliate: può richiedere molto codice per fare cose abbastanza semplici. Se ci vogliono dieci righe di codice per generare l'equivalente di una funzione a tre righe, allora non hai guadagnato molto con i tuoi sforzi di meta-programmazione ...

Inoltre, tutto ciò che una macro può fare alla fine può essere realizzato in qualche altro modo in un linguaggio completo turing (anche se questo significa scrivere un sacco di piatti). Come risultato di tutta questa delicatezza, non sorprende che molte lingue decidano che le macro non valgono davvero la pena di implementarle.

Per rispondere alle tue domande, pensa a quali macro vengono utilizzate principalmente (Attenzione: codice compilato dal cervello).

• Le macro utilizzate per definire le costanti simboliche #define X 100

Questo può essere facilmente sostituito con: const int X = 100;

• Le macro utilizzate per definire (essenzialmente) funzioni agnostiche di tipo inline #define max(X,Y) (X>Y?X:Y)

In qualsiasi linguaggio che supporti il ​​sovraccarico delle funzioni, questo può essere emulato in un modo molto più sicuro di tipo avendo funzioni sovraccaricate del tipo corretto o, in un linguaggio che supporta generici, da una funzione generica. La macro tenterà felicemente di confrontare qualsiasi cosa, inclusi puntatori o stringhe, che potrebbero essere compilati, ma quasi sicuramente non è quello che volevi. D'altra parte, se le macro sono state rese sicure per i tipi, non offrono vantaggi o praticità rispetto alle funzioni sovraccariche.

• Macro utilizzate per specificare collegamenti a elementi di uso frequente. #define p printf

Questo è facilmente sostituito da una funzione p()che fa la stessa cosa. Questo è abbastanza coinvolto in C (che richiede di usare ilva_arg() famiglia di funzioni) ma in molti altri linguaggi che supportano un numero variabile di argomenti di funzioni, è molto più semplice.

Supportare queste funzionalità all'interno di una lingua piuttosto che in un linguaggio macro speciale è più semplice, meno soggetto a errori e molto meno confuso per gli altri che leggono il codice. In realtà, non riesco a pensare a un singolo caso d'uso per le macro che non può essere facilmente duplicato in un altro modo. L' unico posto in cui le macro sono veramente utili è quando sono legate a costrutti di compilazione condizionali come #if(ecc.).

Su questo punto, non discuterò con te, poiché credo che le soluzioni non preprocessore alla compilazione condizionale in linguaggi popolari siano estremamente ingombranti (come l'iniezione di bytecode in Java). Ma linguaggi come D hanno messo a punto soluzioni che non richiedono un preprocessore e non sono più ingombranti rispetto all'utilizzo dei condizionali del preprocessore, pur essendo molto meno soggetti a errori.

Il problema più grande che ho riscontrato con le macro è che quando sono molto usati possono rendere il codice molto difficile da leggere e mantenere poiché ti permettono di nascondere nella macro una logica che può essere o meno facile da trovare (e che può essere o meno banale ).

Per cominciare, notiamo che i MACRO in C / C ++ sono molto limitati, soggetti a errori e non molto utili.

I MACRO implementati nel linguaggio dell'assemblatore LISP o z / OS possono essere affidabili e incredibilmente utili.

Ma a causa dell'abuso della funzionalità limitata in C hanno una cattiva reputazione acquisita. Quindi nessuno implementa più le macro, invece ottieni cose come i modelli che fanno alcune delle semplici cose che le macro erano solite fare e cose come le annotazioni di Java che fanno alcune delle cose più complesse che le macro sono solite fare.