함수와 같은 매크로에 전 처리기 지시문을 추가하는 것은 잘못 되었습니까?

Question

내 질문은 this one 또는 this one과 비슷하지만 실제로는 동일하지 않으며 두 번째 대답은 받아 들여지지 않았 음을 알고, 전처리 지시문을 추가하는 것이 올바른지 묻기로했습니다. 함수와 비슷한 매크로가 호출됩니까? 다른 매크로가 정의되어있는 경우 어딘가에 특정 차이를 호출 코드에서

#define FUNC_MACRO(a, b) // do something with the variables 

과 : I가 시험

// ... 
FUNC_MACRO(aVal 
#ifdef ANOTHER_MACRO 
       + offset 
#endif // ANOTHER_MACRO 
      , bVal); 
// ... 

내 경우

나는 함수 같은 매크로를 내 컴퓨터 (리눅스, gcc 4.8)와 괜찮 았던가 (전처리 지시어의 유무에 상관없이 ANOTHER_MACRO가 정의 된 경우와없는 경우), 그렇게하는 것이 안전 할까?

첫 번째 비슷한 질문의 답에서 16.3/9 단락을 읽었지 만 내 경우에도 마찬가지입니까?

Answer 1

C 언어 잎 에서이 같은 정의되지 않은 동작 6.10.3 매크로 교체, ¶11 :

달리 전처리 지침 역할을 할 인수 목록에서 전처리 토큰의 시퀀스가있는 경우

, 동작은 정의되지 않습니다.

실제로 그렇게하는 것은 잘못되었습니다.

GCC와 다른 인기있는 컴파일러는이를 포착하지 않기 때문에 많은 언어 사용자가이를 인식하지 못할 수 있습니다. 내 코드 중 일부가 PCC에서 컴파일하지 못했을 때 (그리고 신속하게 내 코드에서 버그 수정)이 문제가 발생했습니다.

업데이트 : PJTraill은 매크로 확장에서 전 처리기 지시문을 사용하는 것이 "오해의 소지가 있거나 의미가없는"경우에 대해 주석에서 질문했습니다.

foo(a, b, 
#ifdef BAR 
     c); 
#else 
     d); 
#endif 

나는 언어가 매크로 확장 내부 균형 처리기 조건문에 문제가 없는지를 지정하는 것이 타당했을 것이다 있는지 모르겠지만, 난 당신이 문제에 실행 거라고 생각 : 여기에 명백한 일이다 그것들이 처리되어야하는 순서로 모호함이있다.

Answer 2

대신 다음 중 하나를 수행 하시겠습니까?

#ifdef ANOTHER_MACRO 
FUNC_MACRO(aVal + offset, bVal); 
#else 
FUNC_MACRO(aVal, bVal); 
#endif 

편집 : 코멘트에 의해 제기 주소 우려; 나는 OP의 방법이 이라면 구체적으로 (나는 다른 답변이 그것을 커버한다고 생각한다)이 맞는지 모른다. 그러나 간결함과 명확성은 C로 코딩 할 때 매우 중요하게 여겨지는 두 가지 측면입니다.

이렇게 나는 OP와 같은 상황을 약간 재검토하여 더 나은 방법을 찾고 싶습니다. 위에 제안했다. 나는 OP가 triviallised 예제를 사용했을지도 모른다고 생각하지만 일반적으로 대부분의 C 상황에서 뭔가가 지나치게 복잡 해지거나 무언가를하려고 시도 할 때 언어가 허용해야하는 것처럼 보이지 않는다면 필요한 것을 성취 할 수있는 더 좋은 방법이 있다는 것을 알게됩니다. .