C ++ 20은 파일에 저장되는 소스 코드를 요구합니까?


106

그러나 약간 이상한 질문이지만 올바르게 기억한다면 C ++ 소스 코드는 파일을 저장할 파일 시스템이 필요하지 않습니다.

카메라를 통해 손으로 쓴 종이를 스캔하는 컴파일러가 있으면이를 준수 할 수 있습니다. 실제로 그다지 의미가 없지만.

그러나 C ++ 20은 이제 file_name. 이제 소스 코드가 항상 파일에 저장되어야 함을 의미합니까?


13
이것은 영원히 C에있었습니다 __FILE__. 클래스 source_location는 함수 호출 사이트에서 얻을 수 있습니다.
StaceyGirl

28
손으로 쓴 종이에 파일 이름을 줄 수 없습니까?
Jarod42

8
소스 코드가 파일에 있는지 여부에 관계없이 구현 세부 사항이라고 생각합니다. 컴파일러가 stdin을 통해 소스 코드를 제공 할 수 있다면 소스는 데이터베이스에있을 수 있습니다.
Eljay

8
내 예제는 약간 틀릴 수 있지만 TCC와 같은 실시간 컴파일러를 사용하는 경우 메모리에서 직접 컴파일하더라도 오류보고를 위해 항상 사람이 읽을 수있는 소스 이름을 제공 할 수 있습니다. "파일 이름"이 있다는 것은 파일로 저장된다는 것을 의미하지 않습니다.
user7860670

2
<iostream> 개발자가 작성한 파일이 아니라 파일이 아닐 수도 있는 구현 파일 일 것입니다.

답변:


110

아니요, 소스 코드는 파일에서 가져올 필요가 없습니다 (파일로 이동하지 않아도됩니다).

파이프 내에서 C ++를 완전히 컴파일 (및 링크)하여 컴파일러를 중간에 놓을 수 있습니다.

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

수십 년 동안 그랬습니다. 또한보십시오:

std::source_locationC ++ 20 의 도입은 이러한 상황을 변경하지 않습니다. 일부 코드에는 잘 정의 된 소스 위치가 없거나 잘 정의되어 있지만 그다지 의미가 없을 수 있습니다. 사실, 난 정의에 대한 주장 말할 것 std::source_location공평, 그냥 매크로 이하의 동등한 비록 사용하여 파일이 ... 약간의 근시 인 __FILE____LINE__어느 이미 C에 존재 ++ (그리고 C).

@ HBv6 __FILE__은 표준 입력 스트림에서 GCC를 사용하여 컴파일 할 때 의 값을 인쇄하면 다음과 같이 표시 됩니다.

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

결과 실행 파일을 실행하면 인쇄 <stdin>됩니다.

소스 코드는 인터넷에서 올 수도 있습니다.

@Morwenn은이 코드를 다음과 같이 언급합니다.

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

GodBolt에서 작동합니다 (그러나 여러분의 컴퓨터에서는 작동하지 않습니다. 인기있는 컴파일러는 이것을 지원하지 않습니다.)

당신은 언어 변호사입니까? 자, 표준을 참조합시다 ..

C ++ 프로그램 소스가 파일에서 가져와야하는지 여부에 대한 질문은 언어 표준에서 명확하게 답변되지 않았습니다. C ++ 17 표준 (n4713)의 초안을 살펴보면 섹션 5.1 [lex.separate]은 다음과 같습니다.

  1. 프로그램의 텍스트는이 문서에서 소스 파일이라는 단위로 유지됩니다. 모든 헤더 (20.5.1.2) 및 전처리 지시문 #include를 통해 포함 된 소스 파일 (19.2)과 함께 소스 파일과 함께 조건부 포함 (19.1) 전처리 지시문에서 건너 뛴 소스 행을 제외하고 변환 단위라고합니다.

따라서 소스 코드는 반드시 파일 자체가 아니라 "소스 파일이라고하는 단위"에 보관됩니다. 그렇다면 포함은 어디에서 왔습니까? 파일 시스템의 명명 된 파일에서 온다고 가정 할 수 있지만 그 역시 필수 사항은 아닙니다.

