문자열 내에서 매크로 사용하기 질문

전처리 과정에서 직접 문자열을 넣는 방식으로 이루어지는 것이라는 이런
것도 있습니다.

#include <stdio.h>
 
#define str(x) #x
#define xstr(x) str(x)
#define AA 04
 
int main(void)
{
    printf("%" xstr(AA) "d\n", 1);
 
    return 0;
}

--
Jun, Woong (woong at icu.ac.kr)
Web: http://www.woong.org (서버 공사중)

[depth 가 깊어져 따로 모아 답변 답니다]

가치 있는 내용이 별로 없어 어지간하면 그냥 지나가려 했는데 하도
이야기가 길어져 더 이상 보고 있을 수 없네요. (한숨이 나옵니다)

> 애초에 제기된 문맥과 자꾸 동떨지느데요,
> provision이 보여주기 위한 구성 요소로 normative elements 를 사용하고 있습니다.
> normative elements 에는 general/technical 이 있고요.
> general 안에 scope/normative reference가 있고 technical 안에 option으로 terms and definitions
> 와 같은 것을 둘 수 있고 scope에 맞게 이름을 지어서 넣을 수 있습니다.

이렇게 허겁지겁 드시면 또 저번처럼 탈납니다.

> 구리니까

뭐가 구린진 모르겠습니다 ;-)

> techical 안에 본문이 들어간단 말입니다. 이름을 어떻게 지어라고 한 것이 normative 라고 한 적이
> 있습니까? 4. Conformance 가 이름이 없으면 안되는 normative elements 라고 했죠.
> 애초에 시작된 주제에서 왜 자꾸 벗어나세요.
>

처음에는 "4. Conformance" 의 의미를 문제 삼아 correct 와 conforming 을
엮어보려다가, 제가 정의를 인용해 clause 제목이 내용 해석에 절대적 영향
을 줄 수 있는 normative element 가 아님을 보이자, 금새 언제 그런 말
했었냐며 발뺌을 하시는군요. 님 말씀대로 subclause 와는 달리 clause 의
경우 반드시 제목을 가져야 한다는 것을 놓고 이야기하는 것이었다면 벌써
한참 전에 나온 이야기입니다.

http://kldp.org/node/81963#comment-390454

지금 하고 계신 말씀은 한참 전부터 이 논의를 따라오신 모든 분들이
알고있던 사실을 님 혼자서 논란거리로 만들어 지금까지 주장해 오셨다는
얘기뿐이 되지 않습니다.

> 물론 이름을 지을 때 일반론에서 4.3 Homogeneity 같은 것도 생각해야 하고 terms and difinitions 에서는
> nomative 로 Annex D에서 얘기 하고 있습니다.
>

혼자 공부한 내용은 집에 있는 개인 노트에 정리하시는 것이 좋겠습니다.

---------------------------------------------------------------------

표준에 대해 기본 개념이 갖춰지지 않은 상태로 몇일 보게 되었다고 뭔가
의미있는 것들을 깨우친 것처럼 말씀하지 마시기 바랍니다.

> > 그리고 제 영어
> > (영한/영영) 사전은 "erroneous" 의 동의어로 wrong 과 incorrect 를,
> > 한국어 의미로 "잘못된"을 보여주고 있습니다.
>
> erroneous의미를 문제삼은 적 없지만 이것도 오류라는 단어가 있는 상태에서 적절한
> 단어가 아니라고 생각합니다.
>

표준과 ISO 2382-1 이 따로 정의해주지 않은 용어의 개념은 어디서 규정해
준다고 말씀드렸죠? (기억이 나지 않으시면 지금까지의 논의를 천천히
읽으면서 살펴보시길 추천합니다.)

제 영어 사전이 바로 Directives 에서 언급하고 있는 사전 중 하나입니다.

> 다른 관련 것들도 표준 관련 문서를 볼수록 의문점이 많지만 나중으로 미루도록 하고,
>

부탁입니다만, 의문점이 생겨도 수용적 자세로 하는 질문이 아닌 이상
최소한 저한텐 말씀하지 말아 주십시오. 님같이 의미 전달이 어렵고 고집만
강한 분께 답변할 생각만해도 한숨부터 나옵니다. 계속 이런 방식이라면
님과 저 사이에 "나중"은 없습니다.

