현대 프로그래밍 언어에 매크로가 포함되지 않은 이유는 무엇입니까?

C / C ++에서 매우 안전하지 않게 구현 된 것을 알고 있습니다. 더 안전한 방식으로 구현할 수 없습니까? 매크로의 단점은 그들이 제공하는 거대한 힘을 능가하기에 충분히 나쁩니 까?

나는 주된 이유는 매크로가 어휘 적이라고 생각합니다 . 몇 가지 결과가 있습니다.

• 컴파일러는 매크로가 의미 론적으로 닫혀 있는지 확인하는 방법이 없습니다. 즉, 매크로가 함수처럼 "의미있는 단위"를 나타냅니다. (고려 #define TWO 1+1하는 것은 무엇 TWO*TWO입니까? 3.)

• 매크로는 함수처럼 입력되지 않습니다. 컴파일러는 매개 변수 및 리턴 유형이 의미가 있는지 확인할 수 없습니다. 매크로를 사용하는 확장 식만 확인할 수 있습니다.

• 코드가 컴파일되지 않으면 컴파일러는 오류가 매크로 자체에 있는지 또는 매크로가 사용되는 장소에 있는지 알 수있는 방법이 없습니다. 컴파일러는 시간의 절반을 잘못된 장소에보고하거나 둘 중 하나라도 괜찮더라도보고해야합니다. (고려 #define min(x,y) (((x)<(y))?(x):(y)): 유형 x과 y일치하지 않거나 구현하지 않으면 컴파일러는 어떻게해야 operator<합니까?)

• 자동화 된 도구는 의미 적으로 유용한 방식으로 작업 할 수 없습니다. 특히 함수처럼 작동하지만 표현식으로 확장되는 매크로에는 IntelliSense와 같은 것을 사용할 수 없습니다. (다시 min예)

• 매크로의 부작용은 함수와 같이 명시 적이 지 않으므로 프로그래머에게 혼란을 줄 수 있습니다. ( min예를 다시 고려하십시오. 함수 호출에서에 대한 표현식 x은 한 번만 평가 된다는 것을 알고 있지만 여기서는 매크로를 보지 않으면 알 수 없습니다.)

내가 말했듯이, 이것들은 모두 매크로가 어휘 적이라는 사실의 결과입니다. 더 적절한 것으로 바꾸려고하면 함수와 상수가 생깁니다.

그러나 C / C ++보다 매크로 를 더 잘 설계하고 구현할 수 있습니다.

매크로의 문제점은 실제로 코드를 다른 것으로 재 작성 하는 언어 구문 확장 메커니즘이라는 점입니다.

• C / C ++의 경우 기본 위생 검사가 없습니다. 조심하면 문제가 없습니다. 실수를하거나 매크로를 과도하게 사용하면 큰 문제가 생길 수 있습니다.

  여기에 (C / C ++ 스타일) 매크로로 수행 할 수있는 많은 간단한 작업을 다른 언어로 다른 방법으로 수행 할 수 있습니다.

• 다양한 리스프 (Lisp) 방언과 같은 다른 언어에서는 매크로가 핵심 언어 구문과 더 잘 통합되지만 매크로 "누출"의 선언에는 여전히 문제가 발생할 수 있습니다. 이것은 위생적인 매크로에 의해 해결됩니다 .

간략한 역사적 맥락

매크로 (매크로 명령어의 줄임말)는 어셈블리 언어의 맥락에서 처음 등장했습니다. Wikipedia 에 따르면 , 1950 년대에 일부 IBM 어셈블러에서 매크로를 사용할 수있었습니다.

원래 LISP에는 매크로가 없었지만 1960 년대 중반에 처음으로 MacLisp에 도입되었습니다. https://stackoverflow.com/questions/3065606/when-did-the-idea-of-macros-user-defined-code -변환이 나타납니다 . http://www.csee.umbc.edu/courses/331/resources/papers/Evolution-of-Lisp.pdf . 그 전에 "fexprs"는 매크로와 유사한 기능을 제공했습니다.

초기 C 버전에는 매크로가 없었습니다 ( http://cm.bell-labs.com/cm/cs/who/dmr/chist.html ). 이들은 전처리기를 통해 1972-73 년경에 추가되었습니다. 그 전에 C는 #include및 만 지원했습니다 #define.

M4 매크로 전처리 기는 1977 년경에 시작되었습니다.

보다 최근의 언어는 작동 모델이 텍스트가 아닌 구문 적 인 매크로를 구현합니다.

따라서 누군가 "매크로"라는 용어의 특정 정의의 우선 순위 에 대해 이야기 할 때 그 의미가 시간이 지남에 따라 진화했음을 주목하는 것이 중요합니다.

Scott이 지적한 것처럼 매크로를 사용하면 논리를 숨길 수 있습니다. 물론 함수, 클래스, 라이브러리 및 기타 여러 일반적인 장치도 마찬가지입니다.

그러나 강력한 매크로 시스템은 한층 더 발전하여 일반적으로 사용되지 않는 구문과 구조를 설계하고 활용할 수 있습니다. 도메인 언어, 코드 생성기 등 단일 언어 환경에서 편안하게 사용할 수있는 훌륭한 도구입니다.

그러나 악용 될 수 있습니다. 코드를 읽기, 이해 및 디버깅하기 어렵게 만들고, 새로운 프로그래머가 코드베이스에 익숙해지는 데 필요한 시간을 늘리고, 비용과 실수로 인해 지연 될 수 있습니다.

따라서 프로그래밍 을 단순화 하려는 언어 (예 : Java 또는 Python)의 경우 이러한 시스템이 끔찍합니다.

매크로는 일부 상황에서 매우 안전하게 구현 될 수 있습니다. 예를 들어 Lisp에서 매크로는 변환 된 코드를 데이터 구조 (s- 표현식)로 반환하는 함수일뿐입니다. 물론 Lisp는 호모 닉 이라는 사실과 "코드는 데이터" 라는 사실에서 큰 이점을 얻습니다 .

매크로가 쉬운 방법의 예는 예외의 경우에 사용할 기본값을 지정하는이 Clojure 예입니다.

(defmacro on-error [default-value code]
  `(try ~code (catch Exception ~'e ~default-value)))

(on-error 0 (+ nil nil))               ;; would normally throw NullPointerException
=> 0                                   ;l; but we get the default value

그러나 Lisps에서도 일반적인 조언은 "필요하지 않으면 매크로를 사용하지 마십시오"입니다.

호모 닉 언어를 사용하지 않으면 매크로가 훨씬 까다로워지고 다양한 옵션에 모두 함정이 있습니다.

• 텍스트 기반 매크로 ( 예 : C 프리 프로세서)는 구현이 간단하지만 구문상의 문제를 포함하여 텍스트 형식으로 올바른 소스 구문을 생성해야하기 때문에 올바르게 사용하기가 매우 까다 롭습니다.
• 매크로 기반 DSLS- 예를 들어 C ++ 템플릿 시스템. 복잡하고 자체적으로 까다로운 구문을 생성 할 수 있으며, 언어 구문 및 시맨틱에 새로운 복잡성을 도입하기 때문에 컴파일러 및 도구 작성자가 올바르게 처리하기가 매우 복잡 할 수 있습니다.
• AST / 바이트 코드 조작 API ( 예 : Java 리플렉션 / 바이트 코드 생성)는 이론적으로 매우 유연하지만 매우 장황 할 수 있습니다. 매우 간단한 작업을 수행하려면 많은 코드가 필요할 수 있습니다. 3 줄 함수와 동등한 기능을 생성하는 데 10 줄의 코드가 필요한 경우 메타 프로그래밍 노력으로 많은 것을 얻지 못했습니다 ...

더욱이, 매크로가 할 수있는 모든 것은 궁극적으로 튜링 완전한 언어로 다른 방식으로 달성 될 수 있습니다 (이것이 많은 상용구를 작성하는 것을 의미하더라도). 이러한 까다로운 결과로 많은 언어에서 매크로가 실제로 구현하려는 모든 노력의 가치가 없다고 결정하는 것은 놀라운 일이 아닙니다.

질문에 대답하려면 주로 어떤 매크로가 사용되는지 (경고 : 뇌 컴파일 코드)에 대해 생각해보십시오.

• 기호 상수를 정의하는 데 사용되는 매크로 #define X 100

이것은 쉽게 다음으로 대체 될 수 있습니다. const int X = 100;

• 인라인 유형에 관계없이 함수를 정의하는 데 사용되는 매크로 #define max(X,Y) (X>Y?X:Y)

함수 오버로딩을 지원하는 모든 언어에서 올바른 형식의 오버로드 된 함수를 사용하거나 제네릭을 지원하는 언어에서 제네릭 함수를 사용하여 훨씬 더 안전한 형식으로 에뮬레이션 할 수 있습니다. 매크로는 컴파일 할 수있는 포인터 나 문자열을 포함하여 어떤 것도 비교하려고 시도 하지만, 원하는 것은 아닙니다. 반면에 매크로를 안전한 유형으로 만들면 오버로드 된 기능에 비해 이점이나 편의성이 제공되지 않습니다.

• 자주 사용하는 요소에 대한 바로 가기를 지정하는 데 사용되는 매크로입니다. #define p printf

이것은 p()같은 일 을하는 기능으로 쉽게 대체됩니다 . 이것은 C ( va_arg()함수 패밀리 를 사용해야 함 )와 관련이 있지만 가변 수의 함수 인수를 지원하는 다른 많은 언어에서는 훨씬 간단합니다.

특수 매크로 언어가 아닌 언어 내 에서 이러한 기능을 지원하는 것이 더 간단하고 오류가 적으며 코드를 읽는 다른 사람들과 혼동되지 않습니다. 실제로 다른 방법으로는 쉽게 복제 할 수없는 매크로 의 단일 사용 사례를 생각할 수 없습니다. 만 그들이 같은 조건부 컴파일 구조에 연결하는 경우 매크로가 진정으로 유용한 장소입니다 #if(등).

그 시점에서, 나는 대중 언어의 조건부 컴파일에 대한 비 전처리 프로세서 솔루션이 매우 번거 롭다고 믿기 때문에 당신과 논쟁하지 않을 것입니다 (Java의 바이트 코드 주입과 같은). 그러나 D와 같은 언어는 전처리 기가 필요없고 전 처리기 조건을 사용하는 것보다 더 번거롭지 않고 오류가 발생하기 쉬운 솔루션을 제시했습니다.

매크로에서 가장 큰 문제는 매크로를 많이 사용하면 찾기 쉽고 유지하기 어려운 매크로에서 논리를 숨길 수 있기 때문에 코드를 읽고 유지하기가 매우 어렵다는 것입니다. ).

C / C ++의 MACRO는 매우 제한적이며 오류가 발생하기 쉬우 며 실제로는 유용하지 않다는 점을 염두에두고 시작하지 마십시오.

LISP 또는 z / OS 어셈블러 언어로 구현 된 MACRO는 신뢰할 수 있고 매우 유용 할 수 있습니다.

그러나 C의 제한된 기능을 남용했기 때문에 그들은 나쁜 평판을 얻었습니다. 따라서 아무도 더 이상 매크로를 구현하지 않습니다. 대신 사용되는 간단한 작업 매크로 중 일부를 수행하는 템플릿과 Java의 주석과 같은 작업을 수행하여 더 복잡한 작업을 수행합니다.