C ++ 20 impone che il codice sorgente venga memorizzato nei file?

Una domanda un po 'strana, tuttavia, se ricordo bene, il codice sorgente C ++ non richiede un file system per memorizzare i suoi file.

Avere un compilatore che scansiona documenti scritti a mano tramite una fotocamera sarebbe un'implementazione conforme. Anche se praticamente non ha molto senso.

Tuttavia C ++ 20 ora aggiunge la posizione di origine con file_name. Questo ora implica che il codice sorgente debba essere sempre memorizzato in un file?

No, il codice sorgente non deve provenire da un file (né andare a un file).

Puoi compilare (e collegare) C ++ completamente all'interno di una pipe, mettendo il tuo compilatore nel mezzo, ad es

generate_source | g++ -o- -xc++ - | do_something_with_the_binary

ed è stato così per decenni. Guarda anche:

• È possibile far leggere a GCC da una pipe?
• Come rendere l'output di GCC su stdout?

L'introduzione di std::source_locationin C ++ 20 non cambia questo stato di cose. È solo che parte del codice non avrà una posizione di origine ben definita (o potrebbe essere ben definita, ma non molto significativa). In realtà, direi che l'insistenza sulla definizione di std::source_locationfile usando è un po 'miope ... anche se in tutta onestà, è solo un equivalente senza macro di __FILE__e __LINE__che già esistono in C ++ (e C).

@ HBv6 nota che se si stampa il valore di __FILE__durante la compilazione utilizzando GCC dal flusso di input standard:

echo -e '#include <iostream>\n int main(){std::cout << __FILE__ ;}' | g++ -xc++  -

eseguendo le stampe eseguibili risultanti <stdin>.

Il codice sorgente può anche provenire da Internet.

@ Morwenn nota che questo codice:

#include <https://raw.githubusercontent.com/Morwenn/poplar-heap/master/poplar.h>

// Type your code here, or load an example.
void poplar_sort(int* data, size_t size) {
    poplar::make_heap(data, data + size);
    poplar::sort_heap(data, data + size);
}

funziona su GodBolt (ma non funzionerà sulla tua macchina - nessun compilatore popolare lo supporta).

Sei un avvocato linguistico? Ok, quindi consultiamo lo standard ..

La domanda se i sorgenti del programma C ++ debbano provenire da file non trova una risposta chiara nello standard del linguaggio. Guardando una bozza dello standard C ++ 17 (n4713), la sezione 5.1 [lex.separate] si legge:

1. Il testo del programma è contenuto in unità chiamate file sorgente in questo documento. Un file sorgente insieme a tutte le intestazioni (20.5.1.2) e ai file sorgente inclusi (19.2) tramite la direttiva di pre-elaborazione #include, meno qualsiasi riga di sorgente saltata da una qualsiasi delle direttive di pre-elaborazione di inclusione condizionale (19.1), è chiamato unità di traduzione.

Quindi, il codice sorgente non è necessariamente conservato in un file di per sé, ma in una "unità chiamata file sorgente". Ma allora, da dove vengono gli include? Si potrebbe presumere che provengano da file con nome sul filesystem ... ma anche questo non è obbligatorio.

In ogni caso, std::source_locationnon sembra cambiare questa formulazione in C ++ 20 o influenzare la sua interpretazione (AFAICT).

Anche prima del C ++ 20, lo standard aveva:

__FILE__

Il presunto nome del file sorgente corrente (una stringa di caratteri letterale).

La definizione è la stessa per source_location::file_name.

Pertanto, non è stata apportata alcuna modifica al supporto per le implementazioni senza file system in C ++ 20.

Lo standard non definisce esattamente cosa significhi "file sorgente", quindi se si riferisce a un file system può essere interpretato. Presumibilmente, potrebbe essere conforme per un'implementazione produrre "la nota scritta a mano che mi hai dato proprio in quel momento" se questo identifica effettivamente il "file sorgente" in quell'implementazione del linguaggio.

In conclusione: Sì, le fonti sono indicate come "file" dallo standard, ma cosa sia un "file" e se sia coinvolto un file system non è specificato.