> 다시, 잘못된 프로그램 구조로 돌아가서 얘기하면, 문법성 오류를 구조의 잘못이라고 한데
> 있습니다.

엄밀히 말해 문법 오류는 undefined behavior 보다 더 엄격한 제약을 받는
constraint violation 입니다. 하지만 행동의 측면에서, syntactic rule
을 어긴 프로그램과 semantic rule 을 어긴 프로그램 모두 undefined
behavior 로 기술됩니다. "구조"라는 표현에 무의미하게 딴지 걸며 문법성
오류만을 연결한 사람은 (제가 보기엔) 님 혼자만이었습니다.

> construct 라는 의미에 사전적으로 구조의 의미도 있습니다. 사전적인 의미에서
> architecture, structure, construct 모두 구조로 번역할 수 있습니다. 그러나 그냥 사전에
> 있는 한 단어를 대치하는 것이 번역이 아니라는 사실을 잘 아시듯이, 문맥을 살려줘야 합니다.

제가 "구조"라는 단어를 사용했을 때 어떤 의도로 사용했는지는 이미 말씀
드린 바 있습니다. 제가 영어 논의 등을 운운하며 construct 를
언급했음에도 불구하고 structure, architecture 라는 거리감 있는 단어를
꾸준히 끌고 들어온 것은 님입니다. 잔잔한 호수에 스스로 돌 던져놓고
파문이 일었다고 큰 소리 내시는 셈입니다.

> C 표준에서 construct는 분명 구문, 의미상 규칙으로 이루져 있음을 알고 있습니다. 이것은
> 언어를 구성하는 요소로서 말하고 있는 것입니다.

그렇게 어렵게 따지지 않아도 문맥을 통해서 자연스럽게 뜻이 배어 나올
수 있는 용어입니다. 그렇지 않았다면 표준이 본문을 통해 분명히 정의해
주었을 것입니다. 또한, 그 정도로 깊이 있게 탐구해야 할 용어는
construct 같은 애들이 아니라 character 같은 애들입니다 - construct 에
집착하는 것은 에너지 낭비일 뿐입니다.

> 6.2.7p3에서
>
> 인용:
>
> A composite type can be constructed from two types that are compatible
>
> 6.4.4.4p12
>

부적절한 인용입니다. 여기서 "constrcut" 는 "구조(something built)"의
의미라기 보다는 "생성(produced)"의 의미에 가깝습니다. composite type
이 무엇인지 알고는 인용하셨습니까? (프로그래머에게) composite type 은
소스 상에 눈으로 보이는 존재가 아니라 비슷한 type 들의 합성으로
"허공에" 생성되는 존재에 가깝습니다. 따라서 program construct 로부터
유도 혹은 유추될 수 있는 것이지, 구체적인 program construct 자체를
구성하는 개념은 아닙니다.

> 인용:
>
> The construction '\0' is commonly used to represent the null character.
>

맞습니다. 여기서의 construction 이 제가 "프로그램 구조"에서 언급한
"구조"에 부합하는 의미입니다.

> 표준에서 program structure란 단어가 분명히 있기 때문에 번역할 때는 이 둘과 구분해
> 줘야 합니다.
>

construct/construction 만 존재하던 곳에 structure 를 끌고 들어온 분은
님입니다. (최소한 제가 "construct" 를 언급한 이후) 다른 사람들은 오해
없이 다들 잘 이해하고 있는데 혼자서 construct 와 structure 를
혼동하더니 대단한 발견이라도 한 것처럼 글을 남기시는 이유는...

> 참고로 한국정보통신기술협회(TTA)에서 정의한 언어 구성소는 다음과 같습니다.
>
> 인용:
>
> 언어 구성소 [ 言語構成素, language construct A ]
> 프로그램 언어를 기술할 때 필요한 구문상의 구성 요소. 식별자, 명령문, 모듈 등이 있다.
>
>
> 영어를 그대로 쓰지 않았을 경우에는 그에 합당한 번역을 해 줘야 하는 것입니다.
> 제가 처음에 Architecture적인 의미로 듣고 의문을 제기하는 것은 합당하다고 생각합니다.
>

