IT's me

pimpl idiom

컴파일 의존성을 줄이기 위한 하나의 설계 기법이다.

많이 쓰여지는 기법 중 하니이기 때문에 거의 패턴으로 굳어져 있다.

include가 필요한 사용자 정의 타입의 멤버 변수들을

해당 멤버 변수들을 포함한 클래스(구조체)의 포인터로 대체하는 방법이다.

이런 형식의 문제점은 헤더파일 내에서 다른 헤더파일을

include하고 있다는 것이다. include를 하게 되면 전처리기는

해당 헤더의 내용을 그대로 복사해서 집어넣는다. 그렇다면

AAA.h를 include하는 모든 cpp 파일에 AAA.h가 include하는

모든 헤더가 포함되게 되므로 코드량이 매우 커진다.

따라서 컴파일 시간이 늘어난다.

또한 myString같은 유저 정의 클래스의 경우

내용이 바뀔 가능성이 매우 높다. myString의

내용이 바뀐다면 AAA.h는 물론 AAA.h를 포함하는

모든 파일도 다시 재컴파일 될 수 밖에 없다.

pimpl idiom을 통해 해결해보자.

include가 필요한 멤버 변수들을 모아 Aimpl 구조체에 저장하자.

그리고 그 구조체에 대한 포인터를 멤버 변수로 들고 있는다.

Aimpl 구조체 정의는 cpp 파일로 미룬다.

여기서 중요한 점은 cpp파일의 include는

오직 해당 cpp 파일에만 영향을 미친다는 것이다.

따라서 위의 코드는 헤더파일의 include를

구현파일로 모두 보내버렸다는 것이 포인트다.

한 걸음 더 나아가 tr1의 shared_ptr을 사용해서

구현을 한다면 더욱 좋은 설계가 될 것이다.

물론 AAA의 소멸자에서 delete연산을 해주지 않아도 된다.

구조체가 아닌 클래스로 pimpl을 구현해보자.

필요한 클래스를 전방 선언 후 Person 클래스 선언 내에서

참조자 혹은 포인터의 정의 그리고 값의 전달 및 반환

그야말로 인터페이스와 구현이 뼈와 살이 분리되듯 떨어진다.

이러한 방법은 pimpl idiom 외에도 인터페이스 클래스를

설계하는 방법도 생각해볼 수 있으나, 패턴으로 볼 수 없기 때문에

후에 C++ 카테고리에서 포스팅하도록 하겠다.

DFS 알고리즘 단지 번호 붙이기 (백준)

DFS 문제이다. 재귀를 사용해서 풀었다.

원래는 메인에서 재귀함수를 한번 호출하고

재귀 함수 내에서 모든 작업을 다 하는 방식으로

진행하려 했지만, 메인에서 반복문으로 재귀를 불러주니

문제가 상당히 쉬워졌다.. 그래도 여전히 25분

01. 초기화

02. 재귀 함수 호출 및 답 출력

DFS 알고리즘을 풀면서 비용적인 측면까지도

생각해볼 때 인 것 같다. 위의 문제는 메인에서

하나하나 호출을 하는게 상당히 비효율적으로 보인다.

하지만 테스트는 푸는 시간 또한 중요하기에

이러한 방법으로 계속 푸는 연습을 해야겠다.

DFS 알고리즘 경로찾기 (백준)

DFS 문제이다.

재귀를 사용해 풀었지만 시간초과..

때문에 답이 맞는지도 모르겠다.

적어도 예제는 다 맞았으니 올려본다.

다음엔 스택을 이용해 풀어보겠다.

예전 같은 경우 재귀를 이용해 DFS를 풀 때

재귀 함수 내에서 모든 것을 끝내려 했다.

사실 그게 큰 부담이 되었는데, 메인 함수에서

재귀를 여러번 불러주는 식으로 진행을 하니 한결 수월했다.

비용적인 측면에 대해서도 고민해볼 시기인 것 같다.

열공합시다!