Perché il preprocessore C/C++ aggiunge uno spazio qui?

Question

Ho un piccolo problema con un preprocessore che mi imbarazza e non riesco a trovare alcuna spiegazione nella documentazione/preprocessore/lingua specifica.

#define booboo() aaa 
booboo()bbb 
booboo().bbb 

viene pre-elaborato in:

aaa bbb <--- why is space added here 
aaa.bbb 

Dopo la manipolazione trigrammi, linee e commenti continuato, preprocessore funziona su direttive del preprocessore e si divide in ingresso in token pre-elaborazione e spazi bianchi. L'elenco di sostituzione di booboo comprende un token-token che è identificativo 'aaa'. booboo() bbb è diviso in token-to-pe: 'booboo', '(', ')', 'bbb'. La sequenza di 'booboo', '(', ')' è riconosciuta come invocazione macro funzionale e dovrebbe essere estesa a 'aaa' e imho in output dovrebbe apparire come 'aaabbb'. Ho detto che sembra che - per l'umano - assomiglierebbe a un token mentre il compilatore otterrebbe 2 token 'aaa' e 'bbb' poiché non è stato utilizzato alcun operatore '##' che consente la concatenazione di token in token. Perché/quale regola rende il preprocessore cpp (c) spazio aggiuntivo tra 'aaa' e 'bbb' quando 'booboo(). Bbb' risulta in 'aaa.bbb' senza spazio?

Ciò è dovuto al fatto che cpp tenta di rendere l'output (che è per lo più umano) non ambiguo? Umano non è in grado di dire che 'aaabbb' è composto da 2 token poiché vede solo l'ortografia dei token. Ho ragione? Ho letto la documentazione C99 sul preprocessore e la documentazione di gcc per cpp. Non vedo nulla al riguardo.

Se ho ragione abbiamo situazione simile qui:

#define baba() + 
baba()+ 
baba()- 

risultati in:

+ + 
+- 

In caso contrario (se '++' è l'uscita) sarebbe risultato a un essere umano come ' ++ 'token ma ci sarebbero 2 token' + 'e' + '. È come con l'operatore '##' che cpp controlla se la concatenazione produce un token valido, ma nei casi mostrati vuole impedire all'uomo che tale concatenazione sia stata eseguita? '+ -' non è ambiguo quindi non viene aggiunto spazio

Answer 1

Il risultato della preelaborazione è trasformare il file sorgente in un elenco di token. Nel tuo caso l'elenco di token sarà simile, dopo tokenizzazione:

.... 
booboo() 
bbb 
.... 

e poi, dopo la sostituzione macro:

.... 
aaa 
bbb 
.... 

Poi il compilatore traduce l'elenco di token in un file eseguibile.

Lo spazio vuoto che si sta visualizzando è solo un dettaglio di implementazione che il compilatore, ecc., Ha scelto di disporre i token di preelaborazione quando si visualizza un risultato intermedio. Gli standard non dicono nulla sui file di elaborazione intermedi. Non è richiesto che ci sia un programma separato per eseguire la pre-elaborazione.

Answer 2

Ho scritto un compilatore ANSI C all'inizio degli anni '90. Per quanto mi ricordo, un token commento/....../dovrebbe essere sostituito da un singolo spazio bianco. Le macro sostituiscono il testo, sul posto. Non è necessario che i token risultanti dalla sostituzione del testo di tali macro espansioni siano token di linguaggio C legali. Quando una macro è definita come testo 'aaa', è solo quel testo 'aaa' che si fa strada nel flusso di input. Il parser di C può o non può visualizzare token validi come risultato di ciò!

Quindi, dato:

definire booboo() aaa

espandibile booboo() bbb dovrebbe comportare testo aaabbb

Cosa che aaabbb medio è lasciata all'utente. Ma quel aaabbb non sarà preelaborato anche se capita di essere il nome di una macro. Questo è sicuro. Ma aaabbb potrebbe essere un identificativo utente - nessun problema lì.