컴파일러

Search BackLinks only
Display context of search results
Case-sensitive searching

• MoreEffectiveC++/Miscellany . . . . 29 matches
       당신의 코드를 변화가 필요할때, 그 효과를 지역화(지역화:localized) 시키도록 디자인 해라. 가능한한 캡슐화 하여라:구체적인 구현은 private 하라. 광범위하게 적용해야 할곳이 있다면 이름없는(unamed) namespace나, file-static객체 나 함수(Item 31참고)를 사용하라. 가상 기초 클래스가 주도하는 디자인은 피하라. 왜냐하면 그러한 클래스는 그들로 부터 유도된 모든 클래스가 초기화 해야만 한다. - 그들이 직접적으로 유도되지 않은 경우도(Item 4참고) if-than-else을 개단식으로 사용한 RTTI 기반의 디자인을 피하라.(Item 31참고) 항상 클래스의 계층은 변화한다. 각 코드들은 업데이트 되어야만 한다. 그리고 만약 하나를 읽어 버린다면, 당신의 컴파일러로 부터 아무런 warning를 받을수 없을 것이다.
       물론, 필요하다면 현재 감안하는 생각으로 접근한다. 당신이 개발중인 소프트웨어는 현재의 컴파일러에서 동작해야만 한다.;당신은 최신의 언어가 해당 기능을 구현할때까지 기다리지 못한다. 당신의 현재 가지고 있는 언어에서 동작해야 하고. 그래서 당신의 클라이언트에서 사용 가능해야 한다.;당신의 고객에게 그들의 시스템을 업그레이드 하거나, 수행 환경을(operating environment) 바꾸게 하지는 못할것이다. 그건은 '''지금''' 수행함을 보증해야 한다.;좀더 작은, 좀더 빠른 프로그램에 대한 약속은 라이프 사이클을 줄이고, 고객에게 기대감을 부풀릴 것이다. 그리고 당신이 만드는 프로그램은 '''곧''' 작동해야만 한다. 이는 종종 "최신의 과거"를 만들어 버린다. 이는 중요한 속박이다. 당신은 이를 무시할수 없다.
       솔직히, dynamic_cast를 사용해서 실행 시간에 검사하는건 좀 짜증난다. 한가지, 몇몇 컴파일러는 아직 dynamic_cast에 대한 지원이 부족해서, 이를 사용하면, 이론적으로는 이식성이 보장되지만 실제로는 그렇지 않다. 더 중요하게 Lizard와 Chicken의 클라이언트들은 bad_cast 예외에 대한 준비와, 할당을 수행할때의 각 코딩시에 민감하게 처리하지 못한다. 내 경험에 비추어 볼때 많은 프로그래머들이 그런 방법을 취하지 않고 있다. 만약 그들이 하지 않는다면, 할당이 일어나는 수많은 곳에서 정확하지 않은 처리상태로, 명료성을 보장 받을수 없다.
       이 디자인은 당신이 필요한 모든것을 제공한다. 동종의 할당에 관해서 ''동물'', ''도마뱀'', ''닭''의 할당 연산을 허용한다.;부분적인 할당과 타종간의 할당을 금지한다는 것;그리고 유도된 클래스의 할당은 아마 기본 클레스 내의 할당 연산자가 맡을 것이다. 게다가 Animal, Lizard, Chicken클래스의 역할이 기록된 코드들을 수정을 필요로 하지 않는다. 왜냐하면, 이들 클래스는 소계된 AbstractAnimal 클래스로 기존의 역할들을 대신 받을수 있다. 물론, 그러한 코드들은 재 컴파일이 되어야 한다. 그렇지만 컴파일러가 할당의 명시성을 보장해 주어서 보장되는 보안성에 비하여 작은 비용이다.
       많은 면에서, C++와 C에서 컴포넌트를 만들때, 네가 하는 걱정은 C 컴파일러가 오브젝트 파일을 서투르게 처리 할때의 걱정과 같다. 다른 컴파일러들이 구현에 의존적인 요소들에 대하여 동일하지 않으면, 그런 파일들을 혼합해서 쓸 방법이 없다. (구현 의존 요소:int, double의 크기, 인자를 넘기고 받는 방법, 호출자와 호출간에 통신 ) 이러한 개발 환경에서 컴파일러들을 섞어서 사용하는 것에(mixed-compiler) 관한 실질적은 관점은 언어의 표준에 대한 노력에 의해서 아마 완전히 무시 된다. 그래서 컴파일러 A와 컴파일러 B의 오브젝트 파일을 안전하게 섞어서 쓸수 있는 신뢰성 있는 유일한 방법은, 컴파일러 A,B의 벤더들이 그들의 알맞는 output에 대한 product의 정보를 확실히 아는 것이다. 이것은 C++와 C를 이용하는 프로그램, 그런 모든 프로그램에 대하여 사실이다. 그래서 당신이 C++과 C를 같은 프로그램에서 섞어서 쓰기 전에는 C++와 C컴파일러가 알맞는 오브젝트 파일을 만들어 내야만 한다.
       당신도 알다 시피, name mangling(이름 조정:이후 name mangling로 씀) 당신의 C++ 컴파일러가 당신의 프로그램상에서 각 함수에 유일한 이름을 부여하는 작업이다. C에서 이러한 작업은 필요가 없었다. 왜냐하면, 당신은 함수 이름을 오버로드(overload)할수가 없었기 때문이다. 그렇지만 C++ 프로그래머들은 최소한 몇개 함수에 같은 이름을 쓴다.(예를들어서, iostream 라이브러리를 생각해보자. 여기에는 몇가지 버전이나 operator<< 와 operator>>가 있다. ) 오버로딩(overloading)은 대부분의 링커들에게 불편한 존재이다. 왜냐하면 링커들은 일반적으로 같은 이름으로 된 다양한 함수들에 대하여 어두운 시각을 가진다. name magling은 링커들의 진실성의 승인이다.;특별히 링커들이 보통 모든 함수 이름에 대하여 유일하다는 사실에 대하여
       C++의 테투리에 머물러 있다면, name mangling은 당신과 그리 관계 있는 것 같지 않다. 만약 당신이 컴파일러가 xyzzy라고 magling한 drawLine이라는 함수를 가지고 있다면 당신은 항상 drawLine이라고 사용하고, 오브젝트 파일에서 xyzzy라고 교체되어 쓰는것에는 주의를 기울일 필요가 없다.
       그리고 당신의 코드는 일반적으로 사용하는 것처럼 drawLine을 호출하는 코들르 가진다. 그러한 각 호출마다 당신의 컴파일러가 mangle을 한 함수 이름을 호출 부분에 넣는다. 그래서 이론 코드를 쓰면,
       그렇지만 만약 drawLine가 C함수라면, drawLine 함수를 호출할때 drawLine으로 포함하는 컴파일러된 버전으로 오브젝트( 혹은 동적 링크 라이브러리 등) 파일에 포함되어 있다.;name mangle이 되지 않은 체로 되어 있다. 당신이 이 둘을 모두 섞어서 프로그램 하려고 노력하면, 에러가 날것이다. 왜냐하면 링커는 xyzzy의 호출되는 함수를 찾고, 그에 관한 함수가 없기 때문이다.
       이런 문제를 해결하기 위하여, C++ 컴파일러에게 해당 함수에 name mangle을 수행하지 않도록 알려야 할 방법이 필요하다. C든, assempler, FORTRAN, Lisp, Forth나 니가 가진 무슨 언어간에, 다른 언어에서 작성되어진 name mangle 처리된 함수를 원할수 없다.(예, 이 언어들에 COBOL도 들어가겠지만 당신이 쓰는가?) 결곡, 만약 C함수인 drawLine을 호출하면 그것은 진짜로 drawLine을 호출하고, 당신의 오브젝트 코드역시 그 이름 그대로 변화없이 사용한다.
       그런 방법에 이용하는건, "표준" 적인 name mangle 알고리즘이란 없다. 다른 컴파일러는 다른 방법으로 name mangle 을 막는 방법을 제공한다. 이는 좋은 것이다. 만약에 모든 컴파일러가 같은 방법으로 name mangle을 수행 하면, 당신은 아마도 그들이 만들어 내는 알맞은 코드에 대한 생각에 안심해 할지 모른다. 만약 당신이 정확하지 않은 C++ 컴파일러로 부터 생성된 객체를 혼용하면 링크중에 에러를 발생할수 있는 좋은 기회를 맞이할것이다. 왜냐하면, mangle처리된 이름을 찾을수 없기 때문이다. 이것은 당신에게 알맞음을 따지는 또다른 문제를 의미하고, 또 도좋은 해결책을 찾아야 함을 의미한다.
       main이 수행되기 전에 객체가 생성되야 하는 필요성이 있지만, main이 가장 처음 불려야 하는것으로 가정되는 딜레마의 해결을 위해서, 많은 컴파일러 들이 특별한 컴파일러가 작성하는 함수를 main의 시작단에 넣는다. 그리고 이 특별한 한수는 static initialization 을 한다. 비슷하게 컴파얼러는 종종 main의 끝에 특별한 함수를 넣어서 static 객체의 삭제를 수행한다. main 에 대해 작성되는 코드는 종종 main 이 엃게 작성되는 것처럼 보인다.
       이렇게 의미 그대로는 아니다. performStaticInitialization 과 performStaticDestruction 은 보통 훨씬 난해한 이름이고, 그들은 inline 으로 우리의 객체 파일에서 어떠한 함수로 알아볼수 있게 작성되어 있다. 중요한 점은 이것이다.:만약 C++ 컴파일러가 정적(static) 객체의 초기화(initialization)와 파괴(destruction)를 이러한 방법으로 적용하면, C++에서 main이 작성되지 않았다면, 초기화와 파괴가 수행되지 않을 것이다. 정적 초기화, 파괴에 대한 이러한 접근이 일반적이기 때문에, 만약 C++에서 소프트웨어 시스템의 어떤 부분을 작성할때 main을 작성하도록 노력해야 할것이다.
       만약 C++에서 main을 작성할수 없다면 문제가 된다. 왜냐하면, 정적(static) 객체 호출을 위한 생성자, 파괴자에 대하여 이식성에 확신을 줄수 없기 때문이다. 이것은 모든것을 잃는다는 의미는 아니다. 단지 좀더 할일이 많아 진다는 것을 의미한다. 컴파일러 밴더들은 이러한 문제를 잘 알고 있다. 그래서 거의 대부분의 벤더들은 static initialization, destruction을 위해서 몇가지의 언어와 관계없는 기술을 제공한다. 이에 관한 정보는 당신의 컴파일러의 문서를 참조하거나, 벤더들에게 문의해라
       메모리 leak를 피할려면, strdup 내부에서 할당된 메모리를 strdup의 호출자가 해제해 주어야 한다. 하지만 메모리를 어떻게 해제 할것인가? delete로? free로? 만약 strdup를 당신이 C 라이브러리에서 불렀다면, free로, C++ 라이브러리에서 불렀다면 delete로 해야 한다. 무엇이 당신은 strdup 호출후에 무엇이 필요한가, 시스템과 시스템 간에 뿐이 아닐, 컴파일러, 컴파얼러 간에도 이건 문제를 일으킬수 있다. 그러한 이식성의 고통의 감소를 위해, 표준 라이브리에서 불러야 하지 말아야할 함수, 대다수 플렛폼에 종속적으로 귀속된 모습의 함수들을 부르지 않도록 노력하라.
       우리는 C++와 C프로그램 사이에 데이터 교환에 관해서 다룬다. C++의 개념을 이해하는 C 함수를 만드는것 불가능 하다. 그래서 이 두 언어간의 전달의 수준은 C가 표현할수 있는 개념으로 한정된다. 그래서 객체의 전달 방식이나, 포인터를 C 에서 작성된 루틴의 멤버 함수로 전달하는 방법은 이식성이 떨어질것은 분명하다. C는 일반적인 포인터 이해한다. 그래서 당신의 C++와 C컴파일러가 만들어 내는, 두가지의 언어에서 알맞는 함수는 pointer와 객체를 pointer와 non-member 나 static 함수를 안전하게 교체할수 있다.자연 스럽게, 구조체와 built-in형의 변수들 역시 자유로이 C+++/C의 경계를 넘나든다.
       C++에서 구조체의 설계 규칙이 C에서의 그것과 일치하기 때문에 양 언어가 각자의 컴파일러로 같은 규칙으로 구조체가 설계되어 있다고 가정 할수 있다. 그러한 구조체는 안전하게 C++과 C사이에 교환될수 있다. 만약 당신이 ''비가상 함수''를 C++ 버전의 구조체에 추가 했다면, 그것의 메모리 모양(layout)은 바뀌지 않는다. 그래서 비가상 함수를 포함하는 구조체(혹은 클래스)의 객체(object)는 오직 멤버 함수가 없는 구조체 C로 최적화 될것이다. 가상 함수를 더하는 것은 논할 가치가 없다. 왜냐하면 가상 함수를 클래스에 추가하는 것은 메모리의 배열에 다른 모습을 보인다. (Item24참고) 다른 구조체(혹은 클래스)로 부터 상속 받은 구조체는 보통 그것의 메모리상 모습이 바뀐다. 그래서 기본(base) 구조체(혹은 클래스)에 의한 구조체 역시 C함수의 지원이 미흡하다.
        * C++, C컴파일러가 조화로운 오브젝트 파일을 생성하도록 하라.
       ISO/ANSI standard for C++ 는 컴파일러가 구현될때, 벤더들의 조언이고, 책을 준비할때, 작가들이 시험해 볼 것이고, 프로그래머들이 C++에 관한 정의에 질문에 답이다. ARM이 나온 이후 C++에 가장 큰 변화를 알아 보자.
