12
제목은 그것을 요약합니다. 아마도 소스 코드 생성 파서 생성기 (본질적으로 프로그램에 문법을 하드 코딩하는)로 수행 할 수있는 모든 작업은 구성 가능한 파서를 사용하여 수행 할 수 있습니다 (문법을 유지할 수있는 구문 분석기 데이터 구조로 소프트 코딩 된 -parsed).단지 구성 가능한 파서 대신 파서 생성기를 사용하는 이유는 무엇입니까?
하드 코드 된 코드 생성 구문 분석기는 간접 참조 수준이 한 단계 낮 으면 성능 보너스가되지만 컴파일 및 실행 (또는 동적 언어로는 exec())이 복잡하고 전반적인 clunkiness 코드 생성은 상당히 큰 단점이 있습니다. 파서의 코드 생성과 관련하여 내가 알지 못하는 다른 이점이 있습니까?
내가 사용한 코드 생성의 대부분은 언어 (예 : 웹 프레임 워크, AOP, 데이터베이스와의 인터페이스)의 메타 프로그래밍 기능의 한계를 해결하는 것이지만, 전체 lex-parse 작업은 매우 간단하고 코드 생성에서 얻을 수있는 추가적인 메타 프로그래밍 역 동성을 필요로하지 않습니다. 뭐라 구요? 성능상의 이점이 큽니다?
@BartKiers : 파서 - 제네레이터에 의해 생성 된 파서가 제너레이터 자체보다 더 복잡하거나 더 일반적인 것은 아니지만? 파서 생성기가 뭔가를 구문 분석 할만큼 복잡한 코드를 생성 할 수 있다면 왜 코드를 생성하고 컴파일하고 메모리에서 코드를 실행하여 즉시 구문 분석 할 수 없습니까? 그냥 파싱하는 것과 똑같은가? (아마도 파서 생성기가 있기 때문에 그 이유가 모르겠다.) –
죄송합니다, 이해가되지 않습니다. 더 이상 설명하려고하지 마십시오. 나는이 질문이 SO에 잘 맞지 않는다고 생각합니다. 따라서 나는 그 질문을 따르지 않을 것입니다. –
약간의 노력으로 lex와 yacc (flex와 bison)에 의해 생성 된 테이블을 얻고 비표준 스켈레톤에서 사용할 수 있습니다. 가장 큰 문제점은 사용자 공급 조치를 연결하는 것입니다. – wildplasser