알겠습니다. 제가 항상 저와 대화를 나누고 논의를 하던 분들만을 생각해
표준에 대한 경험이 적은 님이 "구조"라는 용어에 (제 의도와 다른
의미의) structure 와 architecture 를 생각하실 수 있다는 사실은 전혀
생각하지 못했습니다. 하지만 아직도 "구조"의 의도한 의미로 보다 분명한
"construct/construction" 을 한참 전에 언급했음에도 불구하고 끝까지
structure/architecture 와 혼동된다 말씀하시는 님이 온전히 이해가
되지는 않습니다.

> language lawyer적인 측면에서 문제를 고민하신다면, 번역을 생각하신다면 분명 부딛칠
> 문제입니다. 그것이 아니라면 상관없습니다.
>

표준의 "권위 있는" 번역은 아무나 할 수 있는 것이 아닙니다. 현재 ISO
에 우리나라를 대표하고 있는 기관인 기술표준원만이 가능합니다 - 실제
C89 의 경우 우리말 번역본이 나왔던 것으로 알고 있습니다. 그럼에도
불구하고 제가 해당 문맥에서 language lawyer 로서 엄격한 번역을
시도했다고 생각하시나요? 아래 제 답변을 님은 보신 기억이 없다는
뜻인가요?

제가 씀:
] 영어로 논의를 진행할 때 "program", "program constrcut" 는 종종
] 통용되어 사용되는 표현입니다.

제가 표준의 우리말 번역을 시도했다면 "영어로 논의를 진행할 때",
"종종 통용되어" 와 같은 표현을 사용하지 않았을 것입니다.

어쨌든 (아직도 중반부부터는 그 의미가 분명해졌음에도 이제서야 정리가
되는 님을 온전히 이해하긴 어렵지만) 애초에 님이 왜 "구조"라는 표현에
대해 의문을 표했는지는 이해했으며, 오해라는 것이 일방의 잘못이
아니기에 처음부터 보다 분명한 표현을 사용하지 못한 점에 대해
사과드립니다.

그리고 더불어 부탁드립니다만, 질문이든 주장이든 글 올리시기 전에
(비록 상당히 길긴 하지만) 전체 논의를 쭉 훑어보시기 바랍니다.
님이 앞으로 쓰실 글을 정리하는데에도 도움이 될 뿐더러, 종종 지금까지
남아있던 의문이나 오해에 대한 답을 얻을 수 있기도 합니다.

--
Jun, Woong (woong at icu.ac.kr)
Web: http://www.woong.org (서버 공사중)

> correct와 conforming이 전혀 관련없다고 말하는데 동의하지 않습니다.
> 아마 위에서 알겠다고 했을껍니다. 자꾸 핵심을 벗어났기 때문에 이제 다른 것들이
> 어느 정도 정리 됐기고 새로운 이해 바탕위해 다시 시도하는 것입니다.
>

그럼 이제부터 고쳐 아시기 바랍니다. 제가 많이 바쁜 관계로 아래
간단히(?) 설명 드립니다.

>
> correct program(이하 cr.p.)은 이미 말한대로 정의가 아니라 단순히 기술했다는 것을
> 알고 있습니다.
>

맞습니다. 엄밀한 정의가 아닙니다. 즉 우리가 흔히 사용하는 "correct
program" 이라는 표현을 표준화 위원회는 어떤 기준으로 생각하고 있는가
를 표준의 용어를 통해 보인 것이라 생각하시면 됩니다.

> 이 말은 곧 이미 정의된 conforming program(이하 cf.p.) 이나 strictly
> conforming program(이하 s.c.p.)에 어떤 식으로든 속해 있다는 뜻입니다. 이것이 cf.p., s.c.p.
> 개념 위에 세워졌지는 않지만 결국 한 형태로 자리 잡고 있기 때문에 4.Conformance에 기술하고 있다는
> 생각입니다.

엄밀히 따지고 들어가면 100% 맞는 이야긴 아니지만, 이렇게 이해해도 큰
무리는 없다는데 동의합니다.