여하튼, std::source_locationC ++ 20에서이 표현을 변경하거나 해석 (AFAICT)에 영향을 미치지 않는 것 같습니다.


9
이 파이프는 표준 목적 상 "소스 파일"입니다.
melpomene

5
저는 "프로그램의 텍스트는 이 국제 표준에서 소스 파일 (또는 전처리 파일 ) 이라는 단위로 유지됩니다."라고 정의하는 C 표준을보고 있습니다. 따라서 코드가 저장되는 곳마다 Standardese의 "소스 파일"이됩니다. (부록 : 유사한 언어가 [lex]의 C ++ 표준에 있습니다.)
melpomene

8
@melpomene : 단위는 단지 소스 파일 이라고 불리며 실제로 소스 파일이어야한다고 말하는 것은 아닙니다. 그러나 나는 이것을 포함하도록 대답을 편집 할 것입니다.
einpoklum

13
방금 GCC로 시도했습니다 : "echo '#include <stdio.h> \ nint main () {printf ("% s \\ n ", __FILE__); return 1;}'| gcc -o test -xc-"( 인용없이). 실행되면 <stdin>을 출력합니다.
HBv6

11
표준 (및 과학)의 용어와 이름 및 개념에 대한 재미있는 점이 있습니다. 일반적으로 원자 적입니다. 즉, "소스 파일"은 "소스"인 "파일"일 필요는 없습니다. 사실 "파일"이라는 용어는 정의되지 않을 수도 있습니다. 수학에서 숫자와 비교해보십시오. " number ","natural nmber ","rational number ","real number "등
Joker_vD

53

C ++ 20 이전에도 표준은 다음과 같습니다.

__FILE__

현재 소스 파일의 추정 이름 (문자열 리터럴)입니다.

정의는 source_location::file_name.

따라서 C ++ 20에서 파일 시스템없는 구현에 대한 지원과 관련하여 변경된 사항은 없습니다.

표준은 "소스 파일"이 무엇을 의미하는지 정확히 정의하지 않으므로 파일 시스템을 참조하는지 여부는 해석에 달려 있습니다. 아마도 해당 언어 구현에서 실제로 "소스 파일"을 식별하는 경우 "그때 내게 준 손으로 쓴 메모"를 생성하는 구현에 적합 할 수 있습니다.


결론 : 예, 소스는 표준에서 "파일"이라고하지만 "파일"이 무엇인지, 파일 시스템이 관련되어 있는지 여부는 지정되지 않습니다.


2
@Yksisarvinen 나는 규칙의 "추정"자격 정확히 의도를 모르는,하지만 난 가정 이 필요 도다 파일 이름이 절대 또는 표준 아니라의 관점에서 상대 이름이 될 수 있음을 명확히인지 :) 컴파일러로 충분합니다. 내가 틀렸을 수도있다.
eerorika

4
"왼쪽 캐비닛, 세 번째 서랍, 네 번째 빨간색 탭 폴더, 17 페이지"가scanner-c++ 반환되는 것을 볼 수 있습니다 .
dmckee --- 전 중재자 새끼 고양이

2
FWIW, POSIX 의미에서 파이프 (또는 다른 파일 같은 것)는 "파일"입니다. 따라서 stdin / stdout은 디스크 파일 등이 아니라 "파일"입니다.

3
@Yksisarvinen :위원회는 모호한 구현이 평범한 행동에 반하는 일을해야 할 합당한 이유가있을 수있는 상황을 종종 허용합니다. 그렇게 할 때 컴파일러 작성자에게 고객이 일반적인 동작이 다른 대안보다 더 유용하거나 덜 유용하다고 판단하는지 여부를 판단합니다. 그러한 것들이 구현 자의 판단에 맡겨 졌다는 사실은 "모호함"으로 간주 될 수 있지만, 훌륭한 컴파일러 작성자는위원회가 할 수있는 것보다 고객의 요구에 대해 더 많이 알 것이기 때문에 의도적 인 것입니다.
supercat

1
@dmckee ... 문에 '표범을 조심하라'라는 표지판이있는 사용하지 않는 화장실에서.
Andrew Henle
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.