program tip

컴파일러가 아닌 C ++ 인터프리터를 사용 했습니까?

radiobox 2020. 11. 12. 08:06
반응형

컴파일러가 아닌 C ++ 인터프리터를 사용 했습니까?


누군가 UnderC, Cint, Cling, Ch 또는 다른 C ++ 인터프리터를 사용하고 경험을 공유 할 수 있는지 궁금합니다.


참고 : 다음 내용은 CINT에 따라 다르지만 아마도 가장 널리 사용되는 C ++ 인터프리터 라는 점을 감안할 때 모두 유효 할 수 있습니다.

CINT를 광범위하게 사용하는 입자 물리학 대학원생으로서주의해야합니다. "작동"하는 동안 단계적으로 제거되는 과정에 있으며 입자 물리학에서 1 년 이상을 보낸 사람들은 일반적으로 몇 가지 이유로이를 피하는 방법을 배웁니다.

  1. C 인터프리터라는 뿌리 때문에 C ++의 가장 중요한 구성 요소 중 일부를 해석하지 못합니다. 예를 들어 템플릿이 항상 작동하는 것은 아니므로 C ++를 유연하고 유용하게 만드는 것을 사용하지 않는 것이 좋습니다.

  2. 최소로 최적화 된 C ++보다 느립니다 (적어도 5 배).

  3. 디버깅 메시지는 g ++에서 생성 된 것보다 훨씬 더 비밀 스럽습니다.

  4. 범위 지정은 컴파일 된 C ++와 일치하지 않습니다. 형식의 코드를 보는 것은 매우 일반적입니다.

    if (energy > 30) { 
        float correction = 2.4;
    }
    else {
        float correction = 6.3;
    }
    
    somevalue += correction; 
    

    작동하는 C ++ 컴파일러는 correcton범위를 벗어났다고 불평하지만 CINT는이를 허용합니다. 그 결과 CINT 코드는 실제로 C ++가 아니라 그와 유사한 것입니다.

요컨대 CINT는 C ++의 장점이 없으며 모든 단점과 일부가 있습니다.

CINT가 여전히 사용된다는 사실은 ROOT 프레임 워크에 포함되어 있기 때문에 역사적 사고에 가깝습니다. 그것이 작성되었을 때 (20 년 전), 인터랙티브 플로팅 / 피팅을위한 통역 언어가 정말로 필요했습니다. 이제 그 역할을 수행하는 많은 패키지가 있으며 많은 패키지에는 수백 명의 활성 개발자가 있습니다.

이들 중 어느 것도 C ++로 작성되지 않았습니다. 왜? 간단히 말해서 C ++는 해석 할 수 없습니다. 예를 들어 정적 타이핑은 컴파일하는 동안 최적화에서 큰 이득을 얻지 만 컴퓨터가 런타임에만 코드를 볼 수 있도록 허용되는 경우 대부분 코드를 복잡하게 만들고 과도하게 제한합니다. 통역 언어를 사용하고 Python 또는 Ruby를 배울 수있는 사치가 있다면 C ++를 이미 알고 있더라도 CINT에 대한 걸림돌을 푸는 데 걸리는 시간보다 배우는 데 걸리는 시간이 줄어들 것입니다.

내 경험상 ROOT (CINT를 실행하기 위해 설치해야하는 패키지)로 작업하는 이전 연구자들은 CINT를 피하기 위해 ROOT 라이브러리를 일반 C ++ 실행 파일로 컴파일합니다. 젊은 세대는이 리드를 따르거나 스크립트에 Python을 사용합니다.

덧붙여서 ROOT (및 CINT)는 상당히 현대적인 컴퓨터에서 컴파일하는 데 약 30 분 정도 걸리며 새 버전의 gcc에서는 때때로 실패합니다. 수년 전에 중요한 목적을 달성 한 패키지 였지만 지금은 분명히 나이를 보여주고 있습니다. 소스 코드를 살펴보면 수백 개의 더 이상 사용되지 않는 c 스타일 캐스트, 유형 안전성에 큰 허점, 전역 변수의 과도한 사용을 확인할 수 있습니다.

C ++를 작성하려면 작성하려는 의도대로 C ++를 작성하십시오. C ++ 인터프리터가 반드시 있어야한다면 CINT가 좋은 선택 일 것입니다.


이입니다 집착 CERN의 프로젝트 를 기반으로 C ++ 통역을 연타 - 그것의 새로운 접근 방식 에서 20 년의 경험을 기반으로 ROOT의 CINT 하고 매우 안정적이고 CERN들에 의해 권장합니다.

다음은 멋진 Google 토크입니다. clang / LLVM 기반 C ++ 인터프리터 인 cling을 소개 합니다.


cint는 입자 물리학 분석 패키지 ROOT 의 명령 프로세서입니다 . 나는 그것을 정기적으로 사용하고 그것은 나를 위해 매우 잘 작동합니다.

상당히 완전하고 컴파일 된 코드로 잘 작동합니다 (인터프리터에서 사용하기 위해 컴파일 된 모듈을로드 할 수 있습니다 ...)

후기 편집 :: 해당 질문에 대한 포스터가 여기에 게시하고 싶지 않은 것 같았 기 때문에 나중에 중복 된 내용에서 복사했습니다 : igcc . 개인적으로 시도한 적은 없지만 웹 페이지는 유망 해 보입니다.


나는 (약 1 년 전) Ch함께 놀았는데 꽤 괜찮았다.


오래 전에 저는 CodeCenter라는 C ++ 인터프리터를 사용했습니다. 비트 필드 나 멋진 포인터 맹 글링 같은 것을 처리 할 수는 없지만 꽤 좋았습니다. 두 가지 멋진 점은 변수가 변경 될 때를 볼 수 있고 디버깅하는 동안 즉시 C / C ++ 코드를 평가할 수 있다는 것입니다. 요즘에는 GDB와 같은 디버거가 기본적으로 똑같이 좋다고 생각합니다.


또한 오래 전에 Instant C라는 제품을 사용했지만 더 발전했는지는 모르겠습니다.


나는 ch a를 사용하여 내가 담당하는 블랙 박스 테스트 DLL에 사용할 수 있는지 확인했습니다. 불행히도 DLL에서 함수를로드하고 실행하는 방법을 알 수 없었습니다. 다시 말하지만, 나는 그렇게 동기를 부여받지 않았고 방법이있을 수 있습니다.


GCC를 사용하여 코드를 공유 라이브러리로 반복적으로 컴파일 한 다음 결과 객체를로드하여 작동하는 c-repl 이라는 프로그램이 있습니다. Ubuntu의 저장소에 있는 버전 이 Ruby로 작성되고 (물론 GCC는 포함되지 않음) 최신 git 이 Haskell 에 있다는 점을 고려 하면 빠르게 진화하는 것 같습니다 . :)

참고 URL : https://stackoverflow.com/questions/69539/have-you-used-any-of-the-c-interpreters-not-compilers

반응형