Czy C ++ 20 wymaga przechowywania kodu źródłowego w plikach?

Jednak nieco dziwne pytanie, jeśli dobrze pamiętam, kod źródłowy C ++ nie wymaga systemu plików do przechowywania plików.

Posiadanie kompilatora, który skanuje odręczne dokumenty za pomocą aparatu, byłoby zgodną implementacją. Chociaż praktycznie nie ma to większego sensu.

Jednak C ++ 20 dodaje teraz lokalizację źródłową z file_name. Czy to teraz oznacza, że ​​kod źródłowy powinien być zawsze przechowywany w pliku?

Nie, kod źródłowy nie musi pochodzić z pliku (ani przechodzić do pliku).

Możesz skompilować (i połączyć) C ++ całkowicie w potoku, umieszczając kompilator pośrodku, np

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

i tak jest od dziesięcioleci. Zobacz też:

• Czy można uzyskać odczyt GCC z potoku?
• Jak zrobić wyjście GCC na stdout?

Wprowadzenie std::source_locationw C ++ 20 nie zmienia tego stanu rzeczy. Po prostu jakiś kod nie będzie miał dobrze zdefiniowanej lokalizacji źródłowej (lub może być dobrze zdefiniowana, ale niezbyt znacząca). Właściwie, to powiedziałbym, że nacisk na definiowanie std::source_locationza pomocą plików jest nieco krótkowzroczny ... chociaż w sprawiedliwości, to jest po prostu mniej makro odpowiednik __FILE__i __LINE__które już istnieją w C ++ (i C).

@ HBv6 zauważa, że ​​jeśli wypiszesz wartość __FILE__podczas kompilacji przy użyciu GCC ze standardowego strumienia wejściowego:

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

uruchamianie wynikowych wydruków wykonywalnych <stdin>.

Kod źródłowy może nawet pochodzić z Internetu.

@Morwenn zauważa, że ​​ten kod:

#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);
}

działa na GodBolt (ale nie będzie działać na twoim komputerze - żaden popularny kompilator tego nie obsługuje).

Czy jesteś prawnikiem językowym? Ok, więc zapoznajmy się ze standardem.

Na pytanie, czy źródła programów C ++ muszą pochodzić z plików, nie ma jednoznacznej odpowiedzi w standardzie językowym. Patrząc na szkic standardu C ++ 17 (n4713), sekcja 5.1 [lex.separate] brzmi:

1. Tekst programu jest przechowywany w jednostkach zwanych plikami źródłowymi w tym dokumencie. Plik źródłowy wraz ze wszystkimi nagłówkami (20.5.1.2) i plikami źródłowymi (19.2) zawartymi przez dyrektywę preprocessingu #include, pomijając wszelkie linie źródłowe pominięte przez którąkolwiek z dyrektyw wstępnego przetwarzania warunkowego włączenia (19.1), nazywany jest jednostką tłumaczenia.

Zatem kod źródłowy niekoniecznie jest przechowywany w pliku jako takim, ale w „jednostce zwanej plikiem źródłowym”. Ale skąd się biorą dołączenia? Można by przypuszczać, że pochodzą z nazwanych plików w systemie plików ... ale to też nie jest wymagane.

W każdym razie std::source_locationnie wydaje się zmieniać tego sformułowania w C ++ 20 ani wpływać na jego interpretację (AFAICT).

Jeszcze przed C ++ 20 standard miał:

__FILE__

Przypuszczalna nazwa bieżącego pliku źródłowego (literał ciągu znaków).

Definicja jest taka sama dla source_location::file_name.

W związku z tym nie nastąpiła zmiana w zakresie obsługi implementacji bez systemu plików w C ++ 20.

Standard nie definiuje dokładnie, co oznacza „plik źródłowy”, więc interpretacja może zależeć od tego, czy odnosi się on do systemu plików. Przypuszczalnie mogłoby to oznaczać, że implementacja tworzy „odręczną notatkę, którą mi wtedy przekazałeś”, jeśli rzeczywiście identyfikuje ona „plik źródłowy” w tej implementacji języka.

Podsumowując: tak, źródła są standardowo określane jako „pliki”, ale czym jest „plik” i czy w grę wchodzi system plików, nie jest określone.