> cr.p.는 unspecified behavior를 포함하고 있기 때문에 cf.p. 한 형태입니다. 그런데
> unspecified behavior이지만 4p5에 의해 output을 만들지 않으면 s.c.p.
> 이라고 할 수 있기에 어떤 cf.p.는 s.c.p.도 되는 것입니다. 그러므로,

논리적 포함 관계를 좀 더 면밀하게 따져 보시기 바랍니다.

conforming program:
- undefined, unspecified, i-d behavior 모두 포함 가능
- 단지 특정 구현체에서 받아들여주기만(accept) 하면 됨

strictly conforming program:
- undefined behavior 를 포함할 수 없음
- 프로그램의 출력이 unspecified, i-d behavior 에 의존 불가능
- 표준이 기술하는 기능 안에서 구현되어야 함
- 구현체가 받아들여준다는(accept) 보장 없음 (*)

correct program:
- undefined behavior 를 포함할 수 없음
- 구현체가 받아들여준다는(accept) 보장 없음 (*)

표준을 엄밀하게 해석하면 s.c. program 이든 correct program 이든 표준
을 준수하는 구현체가 받아들여줘야(accept) 한다는 요구 사항은
없습니다. 하지만 이는 어디까지나 다소 정치적, 이론적인 문제이기
때문에 현실적으로 상식적인 구현체는 s.c. program, correct program 을
모두 수용할 수 있다고 가정하겠습니다. 따라서 위에서 (*) 로 표시된
항목은 잠시 무시합니다.

자, 이제 각 제약에 따라 논리적으로 따져 보겠습니다.

"s.c. program 이면 correct program 입니다" 는 참
(역) "correct program 이면 s.c. program 입니다" 는 거짓
(대우) "correct program 이 아니면 s.c. program 이 아닙니다" 는 참

"correct program 이면 conforming program 입니다" 는 참
(역) "conforming program 이면 correct program 입니다" 는 거
(대우) "conforming program 이 아니면 correct program 이 아닙니다" 는 참

(명제와 연결해) "s.c. program 이면 conforming program 입니다" 는 참
(역) "conforming program 이면 s.c. program 입니다" 는 거짓
(대우) "conforming program 이 아니면 s.c. program 이 아닙니다" 는 참

* 다시 한번 말씀드리지만, s.c. program 과 correct program 을 모든
구현체가 수용 가능하다는 가정 아래에서의 논리입니다!!!

이제 님이 말씀하신 명제들을 나열해 보겠습니다.

- cr.p.는 unspecified behavior를 포함하고 있기 때문에 cf.p. 한 형태입니다.

이를 "correct program 은 conforming program 입니다" 로 놓으면 맞는
이야기입니다.

- 그런데 unspecified behavior이지만 4p5에 의해 output을 만들지 않으면 s.c.p.
이라고 할 수 있기에 어떤 cf.p.는 s.c.p.도 되는 것입니다.

위에서 나열한 명제에 의해 s.c. program 은 conforming program 의
subset 이 됩니다. 따라서 "어떤" conforming program 은 s.c. program 이
될 수 있습니다. 따라서 맞습니다.

> > 참고로, 프로그램의 출력이 unspecified behavior 에 의존하는 프로그램은
> > correct 프로그램이지만 strictly conforming program 이 아닙니다.
>
> 이것을 틀린 말입니다. 그리고,
>

잘 정리해 놓으시고 왜 틀린 결론을... 제가 글을 천천히 잘 읽어봐달라고
그렇게 부탁을 드렸건만...

출력(output)이 unspecified behavior 에 의존하는 프로그램은 정의에
의해 s.c. program 이 아닙니다. 위에서는 출력(output)을 하지 않는
경우를 말씀해 놓으시고는 왜 밑에서는 출력(output)을 하는 경우임에도
s.c. program 이 될 수 있다고 생각하십니까? --; 다시 확인해 보시기
바랍니다.

> > correct program 의 subset 이 strictly conforming program 이고,
> > conforming program 은 이 둘과 아무런 관련이 없습니다.
>
> 이것 역시 틀리고, 아무런 관련이 없다고 할 수 없는 것입니다.
> 틀린 것이 있다면 지적바랍니다.
>

