파트 1에서 불 필요한 헤더를 제거하고 수정했다면, 파트2[각주:1]에선 기본 하는 일을 제외하고, 컴파일 의존성을 좀 주려 보자.

예제 코드




분석
코드를 자세히 보면, public: protected: 영역 외에 private: 영역 때문에, C 클래스 헤더와 D 클래스 해더를 포함해야 하는 것으로 보인다.[각주:2]

그런 이유기이에 정의되는 데이터 영역을 하나의 구조체 포인터로 묶고[각주:3], 클래스 객체 생성시 동적메모리 할당으로 처리가 된다면, 클래스의 컴파일 의존성을 엄청나게 줄일 수 있게 된다.

이런 방법은 수 많은 사람들에게 사용[각주:4] 되어 오면서, 몇가지 주요한 장점과 단점을 지적되어 왔다.

코드


 이 코드는 다음과 같은 장점과 단점을 갖는다.

장점
  1. 클래스의 정의에서만 언급된 형들은 클라이언트를 위해서 더 이상 정의될 필요가 없어지며, #include를 제거 할 수 있고 컴파일 속도를 높일 수 있다.
  2. 클래스의 멤버 데이터들이 변경 될 경우, 재컴파일 하지 않아도, 자유롭게 변수 추가 및 제거가 될 수 있다.
  3. private: 영역을 더 잘 감출수 있게 되어 private: 개념과 정확히 맞아 떨어 진다.

단점

  1. 각 생성자 및 소멸자는 반드시 메모리 할당/제거 작업이 들어가야 한다.
  2. 완전히 숨겨진 영역에 접근하기 위하여, 별도의 인터페이스를 제공 해야만 한다.


그런데 유심히 잘 살펴보면, a.h 와 b.h 도 줄이고 싶을 것이다. 하지만, X가 A클래스와 B클래스를 상속하여 X의 용량이 결정 되어짐으로, .. (포워드)전방 선언으로는 처리 되질 못하기에, 그 정의 전부 보여야만 한다. 그래서 ... 건들수가 없다.


총평

개발 단계에선 Pimpl 을 사용 하고, 릴리즈 단계에선 실체를 가지는 방법을 많이 사용 한다고 한다. 아마도 최적화 단계에서 약간 변경될 가능성이 있기 때문이라고 본다. 사용해 본 결과 무척이나 컴파일 타임이 줄어 든것을 확인 할 수 있을 것이다. 나이스~



  1. 파트 1에선 소극적인 헤더 파일 제거라면, 파트 2에선 적극적인 헤더파일 제거이다. [본문으로]
  2. 클래스의 용량을 결정하지 않는 것은 그 정의 부분이 없어도 되기 때문이다. 즉, 매개변수 타입과 반환타입에만 쓴다면, 포워드(전방)선언 만 있어도 된다. [본문으로]
  3. class로 묶어도 상관 없다, 단지 그 객체를 포인터로 가리키게 해야 한다. [본문으로]
  4. 이 방법은 많이 사용 되어 왔고, 사람들은 Pimpl(핌플) 이라고 부른다. [본문으로]
  • 네이버 블러그 공유하기
  • 네이버 밴드에 공유하기
  • 페이스북 공유하기
  • 라이프코리아트위터 공유하기
  • shared
  • 카카오스토리 공유하기