• MoreEffectiveC++/Efficiency . . . . 28 matches
       많은 사람들이 병목현상(bottleneck)에 관한 해결책에 고심한다. 경험에 따른 방법, 직관력, tarot 카드이용(운에 맏기기) 그리고 Ouija(점괘를 나타내는 널판지의 상표명, 즉 점보기) 보드를 사용 하기도 하고, 소문이나 잘못, 올바르지 않은 메모리 할당, 충분하지 않은 최적화를 한 컴파일러, 혹은 치명적인 순환 구문을 만들어내기 위해 어셈블리 언어를 사용한 돌대가리 메니저들의 메니저들. 이러한 사정들은 일반적으로 멸시의 비웃음을 동반하고, 그들의 예언은 솔직히 잘못된 것이다.
       대부분 프로그래머들은 그들의 프로그램에 관한 특성에 관하여 멍청한 직관력을 가지고 있다. 왜냐하면 프로그램 성능의 특징은 아주 직관적이지 못하다. 결과적으로 남에 눈에는 띄지 않고 말할수 많은 노력이 성능 향상을 위해 프로그램의 관련된 부분에 쏟아 부어 진다. 예를들어서 아마, 계산을 최소화 시키는 알고리즘과 데이터 구조가 프로그램에 적용 되다. 그렇지만 만약에 입출(I/O-bound)력 부분 적용된다면 저것은 허사가 된다. 증가되는 I/O 라이브러리는 아마 컴파일러에 의하여 바뀐 그 코드에 의해 교체될것이다. 그렇지만, 프로그램이 CPU-bound에 대한 사용이라면 또 이건 별로 중요한 포인터(관점)이 되지 않는 것이다.
       '''lazy fetching'''을 적용 하면, 당신은 반드시 field1과 같은 const멤버 함수를 포함하는 어떠한 멤버 함수에서 실제 데이터 포인터를 초기화하는 과정이 필요한 문제가 발생한다.(const를 다시 재할당?) 하지만 컴파일러는 당신이 const 멤버 함수의 내부에서 데이터 멤버를 수정하려고 시도하면 까다로운(cranky) 반응을 가진다. 그래서 당신은 "좋와, 나는 내가 해야 할것을 알고있어" 말하는 방법을 가지고 있어야만 한다. 가장 좋은 방법은 포인터의 필드를 mutable로 선언해 버리는 것이다. 이것의 의미는 어떠한 멤버 함수에서도 해당 변수를 고칠수 있다는 의미로, 이렇게 어떠한 멤버 함수내에서도 수행할수 있다. 이것이 LargeObject안에 있는 필드들에 mutable이 모두 선언된 이유이다.
       mutable 키워드는 최근에 C++에 추가되어서, 당신의 벤더들이 아직 지원 못할 가능성도 있다. 지원하지 못한다면, 당신은 또 다른 방법으로 컴파일러에게 const 멤버 함수 하에서 데이터 멤버들을 고치는 방안이 필요하다. 한가지 가능할 법인 방법이 "fake this"의 접근인다. "fake this"는 this가 하는 역할처럼 같은 객체를 가리키는 포인터로 pointer-to-non-const(const가 아닌 포인터)를 만들어 내는 것이다. (DeleteMe 약간 이상) 당신이 데이터 멤버를 수정하기를 원하면, 당신은 이 "fake this" 포인터를 통해서 수정할수 있다.:
        ... // 그래서 과거 컴파일러는 이걸 허용한다.
       이 함수는 *this의 constness성질을 부여하기 위하여 const_cast(Item 2참고)를 사용했다.만약 당신이 const_cast마져 지원 안하면 다음과 같이 해야 컴파일러가 알아 먹는다.
       countChar을 호출하는 곳을 보라. 처음에 구문에서 char 배열이 함수로 전달된다. 하지만 함수의 인자는 const string& 이다. 이런 호출은 오직 형(type)이 알맞지 않은것이 제거되거나 당신의 컴파일러는 훌륭히도 string 형의 임시 객체(temporary object)를 만들어서 그러한 맞지 않는 형문제를 제가하면 성공할수 있다. 그러한 임시 객체는 string 생성자가 buffer인자를 바탕으로 초기화 된다. 그러면 constChar의 str인자는 임시(temporary) string 객체를 받아들인다.(bind-bound) countChar이 반환될때 임시(temporary)객체는 자동 소멸된다.
       보통 당신은 이러한 비용으로 피해 입는걸 원하지 않는다. 이런 특별난 함수에 대하여 당신은 아마 비슷한 함수들로 교체해서 비용 지불을 피할수 있다.;Item 22는 당신에게 이러한 변환에 대하여 말해 준다. 하지만 객체를 반환하는 대부분의 함수들은 이렇게 다른 함수로의 변환을 통해서 생성, 삭제에 대한 비용 지출에 문제를 해결할 방법이 없다. 최소한 그것은 개념적으로 피할려고 하는 방법도 존재 하지 않는다. 하지만 개념과 실제(concep, reality)는 최적화(optimization)이라 불리는 어두 컴컴한 애매한 부분이다. 그리고 때로 당신은 당신의 컴파일러에게 임시 객체의 존재를 허용하는 방법으로 당신의 객체를-반환하는 함수들수 있다. 이러한 최적화들은 ''return value oprimization''으로 Item 20의 주제이다.
       임시 객체의 밑바탕의 생각은 비용이 발생하다. 이다. 그래서 당신은 가능한한 그것을 없애기를 원할 것이다. 하지만 이보다 더 중요한 것은, 이러한 임시 객체의 발생에 부분에 대한 통찰력을 기르는 것이다. reference-to-const(상수참조)를 사용한때는 임시 객체가 인자로 전달될수 있는 가능성이 존재 하는 것이다. 그리고 객체로 함수 값을 반환 할때는 임시 인자(temporary)는 아마도 만들어질것이다.(그리고 파괴되어 진다.) 그러한 생성에 대해 예측하고, 당신이 "behind the scences"(보이지 않는 부분) 에서의 컴파일러가 지불하는 비용에 대한 눈을 배워야 한다.
       컴파일러가 임시 인자들에 대한 비용 을 제거할수 있는 그런 방법이라면, 객체를 반환하는 함수 작성에 대해서는 가능할 것이다. 만약 객체 대신에 생성자 구문을 써넣어버리는 트릭(trick)이라면 말이다. 그리고 다음과 같이 할수 있다.
       이러한 지역 객체 대신의 생성자 구문을 반환하는 작업은 당신에게 더 많은걸 요구한다. 왜냐하면 당신은 아직 임시 객체에 대한 생성과 파괴에 대한 비용을 가지고 있고, 당신은 함수의 반환 객체들의 생성, 파괴에 대한 비용을 지불해야 하기 때문이다. 그렇지만 당신은 몇가지를 얻을수 있다. C++의 규칙은 컴파일러들이 임시 객체를 최적화 시키도록 한다. 결론적으로, 만약 당신이 operator*의 구문이 이것고 같다면,
       당신의 컴파일러는 operator*내부의 임시 인자를 없애고 그 임시 인자는 operator*에 의하여 반환 된다. 그들은 객체 c를 메모리에 할당하는 코드에 대하여 return 표현에 의해 정의된 객체를 생성한다. 만약 당신의 컴파일러가 이렇게 한다면 operator*에 대한 임시 객체의 총 비용은 zero가 된다. 게다가 당신은 이것보다 더 좋은 어떠한것을 생각할수 없을꺼다. 왜냐하냐면 c가 이름 지어진 객체이고, 이름 지어진 객체는 사라지지 않기 때문이다.(Item 22참고). 거기에 당신은 inline함수의 선언으로 operator*를 부르는 부하 까지 없앨수 있다.
       "내~ 내" 하고서 당신은 궁시렁 거릴꺼다. "최적화라..바보 짓이지. 누가 컴파일러가 그렇게 할수 있다고 하는거지? 나는 정말 컴파일러가 저렇게 하는지 알고 싶은데. 진짜 컴파일러가 저런 일을 하는거 맞아?" 이렇게 말이다. 이러한 특별한 최적화-함수의 반환 값을 가능한한 지역 임시 객체가 사용되는 것을 제거해 버리는것-는 유명한 것이고, 일반적으로 구현되어 있다. 그것은 이렇게 이름 붙여진다.:thr return value optimization. 사실 이런 최적화에 대한 이름은 아마 많은 곳에서 설명되어 질꺼다. 프로그래머는 C++컴파일러가 "return value optimization"을 할수 있는지 벤더들에게 물어 볼수도 있을 정도다 만약 한 벤더가 "예"라고 하고 다른 곳은 "뭐요?" 라고 묻는다면 첫번째 벤더는 당근 경쟁력에서 앞서 가는거다. 아~ 자본주의 인가. 때론 당신은 그걸 좋아 할꺼다.
       컴파일러가 수행해주는 이런 종류의 변환은 참 편하다. 그렇지만 이런 변환에 의해 생성되는 임시 객체는 우리가 바라지 예상하지 않은 비용을 발생시킨다. 많은 사람들은 단지, 이러한 작업에 대하여 아무런 비용을 지불하지 않기를 바라는것 처럼 대다수 C++ 프로그래머들도 암시적 형변환이 비용에 아무런 영향을 끼치지 않기를 원한다. 그렇지만 이런 계산없이 과연 어떻게 수행할수 있을까?
       이런 템플릿은 거의 위의 코드와 동일해 보이지만 결정적인 차이점이 있다. 바로 두번째의 탬플릿은 result인 '''이름을 가지는''' 객체를 포함한다는 것이다. 이런 이름 있는 객체가 있다는 사실은 최근에 구현된 '''반환 값 최적화'''(return value optimization, Item 20참고)가 operator+에 대하여 작동할수 없다는 것을 의미한다. 두가지중 첫번째 것은 항상 '''반환 값 최적화'''(return value optimization)을 수행하기에 적당하다 그래서 당신이 사용하는 컴파일러가 더 좋은 코드를 만들어낼 가능성이 존재 한다.
       이런 코드는, 대다수의 컴파일러들이 '''반환 값 최적화'''를 수행하는 것 보다 처리하기 더 까다롭다. 처음에 우리는 함수 안에서 단지 당신이 이름 지어진 result을 사용하기 위해 객체에 대한 비용을 지불해야 된다. 이름 지어지지 않은(없는) 객체가 이름 지어진 객체들 보다 더 제거하기 쉬운것은 사실이다. 그래서 이름 지어진 객체와 이름 지어지 않은(없는 ) 객체를 선택하 상황이 주어진다면 당신은 아마 임시 인자들을 사용을 선택하는 것이 더 좋은 방법이다. 그것은 특별히 오래된 컴파일러가 아닌 이상은 결코 이름 지어진 녀석들보다 더 많은 비용을 지불하지 않는다.
       이름이 존재, 비존재 객체와 컴파일러의 최적화에 다한 이야기는 참 흥미롭다. 하지만 커다란 주제를 잊지 말자. 그 커다란 주제는 operator할당 버전과(assignment version of operator, operator+= 따위)이 stand-alone operator적용 버전보다 더 효율적이라는 점이다. 라이브러리 설계자인 당신이 두가지를 모두 제공하고, 어플리케이션 개발자인 당신은 최고의 성능을 위하여 stand-alone operator적용 버전 보다 operator할당 버전(assignment version of operator)의 사용에 대하여 생각해야 할것이다.
       나는 이 프로그램을 몇가지의 기계와 OS를 조합으로 돌렸다. 그리고 모든 경우의 컴파일러에서 stdio버전이 더 빨랐다. 때로 그것은 약간에서(20%정도) 굉장한 차이(거의200%)까지도 보였다. 하지만 나는 결코 iostream의 적용이 stdio적용 보다 빠른 경우는 찾을수가 없었다. 덧붙여서 프로그램의 크기도 stdio가 더 작은 경향을(때로는 아주 많이 차이가 난다.) 보여준다.(실체 프로그램에서 이러한 차이는 정말 중요하다.)
       C++컴파일러는 언어상에서 각 특징을 적용할수 있는 방법을 찾아야만 한다. 물론 그런 적용 방법은 컴파일러 의존적이고, 다른 컴파일러는 다른 방법으로 언어의 특성을 적용할 것이다. 이러한 대부분의 부분에서 당신은 아마 그런 걱정은 필요 없을 것이다. 하지만 몇가지 특징의 적용에서 실행프로그램의 객체와 속도의 크기 큰영향을 준다. 그래서 이러한 영향을 주는 특징들에 관하여 기본적 이해를 하고 있는것이 중요하다. 이러한 것중 가장 앞선 특징이 가상함수(virtual function)이 될것이다.
       가상 함수가 호출될때 해당 코드는 함수가 불리는 객체에서 동적 형(dynamic type)으로 반응해서 실행된다.;포인터의 형(type)이나 객체의 참조는 중요하지 않다. 어떻게 컴파일러는 이러한 행동을 효율적으로 제공할수 있을까? 대다수의 적용 방법(implementations)은 ''virtual table''(가상 함수 테이블)과 ''virtual table pointer''(가상함수테이블 포인터)를 제공한다. virtual table과 virtual table pointer는 일반적으로 각자 ''vtbls''과 ''vptrs'' 로 대신 부를수 있다.