넵, 님 말씀대로 위에서 제가 정리해 놓은 명제와 같은 관계를 가지고
있습니다. 하지만, 그 이전에 제가 가정한 것([*] 항목 무시)을 보시기
바랍니다. conforming program 을 결정짓는 중요한 요소는 구현체가
받아들일 수 있느냐, 없느냐 입니다. 받아들인 다는 것은 번역과 실행을
허용한다는 것입니다.

하지만, 표준은 s.c. program 이라고 해서, 혹은 correct program 이라고
해서 구현체가 번역과 실행을 해주어야 한다고 요구하지 않습니다.
correct program 을 기술하면서 특정 subclause 에 따라 행동해야 한다고
요구한 부분은 일단 번역과 실행이 성공한 이후에는 그래야 한다는
뜻입니다. 이론적으로 구현체는 특정 조건을 만족하는 s.c. program
하나만을 올바르게 번역, 실행해 주면 됩니다 - 그 외에는 번역, 실행해
줄 필요가 없습니다. (또, 버럭하시면서 틀린 반박을 하실까봐 아래 표준
인용해 드립니다. 이와 관련된 내용은 제가 csc 에서 길게 토론한 글이
있습니다. 궁금하신 내용은 직접 검색해 보시기 바랍니다)

이는 매우 정치적으로 결정된 비현실적인 사항이지만, 실제 시장의 힘에
의해 컴파일러 회사들은 품질 좋은 컴파일러를 만들려고 할 것이기 때문에
현실적인 문제를 일으키지는 않습니다.

따라서 제가 conforming program 이 무관하다고 드린 말씀은 그와 같은
해석을 적용할 경우 관계가 없다는 뜻입니다 - 설사 억지로 관계를 찾는다
해도 s.c. program 딱 하나와만 교집합을 만들 수 있다는 뜻입니다.
더구나, conforming program 의 의도 자체가 어떤 conformance level 을
결정짓기 위한 것이 아니라 (이전에 보여드린 %1$ 에 대한 답에서처럼)
사람들을 달래기 위한 정치적 목적이라는 것입니다.

한 가지 궁금한 것은 제가 이전에 인용, 언급해 드린 csc 논의 등은
확인해 보셨나요? 해당 내용을 검색해 공부하셨다면 저보다 더 영향력
있는 분들의 답변을 확인하실 수 있습니다. Directives 파실 시간에 그런
논의 몇 개 더 읽는 것이 훨씬 더 도움이 됩니다.

> > 제가 정의를 인용해 clause 제목이 내용 해석에 절대적 영향
> > 을 줄 수 있는 normative element 가 아님을 보이자, 금새 언제 그런 말
> > 했었냐며 발뺌을 하시는군요. 님 말씀대로 subclause 와는 달리 clause 의
> > 경우 반드시 제목을 가져야 한다는 것을 놓고 이야기하는 것이었다면 벌써
> > 한참 전에 나온 이야기입니다.
> >
> > http://kldp.org/node/81963#comment-390454
>
> 제가 이해한 것을 읽어 보고 다시 생각해 보시기 바랍니다.
> normative를 말할 때 확실히 normative general elements(n.g.e.), normative
> technical elements(n.t.e.)와 좀 더 작은 개념인 normative elements(n.e.) 및
> content를 구분하는 것을 처음에 분명 놓쳤습니다. n.e.에는 님이 말하신 Scope(clause 1),
> Normative References(clause 2)와 Title(n.g.e.에 속하는)와 Terms and Definitions,
> 각 clause 3부터 끌 clause까지, Normative Annex 등등(n.t.e.에 속하는) 있습니다.
> 그리고 n.e.에는 선택이거나 필수인, 최종 레벨의 normative이거나 informative인 허용된
> content가 있습니다.
> Normative References를 예로 들면 허용된 content가 Reference와 footnote가 있는데
> Reference는 필수 이고 informative인 footnote만 허용돼 있습니다.
> 근데 Normative References를 필수라고 말하셨지만 Directives 6.2.2에의하면 옵션입니다.
> 그리고 이미 말하셨듯이 clause들도 옵션입니다. 쓰면 normative인데 생략할 수도 있다는 것입
> 니다. 그래서 clause를 쓰면 structure 형식에 의해 아시다시피 제목을 써야하고 subclause
> 에서는 안 써도 되는 것입니다. clause에 허용된 컨텐트 Text/Figures/Tables/Notes/
> Footnotes 증에 Notes, Footnotes는 infomative입니다.
> 이제 이미 언급한 테이블을 보면 이해가 더 잘 될 것입니다. 틀린 것이 있다면 지적바랍니다.
>

ISO 표준 drafting 을 준비 중이신지요? ;-)

님이 이런 내용을 잘못 이해하고 있다고 드린 말씀이 아닙니다.

길게 적으셨지만 clause/subclause 제목과 관련된 결론은 짧게 적으면,
"clause 는 제목을 적어야 하고, subclause 에서는 안 적어도 된다"
입니다.

혹은 그 외에 clause/subclause 제목과 관련해 제가 주의깊게 봐야 하는
결론이 있나요?

> > 물론 이름을 지을 때 일반론에서 4.3 Homogeneity 같은 것도 생각해야 하고 terms and difinitions 에서는
> > nomative 로 Annex D에서 얘기 하고 있습니다.
> >
>
> 혼자 공부한 내용은 집에 있는 개인 노트에 정리하시는 것이 좋겠습니다.
> clause 제목을 지을 때 제한이 전혀 없는 것이 아니기에 언급한 것입니다.
>

--; Homogeneity 의 내용은 제목 뿐 아니라 표준 문서 전반에 걸쳐
적용되어야 하는 일반적 내용입니다. 즉, 지극히 상식적인 내용으로 이미
님과 저 사이에 암시적으로 동의가 이루어진 부분이므로, 지금까지 중점이
되었던 문제와 직접적 관련이 있는 부분으로 생각하지 않는다는 뜻입니다.

>
> 네 감사합니다. 애초의 제기된 문제에 준한(but not strictly conforming)
> 사과라고 생각합니다.

남의 말을 왜곡하는데 일가견이 있으신 것 같습니다. "구조"라는 표현을
불명확하게 사용한 것에 대한 사과입니다.

> 저 역시 기술적인 문맥과 다른 의도로 해석될 수 있는 표현이 있었다면 사과드립니다.
> 정말이지 전 아무 감정없습니다. 앙금이 남아 있다면 또 무지한 저를 질책하시기
> 바랍니다.
>

목적이 무엇인지 모르겠으나, 뭔가를 열심히 탐구하고 계시는 것
좋습니다. 또한 님이 설사 무지하시다 하더라도 무지한 것은 (제가 님의
선생님이 아니고서야) 질책의 대상이 될 수 없습니다. 중요한 것은 님이
그와 같은 무지의 상태에서 나오는 방법과 태도에 있습니다. 님이
지금까지 고민하셨던 것, 혹시나 앞으로 고민하실 것들 모두 저는 5-10년
전에 미리 고민하고 일부는 긴 시간에 걸쳐 결론을 내린 것들입니다.

제가 님의 입장이라면 무턱대고 잘못된 주장을 나열해 놓고 지적되길
기다리고 있지는 않을 것입니다. 이는 매우 위험한 태도입니다. 만약,
저나 혹은 해당 내용을 올바르게 알고 있는 다른 분이 지적을 해주지
않으면 님은 그것이 올바른 사실이라 가정하실테고, 더구나 님 글을 읽는
다른 분들 중에서도 님의 주장을 사실로 받아들이는 분들이 나올 수
있습니다. 이 얼마나 무책임한 행동입니까?

하지만, 반대로 님이 이해한 바를 확인하기 위해 질문의 형태를 취한다면,
님 스스로는 물론 다른 분들의 오해를 낳는 일도 없을 것입니다 - 최소한
물음표가 박힌 문장을 읽고 참이라 가정하는 사람이 더 적지 않겠습니까?

제가 님께 원망스러운 부분은 바로 그런 방식의 부분입니다. 이 점을 좀
더 고려해 보시기 바랍니다.

KLDP 에 글 올리는 것 힘듭니다. 앞으로 제게 "질문" 있으시면 질문하실
내용만 간추려 메일로 부탁드립니다.

--
Jun, Woong (woong at icu.ac.kr)
Web: http://www.woong.org (서버 공사중)