• MoreEffectiveC++/Exception . . . . 19 matches
       다음의 경우 passAndThrowWidget 이 던지는건 Widget 이다. 위에서 언급했듯이 static type으로 예외는 전달된다. 컴파일러는 rw가 SpecialWidget으로의 동작을 전혀 생각하지 않는다.
       일단 이 주제를 부정하는 이는 없으리라.:예외는 적절한 곳에 표현되어야 한다. 그들은 코드를 더 이해가기 편하게 만들어 준다. 왜냐하면 아마 명시적으로 표현된 예외 상태가 전달(던저:throw-이하 던진다는 표현으로) 될 것이기 때문이다. 그렇지만 예외는 주석(comment)보다는 모호하다. 컴파일러는 때때로 컴파일중에 정확히 일치하지 않은 예외들을 발견할수도 있으며, 만약 함수가 예외 스펙(명세:이하명세)상에 제대로 명기되지 않은 예외를 전달(던졌)다면 잘못은 실행시간(runtime)에 발견된다. 그리고 특별한 함수인 unexpected는 자동으로 불리게 된다. 이렇든 예외처리는 상당히 매력적인 면을 가지고 있다.
       unexpected에 관련한 기본적인 행동은 terminate를 호출해서 terminate내에서 abort를 호출로 강제로 프그램을 멈추게 한다. 이 의미는 바로 abort는 프로그램을 종료할때 깨끗이 지우는 과정을 생략하기 때문에 활성화된 스택 프레임내의 지역 변수는 파괴되지 않는다.(즉, 프로그램이 멈추고 디버그시 그 상황에 현재의 자료 값을 조사할수 있다는 의미). 그래서 예외 처리의 명세을 어긴 문제는 상당히 심각한 상황이나, 거의 발생하지 않은 상황이다. 불행히도 그런 심각한 상황을 이르게 하는 함수 작성이 용이하다는게 문제이다. 컴파일러는 오직 예외 명세에 입각한대로 부분적으로 예외 사용에 관한 검사를 한다. 예외가 잡을수 없는것-언어 표준 상에서 거부하는(비록 주의(wanning)일지라도) ''금지하는'' 것- 은 함수를 호출할때 예외 명세에서 벗어나는 함수일것이다.
       당신의 컴파일러가 예외 처리규정에 만족하지 않은 루틴을 가진 함수의 코드를 호출하는데 별 무리없다고, 그러한 호출이 아마 당신의 프로그램에서 프로그램의 중지를 유도하기 때문에 당신은 소프트웨어를 만들때 최대한 그런 만족되지 않은 호출을 최소화 하도록 결과를 유도해야 할것이다. 시작시 가장 좋은 방향은 템플릿상에서의 예외 스펙를 최대한 피하는 것이다. 자 다음의 어떠한 예외도 던지지 않은 템플릿을 생각해 보자.
       이러한 함수 포인터 전달시 관련은 최근에 추가된거니 만약 컴파일러가 지원 못한다고 해도 놀랄것은 없다. (이책은 1996년에 나왔다. 하지만 지금도(2001년정도) 제대로 지원하는 컴파일러가 많지 않은걸로 안다.) 만약 컴파일러가 처리 못한다면 이런 실수의 방지는 당신 자신에게 달렸다.
       이제 당신은 예외 명세가 많은 문제를 가지고 있을수 있음을 이해 할것이다. 컴파일러는 그들의 부분적인 쓰임새를 검사해서 템플릿에서 문제를 발생할 소지를 않으며, 컴파일러는 의외로 규칙위반을 하기 쉽고, 컴파일러가 제대로 되지 않으면 프로그램을 불시에 멈추어 지도록 유도할것이다. 예외 명세 역시 또다른 문제를 안고 있는데, 예외명세는 높은 수준의 호출자가 예외 발생을 대비할때도 unexpected로의 결과물을 만들어 낸다.
       예외 명세의 균형있는 시각은 중요한것이다. 그것은 예외 발생을 예상하는 함수들의 예외 종류들을 보면 훌륭한 문서화가 될것이고, 잘못된 예외 명세의 상황하의 프로그램은 기본적으로 주어지는 상태 즉, 즉시 멈추는 것을 정당화할 만큼 잘못된 일이다. 같은 시각으로 예외는 컴파일러에 의하여 오직 부분적인 점검만을 당하고 예외는 의도하지 않은 잘못을 양산하기 쉬울것이다. 게다가 예외는 unexpected 예외에서 발생하는 높은 레벨의 예외 잡는 문제에 대하여 예방할수 있다.
       이론적으로 당신은 이런(예외) 비용의 지출(선택,select)이 없어야 한다.:C++의 한 부분인 예외, 컴파일러는 예외를 지원해야한다.
       프로그램은 일반적으로 독립적으로 object 파일들이 생성되어 지고, 단지 하나의 작성되어 만들어진 object파일에서 예외 처리가 없다면 다른 것들상의 예외 처리가 아무런 의미가 없기때문에, 당신이 예외처리코드를 사용하지 않는다면, 당신은 컴파일러 제작사들이 이런 예외들을 지원시 일어나는 비용을 없앨 것이라고 예상한다. 게다가 object파일이 예외를 빼기위해 아무런 상호간의 링크가 되지 않는다면 예외 처리가 들어간 라이브러리와의 링크는 어떨까? 즉, 프로그램의 어떤 부분이라도 예외를 사용한다면 나머지 프로그램의 부분들도 예외를 지원해야 한다. 이런 부분적 예외 처리 상황은 실행시간에 정확한 예외를 잡는 수행이 불가능 하게 만들것이다.
       ''' 두번째로 try 블록으로부터의 예외를 잡는(exception-handling)에 대한 비용을 생각해 보자''' 이것은 당신이 catch로 예외 하나를 잡기를 원할때 마다 요구되는 비용이다. 각기 다른 컴파일러들은 서로 다른 방식으로 try블록의 적용을 한다. 그래서 해당 비용은 각 컴파일러마다 다르다. 그냥 대충 어림잡아서 예상하면, 만약 try블록을 쓰게되면, 당신의 전체적인 코드 사이즈는 5-10%가 늘어나고, 당신의 실행 시간 역시 비슷한 수준으로 늘어난다. 이제 아무런 예외를 던지지 않는다고 생각하자;우리가 여기에서 토론하고 있는것은 단지 당신의 프로그램내에서 try가 가지는 비용만이 아니다. 이런 비용의 최소화를 위해서 아마 당신은 필요하지 않는 try블럭은 피해야만 할것이다.
       컴파일러는 수맣은 try 블럭의 예외 스펙에 대한 코드를 위하여 코드를 만들어내야 한다. 그래서 코드 스팩은 일반적으로 하나의 try블럭당 같은 수의 비용을 지출하게 된다. 잠깐?(excuse me?) 당신은 예외 스팩이 단시 스팩인, 즉 코드를 만들어 내는걸 생각하지 않는다고 말한다. 자, 당시은 그런 생각에 관해서 조금 새로운 몇가지를 감안해 봐ㅏ.
       그렇지만 잠깐, 내가 이런것에 관해서 어떻게 아냐구? 만약 예외를 위한 지원은 최근의 컴파일러와 ㄷ컴파일러간에 다른 방식으로 진행된다면서 비용이 5-10%떨어지고 스피드 역시 비슷하게 떨어지고 세개 명령어 정도 늘어나는 것과 같은 성능 저하에 관한 위의 언급 이런것에 관한 출처들? 아마 내가 해줄수 있는 답변은 다소 놀랄것이다.:당신이 try블록과 예외 스펙을 사용을 필요한 곳만 사용하도록 제한해라;그리고 컴파일 해봐라, 그래도 설계상에 문제가 있다면 일단 자신의 설계를 다시 그려보고 생각해 보라, 거기에다, 여기저기 다른 벤더들의 컴파일러로 컴파일 해봐라 그럼 알수 있다.
• Gof/Facade . . . . 10 matches
       예를 들기 위해, 어플리케이션에게 컴파일러 서브시스템을 제공해주는 프로그래밍 환경이 있다고 하자. 이 서브시스템은 컴파일러를 구현하는 Scanner, Parser, ProgramNode, BytecodeStream, 그리고 ProgramNodeBuilder 클래스를 포함하고 있다. 몇몇 특수화된 어플리케이션은 이러한 클래스들을 직접적으로 접근할 필요가 있을 것이다. 하지만, 대부분의 컴파일러 시스템을 이용하는 클라이언트들은 일반적으로 구문분석(Parsing)이나 코드 변환 (Code generation) 의 세부적인 부분에 대해 신경쓸 필요가 없다.(그들은 단지 약간의 코드를 컴파일하기 원할뿐이지 다른 강력한 기능을 알 필요가 없다.) 그러한 클라이언트들에게는 컴파일러 서브시스템의 강력하지만 저급레벨인 인터페이스는 단지 그들의 작업을 복잡하게 만들 뿐이다.
       이러한 클래스들로부터 클라이언트들을 보호할 수 있는 고급레벨의 인터페이스를 제공하기 위해 컴파일러 서브시스템은 facade 로서 Compiler class를 포함한다. 이러한 클래스는 컴파일러의 각 기능성들에 대한 단일한 인터페이스를 정의한다. Compiler class는 facade (원래의 단어 뜻은 건물의 전면. 외관, 겉보기..) 로서 작용한다. Compiler class는 클라이언트들에게 컴파일러 서브시스템에 대한 단일하고 단순한 인터페이스를 제공한다. Compiler class는 컴파일러의 각 기능들을 구현한 클래스들을 완벽하게 은폐시키지 않고, 하나의 클래스에 포함시켜서 붙인다. 컴파일러 facade 는저급레벨의 기능들의 은폐없이 대부분의 프로그래머들에게 편리성을 제공한다.
       서브시스템으로의 public interface는 모든 클라이언트들이 접속가능한 클래스들로 구성되며. 이때 서브시스템으로의 private interface는 단지 서브시스템의 확장자들을 위한 인터페이스이다. 따라서 facade class는 public interface의 일부이다. 하지만, 유일한 일부인 것은 아니다. 다른 서브시스템 클래스들 역시 대게 public interface이다. 예를 들자면, 컴파일러 서브시스템의 Parser class나 Scanner class들은 public interface의 일부이다.
• MoreEffectiveC++/Operator . . . . 10 matches
        * C++에서는 크게 두가지 방식의 함수로 형변환을 컴파일러에게 수행 시키킨다:[[BR]] '''''single-argument constructors''''' 와 '''''implicit type conversion operators''''' 이 그것이다.
       7줄 ''if ( a == b[i] )'' 부분의 코드에서 프로그래머는 자신의 의도와는 다른 코드를 작성했다. 이런 문법 잘못은 당연히! 컴파일러가 알려줘야 개발자의 시간을 아낄수 있으리, 하지만 이런 예제가 꼭 그렇지만은 않다. 이 코드는 컴파일러 입장에서 보면 옳은 코드가 될수 있는 것이다. 바로 Array class에서 정의 하고 있는 '''''single-argument constructor''''' 에 의하여 컴파일시 이런 코드로의 변환의 가능성이 있다.
       '''b[i]''' 는 int형을 반환하기 때문에 이렇게 즉석에서 맞춤 생성자로 type casting(형변환)을 컴파일러가 암시적으로 해줄수 있다. 이제 사태의 심각성을 알겠는가?
       만약 당신의 컴파일러가 엄청 낡은 거거나 제작자가 깜빡해서, 혹은 explicit를 죽어도 넣기 싫다고 할때에는?[[BR]]
       컴파일러 단에서 a생성자인 Array( ArraySize size) 에서 ArraySize 로의 single-argument constructor를 호출하기 때문에 선언이 가능하지만
       *작성자 사설: 아 나는 정말 이런 리턴이 이해가 안간다. 참조로 넘겨 버리면 대체 컴파일러는 어느 시점에서 oldValue의 파괴를 하냔 말이다. C++이 reference counting으로 자원 관리를 따로 해주는 것도 아닌대 말이다. 1학년때 부터의 고민이단 말이다. 좀 명쾌한 설명을 누가 해줬으면..
       이 문장의 해석을 컴파일러는 이렇게 받아 들인다.
       다음과 같은 코드는 컴파일러 단에서 이렇게 교체된다고 볼수 있다.
       당신이 쓰고 있는 컴파일러는 객체 ps point를 파괴하고 객체가 가지고 있는 메모리를 해제한다.
• MoreEffectiveC++/Techniques2of3 . . . . 10 matches
       opintee의 형은 pointer-to-T이다. 아마 String클래스에서는 이것이 String::StringValue의 복사 생성자 일것인데, 우리는 StringValue의 복사 생성자를 선언해 주지 않았다. 그래서 컴파일러가 자동적으로 C++내의 규칙을 지키면서 복사 생성자를 만들어 낼것이다. 그래서 복사는 오직 StringValue의 data 포인터에 해당하는 것만이 이루어 질것이다. data는 복사가 아닌 참조가 행해 질것이다. 이러한 이유로 이후, 작성되는 모든 틀래스에 복사 생성자가 추가되어야 한다.
       이제는 이러한 함수들이 더이상 필요 없다. 물론 아직 String객체의 복사는 지원된다. 복사는 참조세기를 기반한 StringValue객체에서 이루어 지는 것으로, String클래스는 다이성 이런 것을 위해서 한줄도 코딩할 필요가 없다. 그 이유는 이제 컴파일러가 만들 복사 생성자에게 모두 맡겨 버리면 기타의 것들은 모두 자동으로 생성된다. RCPtr은 스마트 포인터이다. 그사실을 기억하라, 복사시 모두 스마트 포인터가 참조를 관리해준다.
       보자마자 이 연산자의 의도를 알것이다. 하지만 operator[][]란건 선언할수가 없다. 그리고 당신의 컴파일러역시 이것을 감안하지 않을 것이다. (오버로드(overload)와 관련한 연산자들에 관한 정보는 Item 7을 참고하라) 우리는 그외의 다른 방안을 찾아야 한다.
       불행히도 이러한 것은 수행되지 않는다. 컴파일러는 const와 non-const 멤버 함수의 구분을 오직 그 객체가 const인가의 여부에 따라만 판단한다. 이러한 구현은, const구별의 목적을 위해 아무런 영향을 못 끼친다.
       s1[5]의 표현은 CharProxy 객체를 반환한다. s1[5]가 output(<<) 연산자에 대하여 객체에 대하여 정의된것은 없다. 그래서 당신의 컴파일러는 operator<<에 적용할수 있는 암시적(implicit) 형변환을 찾는다. 컴파일러는 그래서 프록시 클래스 내부에 선언되어 있는 char()를 찾을수 있다. 컴파일러는 이(char) 형변환을 수행하기를 요청하고, 결과적으로 CharProxy는 문자로 변환되어서 출련되어 진다. 다시 말하지만, 이것은 CharProxy-to-char 로의 형변환이 CharProxy내부에 암시적(implicit) 형변환이 선언되어 있기 때문이다.
       s1[1]의 표현은 CharProxy를 반환하기 때문에, 두번째에서 오른쪽의 의미는 CharProxy*를 반환하는 것이다. 하지만 CharProxy*를 char*로 바꾸는 형변환은 허용되지 않기때문에 p의 초기화에서 컴파일러는 에러를 낸다. 일반적으로 proxy의 주소는 실제 객체보다 다른 포인터 타입을 가진다.
       이러한 어려움은 충분히 예상된다. operator[]가 반환하는 유리수에 관한 프록시이지 진짜 Rational객체가 아니다. numerator과 denominator 멤버 함수는 Rational위해서만 존재하지 프록시를 위해서는 존재하지 않는다. 그러므로 컴파일러가 이에 대한 수행을 못한다. 프록시를 만드는것은 그들이 의미하는 객체와 비슷한거지 완전히 동일한 객체의 기능을 제공할수 없다.
       마지막 프록시가 실패하는 진짜 객체를 교체하지 못하는 상황은 암시적(implicit) 형변환에서 기인한다. 프록시 객체는 암시적(implicit)으로 진짜 객체로 형변환할때 user-defined 형변환 함수가 불린다. 예를들어서 CharProxy는 char로 operator char을 호출해서 변화한다. Item 5의 설명을 보면 컴파일러는 user-defined 형변환 함수를 반응하는 인자로의 필요성이 있는 부분에서 해당 연산을 호출한다고 한다. 결국 함수 호출은 프록시가 전달될때 실패하면 실제 객체를 넘기는 것을 성공시켜서 가능한 것이다. 예를들어서 TVStation리하는 클래스에 watchTV 함수가 있다고 한다면:
• CToAssembly . . . . 9 matches
       기계어 프로그램은 컴퓨터가 이해하고 직접 실행할 수 있는 프로그램이다. 어셈블리어 명령어는 기계어 명령어와 보통 일대일 관계로 대응하지만, 우리가 쉽게 이해할 수 있는 문자열을 사용한다. 고급언어 명령어는 영어에 매우 가까워서 프로그래머가 생각하는 방식과 자연스럽게 대응한다. 결국 어셈블리어나 고급언어 프로그램은 변환기라는 프로그램에 의해 기계어로 변환되야 한다. 이 변환기를 각각 어셈블러(assembler), 컴파일러(compiler) 혹은 인터프리터(interpreter)라고 한다.
       C/C++같은 고급언어의 컴파일러는 고급언어를 어셈블리코드로 변환할 수 있다. GNU C/C++ 컴파일러의 -S 옵션은 프로그램 소스에 해당하는 어셈블리코드를 생성한다. 반복, 함수 호출, 변수 선언과 같은 기본적인 구조가 어셈블리어로 어떻게 대응하는지 알면 C 내부를 이해하기 쉽다. 이 글을 이해하기위해서는 컴퓨터구조와 Intel x86 어셈블리어에 익숙해야 한다.
       80386 이상 프로세서에는 많은 레지스터와 명령어, 주소지정방법이 있다. 그러나 간단한 명령어 몇개만 좀 알아도 GNU 컴파일러가 만드는 코드를 충분히 이해할 수 있다.
       cc first.s 명령어를 실행하면 이 파일을 어셈블하고 링크하여 a.out을 만든다. GNU 컴파일러 앞단 cc가 `.s' 확장자를 어셈블리어 파일로 인식하여, 컴파일단계를 생략하고 어셈블러와 링커를 부른다.
       함수로 파라미터를 전달하기위해 스택을 사용할 수 있다. 우리는 함수가 eax 레지스터에 저장한 값이 함수의 반환값이라는 (우리가 사용하는 C 컴파일러의) 규칙을 따른다. 함수를 호출하는 프로그램은 스택에 값을 넣어서 함수에게 파라미터를 전달한다. 목록 5는 sqr이라는 간단한 함수로 이를 설명한다.
       컴파일러가 asm의 의미를 모르기때문에 asm을 사용하면 컴파일러의 효율성을 제한할 수 있다. GCC는 어떤 최적화를 막을 수 있는 보수적인 추측을 하게 된다.
       여러 작은 C 프로그램을 (-O2 같은) 최적화 옵션을 주고 또 안주고 컴파일해보라. 결과 어셈블리코드를 읽고 컴파일러가 사용한 공통된 최적화 기법을 찾아라.
• EffectiveC++ . . . . 9 matches
       define 된 ASPECT_RATIO 란 상수는 1.653으로 변경되기때문에 컴파일러는 ASPECT_RATIO 란것이 있다는 것을 모르고 symbol table 에?들어가지 않는다. 이는 debugging을 할때 문제가 발생할 수 있다. -인택
       삭제하려고 하며, 베이스 클래스는 가상 소멸자를 가지고 있지 않은 경우. 그 결과는 정의되어 있지 않다. 이것은 컴파일러로 [[BR]]
       치환의 오른쪽 부분이 String형이 아니라 char *형이기 때문에 컴파일러는 String의 생성자를 통해 임시 String객체를 만들어서 호출을 한다. 즉, 아래와 같은 code를 생성한다.
       컴파일러는 위와 같은 임시 객체를 만들려고 하지만, 임시 객체가 const라는 것에 주의. 그리고, operator=의 리턴형을 보면 String에 대한 레퍼런스를 돌려주기 때문에 리턴형이 일치하지 않게 된다. 그래서, error를 발생시킨다. 만약 error를 발생 시키지 않는다면, operator=이 호출되는 측에서 제공된 인자가 아니라 컴파일러가 발생시킨 임시 변수만 수정된다는 것에 놀랄것이다. --;[[BR]]
        * 요즘 컴파일러는 대충 이정도는 알아서 해주지 않나요?;;
       이것 말고도 인라인 함수의 함수포인터를 취할 때 컴파일러에 따라 파일마다 정적 복사본을 생성시킬수도 있다.
        * 생성자와 소멸자는 인라인으로 사용해서는 안된다. 이는 컴파일러구현자가 때에 따라 생성자와 소멸자에 보이지않는 코드부분을 포함할 수도 있기 때문이다.
       === 항목 48. 컴파일러의 경고(Warning)에 주의를 기울여라. ===
• STLErrorDecryptor . . . . 9 matches
       VC++를 가지고 STL 프로그래밍을 하시는 분들이 가장 많이 느끼는 불편함(어느 플랫폼이나 마찬가지이지만)중 하나가 바로 "'''에러 메시지에 나타나는 STL 컴포넌트가 무엇인지 도통 모르겠다'''"라는 점일 겁니다. 이는 컴파일러가 STL 템플릿을 인스턴스화할 때 타입 매개 변수가 모두 포함된 상태로 전체 이름을 써 버리기 때문에 STL 책에 나오지도 않는 클래스 이름과 템플릿 이름 등이 마구 튀어나옴은 물론이거니와, 인스턴스화한 클래스 이름 자체가 엄청나게 길어져서, 코드 한 줄에 대한 에러 메시지가 수십 여 줄까지 만들어지는 현상이 일어나지요.
       이러한 현상은 이펙티브 STL의 항목 49에서도 다루어진 이야기입니다. 원저자는 "많이 읽어서 익숙해져라"라는 결론을 내리고 있지만, 이 문제를 도구적으로 해결한 방법도 있다는 언급도 하고 있었죠. 여기서 이야기하는 [http://www.bdsoft.com/tools/stlfilt.html STL 에러 해독기](이하 해독기)가 바로 그것입니다. 이 도구는 VC 컴파일러가 출력하는 에러 메시지를 가로채어 STL에 관련된 부분을 적절하게 필터링해 줍니다.
       가) 여느 개발도구와 마찬가지로 VC의 IDE는 그 자체에 빌드용 장치(컴파일러와 링커)를 내장하고 있지 않고, 외부에 있는 컴파일러와 링커를 실행해서 프로그램을 빌드합니다. 컴파일러와 링커의 출력 결과는 실제로 콘솔로 빠져 나오는 출력이지만, 네임드 파이프(named pipe)란 것을 통해 VC의 IDE로 다시 들어가 '''출력(output)''' 윈도우에 디스플레이되는 것입니다.
       컴파일을 맡은 프로그램은 CL.EXE란 것인데, 이 프로그램은 C/C++컴파일러(C2.DLL+C1XX.DLL)를 내부적으로 실행시키는 프론트엔드의 역할만을 맡습니다. VC IDE는 컴파일시 이 프로그램을 사용하도록 내정되어 있습니다.
       나) '''원래의 C/C++ 컴파일러를 작동시키되 그 결과를 필터링해주는 기능이 추가된 프론트엔드를 CL.EXE이란 이름으로 행세(?)'''하게 하면, VC의 IDE나 기존의 개발환경에 전혀 영향을 주지 않고 필터링만 할 수 있게 될 겁니다. 해독기 패키지에는 이런 CL.EXE가 포함되어 있습니다. 이것을 "프록시(proxy) CL"이라고 부릅니다.
        * '''STLfilt.pl : 컴파일러의 출력 결과를 필터링 해주는 펄 스크립트.이 파일의 위치를 잘 기억해두세요.'''
        * CL_DIR : VC의 컴파일러 프론트엔드인 CL.EXE가 위치한 디렉토리. 이 부분을 지정하지 않으면 해독기 컨트롤러가 제대로 작동하지 않습니다.
• Android/WallpaperChanger . . . . 8 matches
       자세한 내용을 다루기 전에, 간단한 주의사항입니다: 아래 설명된 대부분의 이슈들은 VM이 JIT 컴파일러이든 아니든 효과적입니다. 같은 기능을 수행하는 두 메소드가 있고 interpret 방식에서 foo()의 실행속도가 bar()보다 빠르다면, 컴파일 된 버전에서도 아마 foo()가 bar()과 비슷하거나 더 빠른 속도를 보여줄 것입니다. 컴파일러가 여러분을 "구해줄"것이라던가 충분히 빠르게 만들어줄 것이라고 의존하는 건 현명하지 못하다는 것이죠.
       C++와 같은 네이티브 언어에서 필드에 직접적으로 접근하는 것 (예. i = mCount) 보다 getter를 사용하는 것 (i = getCount())은 일반적인 관습입니다. 이 방법은 C++에서는 훌륭한 습관입니다. 왜냐하면 항상 접근을 inline화 할 수 있는 컴파일러를 사용하고 있고, 필드에 접근을 제한하거나 디버그 해야 한다면 언제나 코드를 추가할 수 있기 때문입니다.
       컴파일러는 클래스가 처음 사용될 때 실행하게 되는 <clinit>라 불리는 '클래스 초기화 메소드'를 생성합니다. 이 메소드가 intVal에 42 값을 저장하고, strVal에는 클래스파일 문자 상수 테이블로부터 참조를 추출하여 저장합니다. 나중에 참조될 때 이 값들은 필드 참조로 접근됩니다.
       "final"으로 메소드나 클래스의 선언을 하는 것은 즉각적인 성능 이득을 주지는 못하지만, 특정한 최적화를 가능하게 합니다. 예를 들어, 컴파일러가 서브클래스에 의해 오버라이드될 수 없는 "getter"메소드를 알고 있다면, 메소드 호출을 inline화 할 수 있습니다.
       two() 는 자바 언어의 1.5버전에서 소개된 향상된 반복문 구문을 사용합니다. 컴파일러에 의해 생성된 코드는 배열 참조와 배열의 길이를 지역 변수로 복사해주어, 배열의 모든 원소를 탐색하는데 좋은 선택이 될 수 있습니다. 주 루프 내에 추가적인 지역 읽기/저장이 만들어지고(명백하게 "a"에 저장), one()보다 쪼금 느리고 4 바이트 길어지게 하긴 합니다.
       는 정적 필드 참조를 야기합니다. "GROUND"가 정적 final int 였더라면, 컴파일러는 알려진 상수로서 다루고, inline화 했을 수도 있습니다.
       문제는 Foo$Inner는 기술적으로는 (비밀로써) 완전히 분리된, Foo의 private 멤버로 직접적인 접근을 하는 것은 적법하지 못한 클래스라는 것 입니다. 이 차이를 연결짓기 위해, 컴파일러는 두 개의 합성 메소드를 만듭니다:
• MoreEffectiveC++/Techniques1of3 . . . . 8 matches
       같은 코드 써서 내용만 늘린 것 같다. 하지만 조금더 언급해 본다면. Printer::maxObjects는 클래스 내부에서 10으로 초기화 시켰는데, 이는 컴파일러의 지원 여부에 따라 static const 멤버의 경우 초기화가 가능한 C++의 규칙이다.(주:참고 내용이 있었는데 몇 장인지 기억 안난다.) 그리고 maxObject에 관하여 변하지 않는 값이기에 enum으로도 쓸수 있는데, 다음과 같다.
       그리고 만약에 현재 컴파일러가 클래스 내부에서 초기화를 허용하지 않는다면 이렇게 써서 해결하라.
       위의 둘다 상단의 코드와 동일한 역할을 하는 것이다. 좋은 컴파일러 쓰시길..
       만약, using을 지원하지 않은 컴파일러라면 다음과 같은 옛날 문법을 사용할수 있다.
       자 다음과 같이, UPNumber 클래스는 Heap상에서만 사용할수 있는 객체만을 생성 할수 있다. 이것의 대안으로는 Item 26 마지막에 나온 예제와 같이 모든 생성자 만을 사역(private)화 시키는 것이지만, 이 아이디어의 문제는 많은 생성자가 모두 사역(private)으로 있어야 하고, 그것들을 반드시 기억해야 한다는 점이다. 기본 생성자는 물론, 복사 생성자를 전부 선언해 주어야 한다. 그렇지 않으면 컴파일러는 기본적으로 모두 공역(public)으로 취급하고 지역 변수를 만들수 있다. 결과적으로, 파괴자만을 사역(private)화 시키는 것이 간단하다.
       그렇지만 C++언어 상에서 이런 보장에 대한 스펙이 정의 되어 있지 않다 그래서 어떤 컴파일러는 다음과 같이 부를수도 있다.
       후자의 순서로 코드가 생성되어도 컴파일러에게 잘못은 전혀 없다. 그렇지만 '''set-a-bit-in-operator-new''' 방법을 사용한 상단의 예제는 두번째 순서에서는 실패 할수 밖에 없다.
       위에서 isSafeToDelete를 구현할때 다중 상속이나 가상 기초 함수으로 여러개의 주소를 가지고 있는 객체가 전역의 해당 함수를 복잡하게 할것이라고 언급했다. 그런 문제는 isOnHeap에서 역시 마찬가지이다. 하지만 isOnHeap는 오직 HeapTracked객체에 적용 시킨 것이기 때문에, dynamic_cast operatror를 활용으로 위의 문제를 제거한다. 간단히 포인터를 dynamic_cast 하는 것은 (혹은 const void* or volatile void* or 알맞는 것으로 맞추어서) 객체의 가장 앞쪽 포인터, 즉, 할당된 메모리의 가장 앞쪽에 주소를 가리키는 포인터를 의미한다. 그렇지만 dynamic_cast는 가상함수를 하나 이상 가지는 객체를 가리키는 포인터에 한해서만 허용 된다. isSafeToDelete함수는 모든 포인터에 관해서 가능하기 때문에 dynamic_cast가 아무런 소용이 없다. isOnHeap는 조금더 선택의 폭이 있어서 this를 const void*로 dynamic_cast하는 것은 우리에게 현재 객체의 메모리 시작점의ㅣ 포인터를 주게 된다. 그 포인터는 HeapTracked::operator new가 반드시 반환해야만 하는 것으로 HeapTrack::operator new의 처음 부분에 있다. 당신의 컴파일러가 dynamix_cast를 지원하면 이러한 기술은 이식성이 높다.
• 새싹교실/2013/라이히스아우토반/1회차 . . . . 8 matches
        * 운영체제에서 갑자기 컴파일러로 건너 뛴거에 대한 설명이 없었는데.. 운영체제를 크게 보면 그 안에 컴파일러가 들어가기도 합니다.
        * 중간자 역할 (소프트웨어-운영체제-하드웨어, 고급언어-컴파일러-저급언어) 이란 점에서도 연관이 있습니다.
        1. 컴파일러란 것이 있는데, 우리가 만든 소스(코드가 들어가있는 텍스트파일)를 저급언어(사람은 이해하기 힘들고, 기계가 이해하긴 쉬운)인 어셈블리어로 바꾸어 준다.
        1. 인터프리터라는 것도 있는 데, 코드를 프로그램으로 만들어 주는것은 컴파일러와 같지만, 컴파일러와는 다르다.
        * 이 부분 설명을 잘 못 했는데, 컴파일러는 통역병이라 하고, 인터프리터는 카투사라고 생각하면 좀 더 이해하기 쉬울지도.. 통역병은 통역이 업무지만, 카투사는 직접 듣고 일하는게 주 업.
        *컴파일러는 저급언어를 만들고, 인터프리터는 실행명령을 만듭니다. 이 만들어논 실행명령을 프로그램에 넣으면 실행이 되는거죠. 대표적인 인터프리터인 JVM을 가지고 와서 설명해야 할것 같은데.. 허허
• 코바예제/시계 . . . . 8 matches
       시간 객체에 대한 인터페이스는 ObjTimeServer이며 getTime()이라는 메소드를 가지고 있는데 getTime()는 문자 형식으로 현재의 시간을 반환해 준다. CORBA 객체를 작성하는 첫번째 단계는 인터페이스를 만드는 것이다. 인터페이스는 IDL로 작성되며 인터페이스는 IDL 컴파일러로 컴파일된다. 이 IDL 컴파일러는 기본적으로 사용자가 이용하는(예를들면 VisiBroker) ORB에 포함되어 있는 것이다. IDL로 작성된 인터페이스를 컴파일하면 컴파일러는 두 개의 코드 파일을 생성해 준다. 이 코드 파일들은 각 IDL 컴파일러가 사용하도록 약정된 프로그래밍 언어로 되어 있다. 여기에서 사용하는 ORB는 Java ORB이므로 코드 파일은 Java(Stub, Skeleton)로 되어 있을 것이다. IDL 컴파일러에 의해 생성되는 코드는 프록시 객체(proxy object) 및 스켈레톤 코드이다. 클라이언트는 프록시 객체를 사용하여 IDL로 표현된 인터페이스 타입의 객체 레퍼런스에 대한 호출을 생성한다. 바꾸어 말하녀 프록시 객체는 클라이언트가 작업을 위해 사용하는 대리("stand-in") 객체인데 원격 객체가 마치 지역 객체처럼 보이게 해준다는 것이다. 스켈레톤 코드는 이러한 인터페이스를 지원하는 객체에 액세스하기 위해 사용된다. 생성되는 코드는 위치 투명성을 구현한다. 위치 투명성을 통해 객체 레퍼런스를 변환하여 네트웍 연결을 퉁해 원격 서버로 보내며, 객체 레퍼런스에 대한 오퍼레이션에 따르붙는 파라미터를 ["마샬링"]하고, 이를 객체 레퍼런스가 지시하는 객체의 현재 메소드에 전달하여 메소드를 수행하고 그 결과를 반환하려고 하는 것이다. 바꾸어 말하면 클라이언트는 IDL 컴파일러에 의해 생성된 프록시 객체를 가지고 작업을 하는데, 그것이 마치 지역 객체로 작업하는 것처럼 보일 것이라는 의미이다. ORB와 통신하는 것이 프록시 객체의 임무이며 ORB는 네트웍 연결을 관리하고 파라미터를 실제 서버 함수에 넘겨주며 결과를 리턴한다. 이런 식으로 수행에 대한 투명성을 유지한다.
       위의 IDL을 컴파일하면 스텁과 스켈레톤 코드가 생성된다. 컴파일러가 ObjTimeServer_Skeleton.java라는 이름의 파일을 생성하였으며, 여기에는 서버 쪽에서 사용되는 스켈레톤 코드가 들어 있다고 가정하자. 이제 이 IDL에서 지정된 인터페이스를 갖는 객체를 구현해야만 한다. 이 말은 서버 코드, 즉 구현을 작성해야 한다는 것이다. 그러한 구현 객체 클래스를 작성하기 위해서는 IDL 컴파일러에 의해 만들어진 스켈레톤 클래스와 결합해야 한다. 이 결합은 상속 또는 위임을 사용해서 이루어질 수 이다.
• i++VS++i . . . . 7 matches
        * 사용한 컴파일러 : Microsoft 32-bit C/C++ Optimizing Compiler Version 12.00.8804 for 80x86 (Microsoft Visual C++ 6.0 에 Service Pack 5 를 설치했을때의 컴파일러)
        // 컴파일러는 내부적으로 operator++(0)을 호출한다.
        ++i, 나 i++ 둘다 상관 없는 상황이라면, ++i에 습관을 들이자, 위의 연산자 재정의는 [STL]을 사용한다면 일반적인 경우이다. 후위 연산자가 구현된 Iterator는 모두 객체를 복사하는 과정을 거친다. 컴파일러단에서 Iterator 의 복사를 최적화 할수 있는 가능성에서는 보장할 수 없다. 따라서, 다음과 같은 경우
        요즘 컴파일러들은 최적화가 잘 되어서 이전 값을 돌려주기위해 이전 값을 담을 임시 변수를 만들고 값을 증가시킨 후 임시 변수에 있는 이전 값을 돌려주고 임시 변수를 파괴하는 방식으로 하지 않고, 이전 값을 먼저 돌려주고 값을 증가시킵니다.
       속도가 아주 빨라야 하는 프로그래밍을 할 때는 특정 컴파일러에서 어떻게 할 때가 성능이 더 좋은지 알 필요가 있을수도 있다.
        물론 '''특정''' 컴파일러라는 것이 언제나 명시되어야 한다. 일반화는 일반적으로 옳지 않다.
• BigBang . . . . 6 matches
        * 왜? 컴파일러는 이런거 모르기 때문.
        * switch case문에서 case는 컴파일러만 알뿐(Label이라는 소리..)
        * 비표준이지만 거의 모든 컴파일러가 지원하므로 defacto
        * 가변인자의 형을 검사하는 주체가 컴파일러가 아닌, 함수이기 때문이다.
        * 선언(Declaration) - 어떤 대상의 이름과 타입을 컴파일러에게 알려 주는 것
        * #define을 사용하면 컴파일러가 잡아주지 못해서 에러를 발생시킬 가능성이 크다. 그러나 이 말이 #define을 사용하지 말라는 의미는 아니다! 케바케로서 #define이 const보다 맞는 경우도 존재한다.
• Cpp에서의멤버함수구현메커니즘 . . . . 6 matches
       자신이 컴파일러가 되었다고 가정해 봅시다. 우리가 class를 선언하고 컴파일하려면 프로그램의 영역에 class 의 Data 들을 저장할 수 있는 "class 틀"의 정보를 담아 놓을 곳이 필요합니다.
       그러나, 컴파일러인 우리는 이 정보를 지역 변수이든, new 로 할당이든 컴파일 시간에 인자의 type을 보고 함수 호출 유효성을 확인하고, 적절한 함수 포인터를 함수 호출하는 부분에 넣어 줄수 있습니다. 그리고 실행할 수 있는데 이 과정을 두번째에서 설명합니다.
       자 계속 우리는 컴파일러 입니다. 컴파일러인 우리는 member 함수 호출 부분을 함수의 실행코드를 가리키는 함수 포인터로 모두 교체하였습니다. 그리고 인간으로 돌아옵시다.
       라는 함수 실행 코드가 함수 영역에 선언될때 컴파일러가
       만약 구현 컴파일러가, 메모리를 system으로 반환하고 접근 금지 영역으로 설정한다면, 다음 강제 접근시 access 에러가 나겠지요. 이러한 비효율적 구현 플랫폼 없을 겁니다.
• Gof/Visitor . . . . 6 matches
       [컴파일러]가 abstact syntax tree로 프로그램을 표현한다고 하자. 컴파일러는 모든 변수들이 정의가 되어있는 지를 검사하는 것과 같은 '정적인 의미' 분석을 위해 abstract syntax tree에 대해 operation을 수행할 필요가 있을 것이다. 컴파일러는 또한 code 변환을 할 필요가 있다. 또한 컴파일러는 type-checking, code optimization, flow analysis 와 해당 변수가 이용되기 전 선언되었는지 등의 여부를 검사하기 위해서 해당 operations들을 수행할 필요가 있다. 더 나아가 우리는 pretty-printing, program restructuring, code instrumentation, 그리고 프로그램의 다양한 기준들에 대한 계산을 하기 위해 abstract syntax tree를 이용할 것이다.
       예를든다면, visitor를 이용하지 않는 컴파일러는 컴파일러의 abstact syntax tree의 TypeCheck operation을 호출함으로서 type-check 을 수행할 것이다. 각각의 node들은 node들이 가지고 있는 TypeCheck를 호출함으로써 TypeCheck를 구현할 것이다. (앞의 class diagram 참조). 만일 visitor를 이용한다면, TypeCheckingVisior 객체를 만든 뒤, TypeCheckingVisitor 객체를 인자로 넘겨주면서 abstract syntax tree의 Accept operation을 호출할 것이다. 각각의 node들은 visitor를 도로 호출함으로써 Accept를 구현할 것이다 (예를 들어, assignment node의 경우 visitor의 VisitAssignment operation을 호출할 것이고, varible reference는 VisitVaribleReference를 호출할 것이다.) AssignmentNode 클래스의 TypeCheck operation은 이제 TypeCheckingVisitor의 VisitAssignment operation으로 대체될 것이다.
• AcceleratedC++/Chapter8 . . . . 5 matches
       함수의 호출시 함수의 매개변수를 operand로 하여 행해지는 operator의 유효성을 컴파일러가 조사. 사용 가능성을 판단
        실제 컴파일시 컴파일러는 프로그래머가 지정한 타입으로 이 함수를 인스턴스화 시켜서 생성하고 바인딩한다.
        typename 은 아직 인스턴스화 되지 않은 함수를 컴파일러가 읽어들일때 타입 매개변수와 관계된 타입의 형을 생성할때 앞에 붙여야 하는 키워드 임. ex) vector<T> or vector<T>::size_type
        STL은 실제로 함수의 인스턴스화에 관한 표준적인 방식을 제정하지 않았다. 따라서 각 컴파일러마다 서로 다른 방식으로 함수를 인스턴스화한다. 따라서 자신의 컴파일러의 특징을 파악하는 노력이 필요.
• AcceleratedC++/Chapter9 . . . . 5 matches
        '''※ 이런 식으로 헤더파일을 제공하고 실제의 구현된 소스파일은 이미 컴파일된 obj파일로 제공한다면 실제로 판매되는 컴파일러라도 그 컴파일러가 제공하는 함수의 실제구현은 볼 수가 없다.
        헤더파일은 단지 컴파일러가 컴파일을 할때 이런 함수가 존재한다고 가정만 하고, 실제로 그 함수의 코드가 존재하는 것을 확인 할 수 잇는 것은 모든 관련 오브젝트 파일을 링크한뒤에 호출할때 없다는 것을 확인할 수 밖엔 없다.'''
        만약 프로그래머가 생성자를 명시적으로 지정하지 않으면 컴파일러는 Default Constructor를 만들어주는데, 이 기본 생성자는 명시적인 초기화를 지원하지 않으며, 오로지 동일한 형의 다른 객체로의 초기화만을 제공한다.
        '''※만약 객체의 멤버로 const 멤버가 존재한다면 그 멤버는 반드시 이 표현으로만 초기화가 가능하다. 객체가 초기화 되는 시기는 생성자 코드로 진입되기 이전인데 일단 초기화된 const 멤버는 컴파일러가 그 값의 수정을 허용하지 않기 때문이다. '''
• AsemblC++ . . . . 5 matches
       그렇다면 다른 방법이 있다는 건데... 바로 컴파일러에 어셈블리 코드를 얻어내는 기능이 있습니다.
       요즘 컴파일러들은 컴파일을 하면 오브젝트 파일(.obj)을 생성합니다. 이것은 소스를 해석해서 만들어낸 기계어 코드입니다.
       어셈블리 코드는 기계어와 거의 같다고 봐도 무방하기 때문에 컴파일러의 출력 형식의 차이 정도라고 보시면 되겠습니다.
       MS의 C/C++ 컴파일러에서 어셈블리 코드를 얻는 옵션은 /FA 입니다.
       처음에는 그냥 얼마나, 어떤식으로 컴파일러에 의해서 코드가 최적화되고 [IDE]의 버전과 종류에 따라서 어떤 차이가 존재할까 라는 단순한 물음이었지만, 지금 보니 그렇게 코드를 파해치고 분석하는게 해킹이고 크래킹 인것 같기도 합니다;; - [톱아보다]
• Java Study2003/첫번째과제/장창재 . . . . 5 matches
        자바 언어(Java Language)를 이용하여 작성한 자바 프로그램(Java Program)은 자바 컴파일러(Java Compiler)를 이용하여 자바 바이트코드(Java Byte code)로 컴파일 되고, 이 자바 바이트코드는 자바 가상머신에 의해 해석되어 실행되는데, 이때 자바 가상머신은 자바 바이트코드에 대한 해석기 즉 인터프리터(interpreter)로 동작하게 됩니다. 이렇게 자바 프로그램은 컴파일 방식 및 인터프리터 방식이 모두 적용된다는 것입니다.
        자바 컴파일러(Java Compiler):
       자바 바이트코드는 자바 가상머신에서 실행되는 기계어라고 생각하면 됩니다. 그리고, 모든 자바 인터프리터는 자바 가상머신을 구현해 놓은 것으로, 자바 가상머신과 자바 인터프리터를 같은 것으로 생각할 수 있습니다. . 이러한 자바 가상머신은 JDK(Java Development Kit)에 포함되어 있을 수도 있고, 자바 호환 웹 브라우저 내에 내장되어 있을 수도 있습니다. 또는, 자바 칩과 같이 하드웨어에 직접 구현될 수도 있습니다. 자바 바이트코드는 “write once, run anywhere”라는 말을 가능하게 해 줍니다. 다시 말해서, 자바 언어를 이용하여 작성한 자바 프로그램을 각 플랫폼(윈도우 95/98/NT, 리눅스, 유닉스, 매킨토시 등)에 맞게 제공되는 자바 컴파일러를 통해서 바이트코드로 컴파일 할 수 있습니다. 그리고, 이 바이트코드는 자바 가상머신이 있는 어떤 곳에서도 실행될 수 있습니다.
       자바는 서로 다른 이종(Heterogeneous)의 네트워크 환경에서 분산 되어 실행될 수 있도록 설계되었습니다. 이와 같은 환경에서는 응용 프로그램들이 다양한 하드웨어 아키텍쳐 위에서 실행될 수 있어야만 합니다. 이를 위해 자바 컴파일러는 이종의 하드웨어 및 소프트웨어 플랫폼에서 효율적으로 코드를 전송하기 위해 설계된 아키텍쳐 중립적인 중간 코드인 바이트코드를 생성합니다. 이는 동일한 자바 프로그램의 자바 바이트코드가 자바 가상머신이 설치되어 있는 어떤 플랫폼에서도 실행될 수 있도록 하는 것입니다. 또한, 자바는 기본 언어 정의를 엄격하게 함으로써 효율적인 이식성을 제공해 주고 있습니다. 예를 들어, int 형과 같은 기본 데이터형의 크기를 플랫폼과 무관하게 일정하게 하고, 연산자의 기능을 확실하게 규정하고 있습니다. C 언어를 이용하여 int 형을 선언할 때, 도스에서는 16비트, 윈도우 95/98/NT 등 32비트 운영 체제 환경에서는 32비트, 유닉스에서는 32비트 등 그 플랫폼에 따라 크기가 다르지만, 자바에서는 플랫폼에 상관없이 32비트로 고정되도록 하였습니다. 이는 자바 프로그램이 실행되는 환경이 자바 가상머신으로 동일하기 때문입니다.
       자바 컴파일러를 이용하여 컴파일 할 때 '-O' 옵션을 줌으로써 최적화 시켜줍니다.
• 간단한C언어문제 . . . . 5 matches
       C언어의 컴파일러에 따라 메인함수는 저렇게 쓰일 수가 있어요;;; 특정 컴파일러는 return형이 int형이 아니라고 warnning을 내기도 하죠;; - [이영호]
        특정 컴파일러에 종속적인 프로그래밍은 좋지 않습니다. C90이라는 표준이 엄연히 존재하니까요. 특정 구현에 종속적인 프로그래밍을 한다고 하더라도, 프로그램의 심장은 표준에 따라 프로그래밍 하는게 좋습니다.
       옳지 않다. 문제점은 b=a;에 있다. const char *형을 char *형에 대입할 수 없다. 컴파일러 에러. - [이영호]
       옳지않다. 함수의 프로토 타입이 정의되지 않았기 때문에 return형이 int형으로 바뀐다. 프로토타입은 return 타입을 컴파일러에서 알기 위해 쓰이는 것이다. - [이영호]
• OptimizeCompile . . . . 4 matches
       현재 프로세서의 속도는 [무어의 법칙]에 따라 극한으로 속도가 증가하고 있다. 이러한 상황에서는 예전처럼 [CPU] 의 속도 에 프로그램의 실행속도가 크게 영향 받지는 않으므로, 컴파일러의 최적화 작업도 더이상 연산(computation)을 줄이는 것 만이 목적이 되는 것이 아니라, 좀 더 메모리 계층구조를 효율적으로 사용하는 것에 관심이 기울여지게 된다.
       변수가 값을 할당 받아서, 다시 새로운 값으로 할당 받기 전까지, 그 변수는 일종의 constant 라고 볼 수 있다. 컴파일러는 이를 감지해서 최적화를 수행하게 된다.
       컴파일러는 constant propagation 과 constant folding 을 반복하여 수행한다. 각각 서로의 가능성을 만들어 줄 수 있으므로, 더이상 진행 할 수 없을 때까지 진행한다.
       와 같은 문장이 있을때, 나누기 연산은 곱하기 연산보다 좀더 많은 시간을 소요하므로 컴파일러는
• ProgrammingLanguageClass . . . . 4 matches
       중앙대학교 컴공과에 컴파일러 수업이 폐강되는 경우가 많은데, 컴파일러와 PL 둘 중 하나는 프로그래머가 되건, 전산학자가 되건 반드시 필요한 교양이다.
       컴파일러를 독학하려는 사람들은 [http://no-smok.net/nsmk/_c4_c4_c6_c4_c0_cf_b7_af_c3_df_c3_b5_bc_ad_c0_fb 컴파일러추천서적] 참고.
• pragma . . . . 4 matches
       C 와 C++ 을 구현한 각각의 컴파일러에는 포팅된 하드웨어나 OS 에 의존적인 몇몇가지들의 기능을 가지고 있다. 일례로 몇몇의 프로그램들은 메모리에 데이터가 어떠한 방식으로 자리잡을 것인지 에 관한 문제나 함수가 파라미터들을 조작하는 방법들에 대한 세밀한 조작이 요구된다. #pragma 지시어들은 C 와 C++ 언어 안에서 최소한의 호환성을 유지시키며 그러한 시스템 의존적인 명령어들을 언어의 기능으로서 포함시키는 일을 한다. Pragma 지시어들은 일반적으로 '''컴파일러들 마다 서로 다르다'''.
       하지만, 이러한 경고는 Visual C++ 6.0 에서만 유효한것이고, VS.NET 부터 추가 세팅이 필요 없다. VC++ 6.0 에서는 map은 물론 STLPort 나, [Boost] 사용하는 것을 권장하지 않는다. 더 이상 MS 측의 컴파일러 기술 지원이 없으므로, VS.NET 이상 버전을 사용해야 한다.
       혹시라도.. 저 #pragma warning(disable: n ... m) 을 써서 언제나 문제를 해결 할 수 있을거라고 생각하시면 안됩니다. 저 위의 설명에도 씌여있듯이, pragma directive 는 지극히.. 시스템에 의존적입니다. 그러므로, VC 에서는 먹힌다는 저 명령어가 GCC 에서는 안될수도 있고.. 뭐 그런겁니다. 확실하게 쓰고싶으시다면.. 그 컴파일러의 문서를 참조하는것이 도움될겁니다.
• 2006년4학년1학기수업 . . . . 3 matches
       || 5(1:00) || 컴퓨터네트워크 4551 || 컴파일러설계 4552 || 컴퓨터네트워크 4551 || || ||
       || 6(2:00) || 컴퓨터네트워크 4551 || 컴파일러설계 4552 || || 컴파일러설계 4552 || ||
• Chapter I - Sample Code . . . . 3 matches
        이런저런 소개들. (컴파일러는 무엇을 사용한다. 머 어쩌구저쩌구.)
        uCOS-II는 여타의 DOS Application 과 비슷하다. 다른말로는 uCOS-II의 코드는 main 함수에서부터 시작한다. uCOS-II는 멀티태스킹과 각 task 마다 고유의 스택을 할당하기 때문에, uCOS-II를 구동시키려면 이전 DOS의 상태를 저장시켜야하고, uCOS-II의 구동이 종료되면서 저장된 상태를 불러와 DOS수행을 계속하여야 한다. 도스의 상태를 저장하는 함수는 PC_DosSaveReturn()이고 저장된 DOS의 상태를 불러오는것은 PC_DOSReturn() 함수이다. PC.C 파일에는 ANSI C 함수인 setjmp()함수와 longjmp()함수를 서로 연관시켜서 도스의 상태를 저장시키고, 불러온다. 이 함수는 Borland C++ 컴파일러 라이브러리를 비롯한 여타의 컴파일러 라이브러리에서 제공한다.[[BR]]
• InternalLinkage . . . . 3 matches
       하지만 InternalLinkage가 초례하는 문제는 1996 {{{~cpp ISO/ANSI C++ }}} 표준화 작업에서 인라인함수(InlineFunction)를 ExternalLinkage 로 변경해서 문제가 되지 않는다.(최근의 컴파일러들은 지원한다.).
        - 구형 컴파일러에서는 문제가 될 수 있지만 최근의 컴파일러에는 문제될게 없다고 말하는것 같습니다. 제 생각이 잘못된 것이라면 거침없는 지적을..^^; - [임인택]
• ProgrammingLanguageClass/Report2002_2 . . . . 3 matches
        * 컴파일러가 적용하는 type-compatibility 규칙(묵시적 형변환 따위) 에 대한 평가.
        * 컴파일러에서 포인터에 대한 보안성에 관한 평가
        * 만약 가능하다면 functional side-effects가 발생이 컴파일러에서 operand의 순서에 대한 평가 점검한다. -수정 필요
• 김희성/ShortCoding/최대공약수 . . . . 3 matches
        '''컴파일러''' - gcc 컴파일러는 사용된 function을 확인하여 필요한 header file을 자동으로 include 해줍니다. 또한 gcc 컴파일러는 타입이 선언되지 않은 변수는 int형으로 처리합니다. 이로인해서 main의 본래 형식은 int main(int,char**)이지만 변수형을 선언하지 않으면 두번째 인자도 int형으로 처리됩니다.
• 만세삼창VS디아더스1차전 . . . . 3 matches
        내 컴파일러론 되는데 너 컴파일러 버젼업해라
        컴파일러 욕하지 마라 ㅋ
• 새싹교실/2011/Pixar/3월 . . . . 3 matches
        * Keywords : 컴파일러, 프로그래밍 언어, printf 함수, main 함수, #include, assert 함수, 변수, 자료형
        * 컴퓨터는 0과 1밖에 몰라서 사람 말로는 대화할 수 없습니다. 우리가 쓴 코드를 컴퓨터가 이해하기 위해서는 컴파일러의 도움을 받아야합니다.
        * 컴파일러는 번역가 같은 역할을 합니다. 우리가 짠 코드를 컴퓨터가 이해할 수 있게 번역해줘요.
• 새싹교실/2012/개차반 . . . . 3 matches
        * 컴파일러의 역할과 compile -> link -> build 과정 설명
        * 컴파일러 (complier)
        * 컴파일러에 의해 이미 정해져 있는 이름 (identifier)
• 호너의법칙/조현태 . . . . 3 matches
       └ 헤더파일 에러나는건 표준이전에 나온 컴파일러(97년 이전)를 써서 그러는데 C++표준 헤더는 확장자가 붙지 않습니다. 97년 이후에 나온 컴파일러를 써보세요. - [이재혁]
       그리고 제가 사용한 컴파일러(비주얼 .NET) 은 저에게 말하면 미소녀는 무료, 일반인은 밥 한끼, 미소년은 무한끼에 FTP나 HTTP로 제공해드리고 있습니다.^^
• AcceleratedC++ . . . . 2 matches
        || [http://msdn.microsoft.com/visualc/vctoolkit2003/ VSC++ Toolkit] || .net 을 구입할 수 없는 상태에서 STL을 컴파일 해야할 때 사용하면 되는 컴파일러. ||
        '''Visual C++ 6에서 굳이 하실 분들은 ''#pragma warning(disable: 4786)'' 전처리기로 컴파일러 warning을 죽이면 기타 잡스런 워닝을 없애는 것이 가능합니다.'''
• AcceleratedC++/Chapter10 . . . . 2 matches
       int* p; // p는 int*라는 것을 강조하는 표현이다. C컴파일러는 * 주변의 공백을 무시하기 때문에 상기의 2개 표현은 완전히 동일하다.
        상기의 예제에서 month_length의 배열의 크기를 명시적으로 나타내지 않았다는 사실에 유의. 대신에 컴파일러가 초기화된 갯수에 맞추어서 배열을 할당한다.
• AcceleratedC++/Chapter11 . . . . 2 matches
       우리가 복사, 대입, 소멸시 하는 일에 대해서 명시적으로 정하지 않으면 컴파일러는 정해진 자신만의 방법으로 이런 일을 하는 정의를 만들어서 작동하게 된다.
        생성자, 소멸자, 복사 생성자, 대입연산자를 재정의 하지 않을 경우에는 컴파일러가 기 정의된 방식으로 이런 생성자의 기본형을 만든다.
• AcceleratedC++/Chapter13 . . . . 2 matches
        인자를 전달하면서 생기는 모호함을 피하기 위해서 compare 라는 이름대신에 compare_Core_ptrs를 사용하여 컴파일러가 명시적으로 이 함수를 사용하도록 한다.
        이를 해결하는 것은 복사 생성자를 virtual 로 할당하고 이러한 일을 컴파일러에게 위임시키는 방법이다.
• C++0x . . . . 2 matches
       == 지원되는 컴파일러 ==
       예전에 지원되는 컴파일러를 정리해둔 표가 있었던 것 같으나 어디있는지는 모르겠음
• Java Study2003/첫번째과제/노수민 . . . . 2 matches
       자바는 서로 다른 이종(Heterogeneous)의 네트워크 환경에서 분산 되어 실행될 수 있도록 설계되었습니다. 이와 같은 환경에서는 응용 프로그램들이 다양한 하드웨어 아키텍쳐 위에서 실행될 수 있어야만 합니다. 이를 위해 자바 컴파일러는 이종의 하드웨어 및 소프트웨어 플랫폼에서 효율적으로 코드를 전송하기 위해 설계된 아키텍쳐 중립적인 중간 코드인 바이트코드를 생성합니다. 이는 동일한 자바 프로그램의 자바 바이트코드가 자바 가상머신이 설치되어 있는 어떤 플랫폼에서도 실행될 수 있도록 하는 것입니다. 또한, 자바는 기본 언어 정의를 엄격하게 함으로써 효율적인 이식성을 제공해 주고 있습니다. 예를 들어, int 형과 같은 기본 데이터형의 크기를 플랫폼과 무관하게 일정하게 하고, 연산자의 기능을 확실하게 규정하고 있습니다. C 언어를 이용하여 int 형을 선언할 때, 도스에서는 16비트, 윈도우 95/98/NT 등 32비트 운영 체제 환경에서는 32비트, 유닉스에서는 32비트 등 그 플랫폼에 따라 크기가 다르지만, 자바에서는 플랫폼에 상관없이 32비트로 고정되도록 하였습니다. 이는 자바 프로그램이 실행되는 환경이 자바 가상머신으로 동일하기 때문입니다.
        * 자바 Applat 에서 - 자바 Bytescode는 소스를 자바 컴파일러로 컴파일한 결과물로서 HTML 문서에 비해 크기가 매우 크며 웹 서버에서 브라우저로 전송되기까지가 많은 시간이 걸린다. 일단 전송된 애플릿은 브라우저가 수행시키므로 그 속도는 클라이언트의 시스템 환경과 브라우저가 내장하고 있는 JVM의 성능에 따라 좌우된다. 28.8K 정도의 모뎀 환경이라면 그럴듯한 애플릿을 다운 받아서 수행하는데는 많은 인내심이 필요하게 된다. 그러나, 점차 인터넷 통신 환경이 좋아지고 있으며 가정집을 제외한 대부분의 사무실과 학교 등에서는 전용 회선이 깔려 있고, 넉넉한 환경의 전용선이라면 애플릿을 구동하는데 무리가 없다. 근래에는 가정에서도 초고속 통신 환경을 싼 값에 구축할 수 있으므로 점차적으로 인터넷 환경에서 애플릿의 전송은 부담이 되지 않을 것이다. JVM도 기술적으로 많이 향상되었고, Sun뿐 아니라, IBM과 같은 매머드급 회사들이 뛰어들어 개발하고 있어 초기 지적받았던 JVM의 구동 속도는 점차 문제가 되지 않는 상황이다.
• TestFirstProgramming . . . . 2 matches
       어떻게 보면 질답법과도 같다. 프로그래머는 일단 자신이 만들려고 하는 부분에 대해 질문을 내리고, TestCase를 먼저 만들어 냄으로서 의도를 표현한다. 이렇게 UnitTest Code를 먼저 만듬으로서 UnitTest FrameWork와 컴파일러에게 내가 본래 만들고자 하는 기능과 현재 만들어지고 있는 코드가 하는일이 일치하는지에 대해 어느정도 디버깅될 정보를 등록해놓는다. 이로서 컴파일러는 언어의 문법에러 검증뿐만 아니라 알고리즘 자체에 대한 디버깅기능을 어느정도 수행해주게 된다.
• ToastOS . . . . 2 matches
       볼랜드 C++ 3.0 컴파일러[[BR]]
       음..우선 전에 플로피 1번 섹터에서 부트섹트를 읽어 들여 부트 로더를 만든다고 까지 얘기한 것 같다.그럼 커널로더는 무엇일까? 부트 로더가 할 수 없는 기이한 일들을 커널 로더가 한다. 우선 보호모드로들어가는 것과 커널을 실행가능한 상태로 재배치 시키는 일등을 한다. 왜 그런 일을 할까? 부트로더가512kb밖이 되지 않아 그런 일들을 할 수 없기 때문이다. 위에 사진에서 보면 퍼런 글씨로 kernel loader라고나오는데 전에 CAU Operating System 어쩌구...가 먼저 나온다..다만 VMWARE를 쓰기때문에 그런 글씨가 안나온다. 여하튼 커널 로더가 가지는 의미는 우선 부트로더를 만들기 위해 어쩔수 없이 썼던 짜증나는 어셈을 이제 안써도 된다...ㅋㅋ 사실 어셈은 계속 써야 된다... 다만 이제 어쎔을 주로 쓰지 않고 C에서 인라인 어쎔을 쓸것이다. 이제 Boland C 3.1 버전의 컴파일러로 커널로더와 커널을 제작하게 될 것이다. 그럼 위와 같은 것을 그냥 해주면 되는거 아니냐? 라고 반문하는 사람이 있을 것이다.. 그렇다. 그냥 해주면 된다. 우선 컴파일할때 -S라는 옵션을 두어서 어셈블리 소스를 만들고 나서 그리고 그렇게 만들어진소스의 extern들을 링크 시키고 그런 다음 EXE파일을 실행가능한 재배치상태로 만들고 나서 부트로더와 같이뒤집어 씌우면 된다.
• VonNeumannAirport/1002 . . . . 2 matches
       컴파일러가 인자 2개짜리 Interface 이기를 요청한다. 요청대로 해주자.
       이 인터페이스도 수정하길 컴파일러가 바라고 있다. 원하는대로 해주자.
• 대학원준비06 . . . . 2 matches
        * 7/15 1시 칠피. 컴파일러 : 7,8,9 할 예정
       컴파일러 : 최적화
• 문자반대출력 . . . . 2 matches
        * C 에도 라이브러리로 문자열 반전 시켜주는 함수를 제공합니다. strrev()라는 함수를 사용하면 '\0'바로 전 글자부터 거꾸로 만들어주죠. 물론 ANSI 표준은 아니고 Semantec, Borland, Microsoft 에서 제공하는 컴파일러의 경우에 자체 라이브러리로 제공합니다. 이식성을 생각하지 않는 일반적인 코딩에서는 위에 나열한 컴파일러를 이용한다면 사용할 수 있습니다. - 도현
• 새싹교실/2011/AmazingC . . . . 2 matches
        * 컴파일러, 링커, 전처리기, 디버깅 등의 프로그래밍의 기본적인 요소에 대해 알아보았다.
        * printf함수를 사용하여 문자열을 출력하는 방법에 대해 알아보았고 컴파일러가 main 함수를 분석하는 모습을 따라서 전체 코드를 분석했다.
• 새싹교실/2012/AClass/1회차 . . . . 2 matches
        전처리 과정 : 컴파일러가 프로그램을 처리하기전에 특별한 일을 수행해주는 과정
        - 컴파일러가 프로그램을 번역하기 전에 소스프로그램을 처리하는 과정
• 새싹교실/2012/주먹밥 . . . . 2 matches
        * 포인터 : 포인터변수는 32bit 버전 컴파일러에서 4byte 64bit 버전 컴파일러에서 8byte의 크기를 가집니다. 어떤타입이든 말이죠 (void *), (int *), (float *) 모두 말이에요. int *a는 4byte를 할당받고 a에는 '''주소값(address)'''을 가지게 됩니다. 포인터 (*)를 붙이게 되면 그 해당 주소가 가르키는 '''값'''을 찾아가게 되죠. int형 값말이에요 그러니까 4byte만 찾아오겠죠?
• 새싹교실/2012/해보자 . . . . 2 matches
        * 함수의 선언: 컴파일러에게 '이런 이런 함수를 쓸것이다'라고 알리는 것.
        * 함수의 정의: 컴파일러에게 '이런 이런 함수는 이런 이런 일을 한다'라고 알리는 것.
• 서지혜 . . . . 2 matches
        1. 컴파일러 스터디: [NewCompileError]
        1. 컴파일러 스터디: [NewCompileError]
• 이영호/64bit컴퓨터와그에따른공부방향 . . . . 2 matches
       (우선 제 지문의 맥락을 담은 질문부터. 과연 Java와 Python 개발자들이 Assembly+C개발자와 같이 좋은 효율의 다른언어 컴파일러를 만들 수 있을까요. 현재 함수보다 좋은 함수를 생각해 냈는데 그것을 구현하려면 low level의 지식이 필요한데, 자신은 Java와 Python 들만 알고 Assembly를 모른다면 어떻게 해야할까요?)
       P.S: 천문학과 컴퓨터로 치면, 망원경은 컴파일러가 되겠고, Assembly어는 물리학 쯤이 되겠네요. 천문학 및 천체물리학 개론에는 망원경 단원이 1단원 분량으로 망원경 제작법 이런 것들이 아닌(망원경 제작은 아마추어 별바라기들이 하죠.) 물리학의 광학적 특성에 대해 다루죠 :) 예를 조금 잘못 드신거 같네요. 아니면 제가 위에서 제가 여러번 반박한 글들에 제 의도가 제대로 나타나지 않았던가요.
• 정모/2012.3.12 . . . . 2 matches
        * 전시회 홍보, 동아리 방 설명에 이어서 OMS가 상당히 인상 깊었던 정모였습니다. 제목만 보고도 그 주제를 고르신 이유를 바로 알았습니다. 전체적으로 Type, Type Safety, Java Generics에 대해서 상당히 깊이 다루지 않았나 싶네요. 사실 제네릭스 모양이 C++의 템플릿과 비슷하게 생겨서 같은 것이라고 생각하고 있었는데 이건 확실히 '만들어진 이유가 다르다'고 할 만 하군요. 그리고 마지막에 이야기했던 Type Erasure는 제네릭스를 구현할 때 JVM 레벨에서 구현하지 않고 컴파일러 부분에서 처리를 하도록 했기 때문에 타입이 지워지는 거라는 얘기를 들었는데 맞는지 모르겠군요. 이거 때문에 제네릭스 마음에 안 들어하는 사람들도 있는 모양이던데. 중간에 이 부분에 대한 개선이 이루어지고 있다는 말씀을 잠깐 하셨는데 컴파일 이후에도 타입 정보가 사라지지 않도록 스펙을 수정하고 있는 건가요? 좀 궁금하군요. 여담이지만 이번에 꽤 인상깊게 들었던 부분은 예상외로 Data Type에 대한 부분이었습니다. 이걸 제가 1학년 여름방학 때 C++ 스터디를 한다고 수경 선배한테 들은 기억이 지금도 나는데, 그 때는 Type이 가능한 연산을 정의한다는 말이 무슨 뜻인지 이해를 못 했었죠 -_-;;; 이 부분은 아마 새내기들을 대상으로 새싹을 할 때 말해줘야 할 필요가 있지 않을까 싶습니다. 아마 당장은 이해하지 못 하겠지만. 후후 - [서민관]
        * 아... Generics쪽의 개선이었군요 ;;; 타입 추론을 넣는 건가요. 컴파일러단에서 타입을 다 체크했으니 추측해서 넣을 수도 있다는 얘기였나... 그럼 타입 추론은 javac에서 이루어지는 건가요? 그렇다면 C++의 auto 키워드랑 같은 방식으로 작동한다는 얘기인가? 아마 힌들리-밀너 뭔가 하는 걸로 타입을 추측하는 것 같던데 쓰기는 좀 더 편해지겠네요. - [서민관]
• 프로그래밍십계명 . . . . 2 matches
        *컴파일러의 경고는 모두 켜 두어라. 경고는 곧 오류이니라. 오류를 알리는 함수의 결과를 확인하지 않는 우를 범하지 말지어다. 모든 파일 입출력과 모든 메모리 할당은 조만간 실패할 것이라.
        *어떠한 것을 수정했을 때에 연관된 것이 따라서 변하지 않는다면 그것이 곧 벌레이니라. 컴파일러로 하여금 매개 변수 리스트를 완전하게 검사하도록 하고, 언젠가 손대야 하거나 따라서 변해야 하는 수치는 전부 매크로로 치환하며, 형 정의를 적극 활용하여라.
• 0PlayerProject/커널업로드작업정리 . . . . 1 match
        * 크로스 컴파일러 안에 들어있는 것을 사용함.
• ACM_ICPC/2011년스터디 . . . . 1 match
        * 하면 할수록 입출력에 대한 감각이 어느 정도 살아나는 것 같습니다. 처음 접했을 때보단 생소하게 느껴지진 않네요. 처음에는 무슨 삽질을 했길래 그랬을까... 숏코딩을 처음으로 한번 해봤는데 역시 컴파일러에 대한 깊은 이해와 고도의 수학적 사고력이 요구되는듯 싶습니다. 졸리점퍼 71B는 도데체 어떤 코드일지... 처음에는 관심없었는데 해보니까 승부욕이 생깁니다.. 그것보다 해시함수나 B트리 등 심층적으로 다뤄보지 못한 알고리즘에 대한 의욕도 있지만.. 음!! 하고 싶은게 너무나 많네요. -[정진경]
• ATmega163 . . . . 1 match
        * AVR-GCC는 AVR에서 Cross Compile을 위해 만든 공짜 컴파일러
• AVG-GCC . . . . 1 match
        -dumpversion Display the version of the compiler'''컴파일러 버전'''[[BR]]
• AcceleratedC++/Chapter0 . . . . 1 match
        C++의 모든 문장(statement)은 계산 가능한 식이다. 컴파일러에서 에러를 찾을때도 계산 가능한 식인지 확인하여 문장이 올바른 문장인지 에러는 없는지 확인하게 된다. 예를 들어 다음과 같은 두 문장이 있다고 하자.
• AcceleratedC++/Chapter12 . . . . 1 match
       만약 생성자가 하나라도 존재하면 컴파일러는 암시적 기본 생성자를 만들지 않는다. 따라서 아무런 인자를 받지 않는 기본 생성자를 만들 필요가 있다.
• AcceleratedC++/Chapter5 . . . . 1 match
        * 여태껏 잘쓰던 벡터형 변수[n]은 벡터의 n번째 요소를 말한다. 지금까지 하던거 보면 루프 안에서 ++i 이거밖에 없다. 즉 순차적으로만 놀았다는 뜻이다. 우리는 알지만 컴파일러는 알길이 없다. 여기서 반복자(Iterators)라는 것을 알아보자.
• AcceleratedC++/Chapter6 . . . . 1 match
        1. grade함수는 오버라이딩된 함수이므로 컴파일러가 전달인자를 파악하지 못함
• AcceleratedC++/Chapter7 . . . . 1 match
        '''''주의) STL을 이용하면서 많이 범하는 실수: > > (0) >>(X) 컴파일러는 >>에 대해서 operator>>()를 기대한다.'''''
• Boost . . . . 1 match
        * [http://boost.org/status/cs-win32.html 컴파일러 테스트] 페이지를 보면 알 수 있듯이 가장 많은 테스트를 통과하는 것은 gcc. VC++ 6 은 테스트도 안한다.
• BoostLibrary . . . . 1 match
        * [http://boost.org/status/cs-win32.html 컴파일러 테스트] 페이지를 보면 알 수 있듯이 가장 많은 테스트를 통과하는 것은 gcc. VC++ 6 은 테스트도 안한다.
• C++스터디_2005여름/도서관리프로그램 . . . . 1 match
        └처음부터 전부를 만들려고 할 필요 없어용~^^ 음..대게 이경우에는 자료구조 정하고 하나씩 차근차근 테스트 해나가면서 만들면 될것 같아요. 안된다고 포기하면 미오.ㅠ.ㅜ ㅎㅎ 그리고 컴파일러가 머리가 나쁜관계로 대게 46개라도 실제 에러는 그 반수도 안된다는~ 힘내보아요~'ㅇ')/ - [조현태]
• C/Assembly . . . . 1 match
       (C언어의 특징이라고 하였지만, 번역하는 컴파일러의 특징이라고 해야 옳다.)
• C99표준에추가된C언어의엄청좋은기능 . . . . 1 match
        * 알아본 결과 C99에서 지원되는 것으로 표준이 맞으며, 단지 VS의 컴파일러가 C99를 완전히 만족시키지 않기 때문이라고함. gcc도 3.0 이후버전부터 지원된 기능으로 variable-length array 이라고 부르는군요. (gcc는 C99발표이전부터 extension 의 형태로 지원을 하기는 했다고 합니다.) - [eternalbleu]
• CNight2011/고한종 . . . . 1 match
       배열이 근본적으로 포인터란 것은 이미 알고 있었으나 실제 컴파일러에서 이런식으로 표현 된다는 것을 배웠다.
• CPPStudy_2005_1 . . . . 1 match
        [http://msdn.microsoft.com/visualc/vctoolkit2003/ VSC++ Toolkit] .net 을 구입할 수 없는 상태에서 STL을 컴파일 해야할 때 사용하면 되는 컴파일러. (공개)
• CollectiveOwnership . . . . 1 match
       일단 리팩토링을 필요로 하는 부분을 한정하고, 그 주위에 테스트 프로그램을 조금씩 붙여 나가야 한다. 그리고 리팩토링을 한다. 간혹 컴파일러를 테스트 프로그램으로 여기는 약간은 위험한 방법도 있다. see also Wiki:RefactoringLegacyCode
• C언어정복/3월30일 . . . . 1 match
       2. 컴퓨터 언어와 컴파일러 (인터프리터도 같이)
• DPSCChapter1 . . . . 1 match
        * 응용 프로그램 영역(보험, 쌍방향 통신, 등등.) 과 시스템 개발(윈도우즈 시스템, 컴파일러, 등등.)의 많은 새로운 예제들을 다룬다.
• DataStructure/Tree . . . . 1 match
        * PreOrder : Root -> Left Child -> Right Child : 컴파일러가 가장 좋아하는 방식
• EffectiveSTL/Container . . . . 1 match
        * 아직까지도 STL을 완벽하게 지원하는 컴파일러는 존재하지 않는다.
• FocusOnFundamentals . . . . 1 match
       세상에는 참 다양한 사람이 있습니다. 귀납식의 공부를 해야 잘되는 사람, 연역식의 공부를 해야 잘되는 사람.. 자바를 죽도록 공부했더니 OOP의 근본만을 후벼판 사람보다 더 OOP를 잘 꿰는 사람도 있을 수 있습니다. RDB가 아닌 오라클만이 RDB의 전부라고 생각하는 사람이 오히려 더 빨리 RDB의 근본을 깨칠 수도 있습니다. 컴파일러학문이 나오고 포트란 언어가 나온 것은 아닙니다. 어느 하나의 방법만이 옳다고 생각하지는 않습니다. 그리고 그 어떤 것도 잡다하지는 않다고 생각합니다. 사람마다 너무나 다양한 개성이 있겠지요. --["아무개"]
• Garbage collector for C and C++ . . . . 1 match
       A* a1 = new A[ 10 ]; // collectable or uncollectable? (컴파일러마다 다른 결과가 나온다.)
• GarbageCollection . . . . 1 match
       2번째의 것의 경우에는 자료구조 시간에 들은 바로는 전체 메모리 영역을 2개의 영역으로 구분(used, unused). 메모리를 할당하는 개념이 아니라 unused 영역에서 빌려오고, 사용이 끝나면 다시 unused 영역으로 돌려주는 식으로 만든다고함. ㅡㅡ;; 내가 생각하기에는 이건 OS(or VM), 나 컴파일러 수준(혹은 allocation 관련 라이브러리 수준)에서 지원하지 않으면 안되는 것 같음. 정확하게 아시는 분은 덧붙임좀..;;;
• Gof/Composite . . . . 1 match
       RTL Smalltalk 컴파일러 프레임워크 [JML92] 는 CompositePattern을 널리 사용한다. RTLExpression 은 parse tree를 위한 Component 클래스이다. RTLExpression 은 BinaryExpression 과 같은 서브클래스를 가지는데, 이는 RTLExpression 객체들을 자식으로 포함한다. 이 클래스들은 parse tree를 위해 composite 구조를 정의한다. RegisterTransfer 는 프로그램의 Single Static Assignment(SSA) 형태의 중간물을 위한 Component 클래스이다. RegisterTransfer 의 Leaf 서브클래스들은 다음과 같은 다른 형태의 static assignment 를 정의한다.
• HardcoreCppStudy/첫숙제/ValueVsReference/변준원 . . . . 1 match
       다르다면 컴파일러 장애가 발생할 것입니다. 다른 점이 있다면 함수 원형은 마지막에 세미콜론으로 끝난다
• IntegratedDevelopmentEnvironment . . . . 1 match
       IDE는 Integrated Development Environment를 말하며 한국어로는 통합 개발 환경을 의미한다. 보통 텍스트 편집기에 syntax highlite와 debugger, 빌드 도구, 컴파일러 등이 모두 통합되어 나오며 IDE하나만으로도 소스코드를 작성하는데 문제가 없다.[* 최근에는 이마저도 부족한 경우도 있다.]
• Java Study2003/첫번째과제/곽세환 . . . . 1 match
       자바는 서로 다른 이종(Heterogeneous)의 네트워크 환경에서 분산 되어 실행될 수 있도록 설계되었습니다. 이와 같은 환경에서는 응용 프로그램들이 다양한 하드웨어 아키텍쳐 위에서 실행될 수 있어야만 합니다. 이를 위해 자바 컴파일러는 이종의 하드웨어 및 소프트웨어 플랫폼에서 효율적으로 코드를 전송하기 위해 설계된 아키텍쳐 중립적인 중간 코드인 바이트코드를 생성합니다. 이는 동일한 자바 프로그램의 자바 바이트코드가 자바 가상머신이 설치되어 있는 어떤 플랫폼에서도 실행될 수 있도록 하는 것입니다. 또한, 자바는 기본 언어 정의를 엄격하게 함으로써 효율적인 이식성을 제공해 주고 있습니다. 예를 들어, int 형과 같은 기본 데이터형의 크기를 플랫폼과 무관하게 일정하게 하고, 연산자의 기능을 확실하게 규정하고 있습니다. C 언어를 이용하여 int 형을 선언할 때, 도스에서는 16비트, 윈도우 95/98/NT 등 32비트 운영 체제 환경에서는 32비트, 유닉스에서는 32비트 등 그 플랫폼에 따라 크기가 다르지만, 자바에서는 플랫폼에 상관없이 32비트로 고정되도록 하였습니다. 이는 자바 프로그램이 실행되는 환경이 자바 가상머신으로 동일하기 때문입니다.
• Java/문서/참조 . . . . 1 match
       (final이란 그냥 #define이라고 생각해도 무방하다. Java 컴파일러가 해당 final들을
• JavaStudy2004/자바따라잡기 . . . . 1 match
        *1. 최근의 컴퓨터 분야의 용례에서, 가상머신은 자바 언어 및 그 실행 환경의 개발자인 썬 마이크로시스템즈에 의해 사용된 용어이며, 컴파일된 자바 바이너리 코드와, 실제로 프로그램의 명령어를 실행하는 마이크로프로세서(또는 하드웨어 플랫폼) 간에 인터페이스 역할을 담당하는 소프트웨어를 가리킨다. 자바 가상머신이 일단 한 플랫폼에 제공되면, 바이트코드라고 불리는 어떠한 자바 프로그램도 그 플랫폼에서 실행될 수 있다. 자바는, 응용프로그램들이 각각의 플랫폼에 맞게 재작성 되거나, 다시 컴파일하지 않아도 모든 플랫폼에서 실행되는 것을 허용하도록 설계되었다. 자바 가상머신이 이를 가능하게 한다. 자바 가상머신의 규격은 실제 "머신"(프로세서)이 아닌 추상적인 머신을 정의하고, 명령어 집합, 레지스터들의 집합, 스택, 가배지를 모은 heap, 그리고 메쏘드 영역 등을 지정한다. 이러한 추상적, 혹은 논리적으로 정의된 프로세서의 실제 구현은, 실제 프로세서에 의해 인식되는 다른 코드, 혹은 마이크로프로세서 그 자체에 내장될 수도 있다. 자바 소스 프로그램을 컴파일한 결과를 바이트코드라고 부른다. 자바 가상머신은, 실제 마이크로프로세서의 명령어에 그것을 대응시키면서 한번에 한 명령어씩 바이트코드를 해석하거나, 또는 그 바이트코드는 실제 마이크로프로세서에 맞게 JIT 컴파일러라고 불리는 것을 이용해 나중에 컴파일될 수도 있다.
• KAIST전산대학원면접/06전기 . . . . 1 match
       "컴파일러 들었으면 ---최적화 기법이라고 들어봤나?"
• LexAndYacc . . . . 1 match
        * 솔직히 결정적인 이유야 -_- 컴파일러를 짜보기 위해서죠 :)
• Linux/디렉토리용도 . . . . 1 match
       lib 디렉토리에는 컴파일러를 통해서 혹은 만들어진 파일들이 잠조하는 라이브러리들이 존재한다. 또한 하부에 modules 디렉토리에 존재하는 커널 모듈은 특수장치를 설치했거나 제거했을 경우 커널이 자동적으로 모듈을 올리지 못할 경우 insmod, rmmod, modprobe 명령어를 통해서 이런 모듈을 다룰때 이용된다. 커널 모듈의 경우 2.4커널에서는 *.o, 2.6 커널에서는 *.ko의 확장자를 가지고 있다.
• NumericalAnalysisClass . . . . 1 match
       전산학에서 OOP의 발전을 별로 수용하지 않은 대표적인 두 영역이 컴파일러와 수치해석 쪽이다. 또한, 대부분의 수치해석 교과서들은 잡다한 기법과 코드의 백과사전 수준에서 그치고 있다.
• ObjectProgrammingInC . . . . 1 match
       별 다른 뜻은 아니고, C++ 컴파일러의 경우 메소드인 경우 인자로서 this 를 자동으로 넘겨준다고 해서. 그리고, attrib 이 private 이 아닌 public 이라 하더라도, 똑같은 질문이 가능할듯. --[1002]
• PowerOfCryptography/이영호 . . . . 1 match
       // 개략 적인 코딩으로 컴파일러가 없어 에러를 잡지 못했음.
• ReleaseDebugBuildStartGo의관계 . . . . 1 match
        - 실수로 초기화하지 않고 쓰는 지역변수가 있는가?(요즘 나오는 대부분의 좋은 컴파일러는 경고 메시지를 내주긴 합니다만)
• STL/vector/CookBook . . . . 1 match
        * 원인은 그거다. 정적 배열은 컴파일 시에 크기를 잡는다. 입력받는 부분은 컴파일 끝나고 실행할때 크기를 입력받는다. 컴파일러는 당연히 크기를 알수 없으니 에러가 나게된다. 고쳐 보자.
• STLPort . . . . 1 match
        1. MSVC 컴파일러의 자질구레한 경고 메시지를 막을 수 있다 ({{{~cpp _msvc_warnings_off.h}}}가 준비되어 있음)
• SoftwareEngineeringClass . . . . 1 match
        * 지금 듣는 사람들의 이야기를 들어서는 실습을 하는 과정이 투자하는 시간에 비해서 얻는 것이 좀 적은 것 같다는 생각들을 많이하던데... 실제로 팀을 이룬 사람들중에서 실무를 확실하게 경험해 보지 않은 사람들만 있는 경우에는 이게 더 심하다고 합니다. 전 내년에나 이거 들을 차례가 올것 같은데... 이경환 교수님께서도 이번을 마지막으로 하신다고 하고... 이 과목을 반드시 들어야하나 그런 생각도 좀 드네요. 저의 경우에는 이걸 청강(or 도강;;)식으로해서 이론적인 것을 듣고, 그냥 DB, PL을 들으려고하는데.. 어떨지 모르겠네요. (그런데 컴파일러 과목은 언제 생기는 거지 ㅡㅡ;;) - 박영창
• TestDrivenDevelopment . . . . 1 match
       테스트를 작성할때엔 '이미 완성되어있는 잘 된 API' 를 상상하며 작성한다. 잘 만들어진 API는 같은 일을 하더라도 직접 호출해줘야 하는 함수의 갯수가 적고 이해하기 편하며 '무엇'을 해주는지 그 메소드가 말해준다. 적게 코드를 써도 많은 일을 해주는것이다. 그리고, 테스트로서 컴퓨터의 컴파일러에게 코드작성을 위해 해야 할 일들을 묻고, 인터페이스를 만들고. 그리고 구현하고, 다시 구현된 코드를 Refactoring 한다.
• WOWAddOn/2011년프로젝트/초성퀴즈 . . . . 1 match
       Eclipse에서 Java외의 다른것을 돌리려면 당연 인터프리터나 컴파일러를 설치해주어야 한다. 그래서 Lua를 설치하려했다. LuaProfiler나 LuaInterpreter를 설치해야한다는데 도통 영어를 못읽겠다 나의 무식함이 들어났다.
• [Lovely]boy^_^/Diary/7/8_14 . . . . 1 match
        * 쓰는 법 다 잊어먹었다.;; 닷넷 컴파일러로 바뀌니까 막 헷갈린다. 그런의미에서 간단한 테트리스나 만들어 보기로 했다.
• bitblt로 투명배경 구현하기 . . . . 1 match
       프로그램을 컴파일해주는 컴파일러도 아니요..
• zennith/MemoryHierarchy . . . . 1 match
       요즈음의 RISC 구조 프로세서에서는, 모든 연산의 연산자들로 레지스터만 허용하므로, 이 제한된 숫자의 레지스터들을 어떻게 관리하느냐가 성능 향상의 주안점이다. 가령, 빈번하게 요구되는 변수는 계속 가지고 있는다던지, 아니면 한동안 쓰임이 없는 변수를 레지스터에서 버린다던지 하는 일이다. 물론, 이 일(optimal register allocation)은 컴파일러에서 담당한다.
• 경시대회준비반/BigInteger . . . . 1 match
       C++ 용 BigInteger 클래스로 거의 모든 연산을 지원한다. UVA 사이트의 구식(?) 컴파일러에도 문제없이 통과할 뿐 아니라, 성능또한 훌륭하다. 고정도 정수 연산을 하는 문제의 경우, 고정도 연산을 하는 라이브러리를 본인이 직접 짜거나, 이 클래스를 이용하면 된다. 몇 일동안 삽질한 결과 후자가 낫다는 판단이 선다. 되게 잘 짜여진 코드다. 시간 내서 분석해봐야 겠다.
• 고한종/배열을이용한구구단과제 . . . . 1 match
        * 우연히 들어와서 봤는데 fflush()는 output stream에 사용하도록 만들어진 함수고, fflush(stdin)은 MS의 컴파일러에서만 지원하는 거라서 linux쪽에서는 작동하지 않는다고 하니까 그것도 알아두는 것이 좋지 싶어요. - [서민관]
• 데블스캠프2010/넷째날/후기 . . . . 1 match
        * 자바스크립트라는말을 많이 들어봐서 뭔가 했는데 이제야 어떤건지 조금은 알았네요. 자바와 자바스크립트가 다른거라는것도 오늘알았고 자바스크립트가 C언어와 이렇게 비슷한걸 보니까 언어 하나를 배우면 다른건 쉽게 배운다고하는말이 뭔지 알것같습니다. 그리고 역시나 감동의 쓰나미였다 또 C언어처럼 컴파일러 같은게 필요한것도 아니고 코딩한 파일을 웹브라우저로 실행하기만 하면 결과가 나온다는것도 신기하네요 - [경세준]
• 데블스캠프2010/셋째날/후기 . . . . 1 match
        * 예전에 디어셈블러보고 잔뜩 쫄았었는데... 근데 역시 어렵군요 허허 -_- ㅋㅋ 디컴파일러를 깔았다면 더 신기했을텐데 아쉽네요 ㅎㅎ 무튼 신기했습니다!! -[김상호]
• 데블스캠프2010/회의록 . . . . 1 match
        * 컴파일러의 차이를 고려하지 못해 수업 준비가 덜 됨.
• 데블스캠프2012/다섯째날/후기 . . . . 1 match
        * [권순의] - C++의 개념을 C에서 어떻게 적용하는지, 컴파일러가 어떻게 돌아가는지에 대해서 생각해 볼 수 있는 시간이었습니다. 재미지네요. 단계적으로 나아가는 방법이 재미있었습니다. 설명도 자세하게 해 주시고 유익한 시간이었습니다. 그러다 보니 왜 우리가 어떤 것을 사용했을 때 느리다던지 한 것에 대해서 보다 쉽게 이해할 수 있는 시간이 아니었나 합니다.
• 데블스캠프2012/둘째날/후기 . . . . 1 match
        * [정진경] - 입학 하기 전에 산 컴퓨터에 CentOS를 깔고 제일 먼저 해봤던게 웹서버 구축이었던 것 같네요. 윈도우즈 환경에서도 어렵지 않게 구축할 수 있네요. (물론 지금의 시점에서지만,) 개인 서버를 구축하고 응용할 수 있으면 나름 장점이 있는 것 같습니다. 활용하기 나름이지만, 최근 Online Judge System에 VC++ 컴파일러를 올리고 싶어서 윈도우즈 서버도 생각하고 있는데, 추후에 도움이 될지도 모르겠네요.
• 사랑방 . . . . 1 match
        감사합니다.. zero-width positive lookahead assertion이 있었네요. (컴파일러시간에 배웠던거 다 잊어버렸어요 T_T).
• 새싹교실/2012/ABC반 . . . . 1 match
       라는 구문이 없으면 컴파일러는 함수의 구현이 없기 때문에 에러를 띄울 것이다.
• 새싹교실/2012/AClass . . . . 1 match
        * 1.컴파일러란?
• 새싹교실/2012/AClass/4회차 . . . . 1 match
       - c언어에서는 char,int,float 와 같은 많은 수의 기본 데이터 형과 배열, 포인터, 구조체 등의 유도된 데이터형으로부터 새로운 데이터형을 만들 수 있는데, 사용자 측면에서 새로운 데이터 형을 정의 할 수 있도록 typedef선언을 제공한다. typedef은 #define과 달리 이미 존재하는 c언어의 데이터 형만을 취하여 정의하고 typedef은 프리프로세서에 의해 처리되는 것이 아니라 c컴파일러에 의해 처리된다. 또한 #define보다 다양한 형태의 치환이 가능하다.
• 새싹교실/2012/startLine . . . . 1 match
        * 컴파일러가 하는 일.
• 새싹교실/2012/부부동반 . . . . 1 match
       * 컴파일러의 도움없이 스스로 메모리와 포인터의 관계를 통해 완벽한 코드 구현
• 새싹교실/2012/아우토반/앞반/3.22 . . . . 1 match
       컴파일러란?
• 소수구하기 . . . . 1 match
       '''문제정의 1'''의 50000이하 소수를 구하는 소스중 남훈이의 소스에서 제곱근 연산을 넣고, 모든 인자를 static, 컴파일러 옵션을 최대로해서 돌렸다. 출력은 필요 없으므로, 시간과 갯수만 출력한다. (Duron 800 MS VS.NET 2003)
• 실습 . . . . 1 match
       2. 컴파일러 세팅 (Compiler Setting)
• 이승한/질문 . . . . 1 match
       아마 승한이가 원하는 답은 아니겠지만 한번 적어본다. 지금 함수에 전달하는 것은 인트형의 포인터이기 때문에 함수는 지금 받은 것이 숫자인지 배열인지 알 수 가 없지. 게다가 주소를 참조하게 되서 함수 안에서 그 값을 변경해주면 원본 값도 변하게 되고. 그래서 나는 함수 안에 멤버 변수를 만들어서 전달 값을 복사해서 쓰거든. 보통 전달인수를 받을 때 컴파일러에서 그 원본 값을 쓰지 않고 복사값을 사용하는 건 알지? 그 작업을 프로그래머가 해주는 것이지. 밑은 여태 말한대로 구현하고 간단하게 테스트한 소스야.
• 이영호/끄적끄적 . . . . 1 match
       컴파일러도 없어서 메모장에서 작업하고...
• 이영호/미니프로젝트#1 . . . . 1 match
       나중에 아랫부분만 컴파일 해보자. 컴파일러가 없다! 에러가 나올지 모른다.
• 임베디드방향과가능성/정보 . . . . 1 match
       (소수의 천재들... 프로그래밍 제네레이터 --... 저걸 만들려고 아이디어를 가지고 있었는데 같은 생각을 하는 사람이 있었네... -_- 컴파일러 이론은 너무 어렵지만... 가장 먼저 만들 수 있을까...)
• 정모/2012.12.10 . . . . 1 match
        * 인간 컴파일러
• 큐와 스택/문원명 . . . . 1 match
        // 각 Pointer들은 의미 없는 값들로 채워져 있습니다.(컴파일러 의존)
• 후각발달특별세미나 . . . . 1 match
       그런데, 함수 호출에 의한 오버헤드는 컴파일러/VM 기술이 발전하면서 점점 줄어들고 있고, 문제가 복잡할수록 그런 낮은 단계의 옵티마이제이션보다 높은 단계에서의 최적화가 훨씬 더 효과적인데, 리팩토링이 잘 되어 함수가 잘게 쪼개어져 있으면 높은 단계의 최적화를 하기가 쉬워집니다. (그래도 여전히 로우레벨의 옵티마이제이션이 필요하다면 매크로나 코드 제너레이션을 쓸 수 있습니다. DavidParnas의 [http://www.acm.org/classics/may96/ 논문] 참고)

Found 121 matching pages out of 7555 total pages (5000 pages are searched)

You can also click here to search title.