구글 C++ 스타일 가이드 (feat. 전방선언)

https://jongwook.kim/google-styleguide/trunk/cppguide.xml

 

클래스 전방선언에 관해서 단점은 없나 찾아보던 도중 발견한 사이트.

 

참고로 보면 좋을 듯 하다

 

---

 

별개로 본래의 목적(...)이었던 전방선언에 관한 부분

 

장점:

• 불필요한 #include는 컴파일러가 더 많은 파일을 열고 더 많은 입력을 처리하도록 만든다.
• 불필요한 #include는 헤더 파일 변경 시 코드를 더 자주 다시 컴파일하도록 만든다.

 

단점:

• 템플릿, typedef, 디폴트 인자, using 선언과 같은 기능을 쓸 때 전방 선언의 정확한 형태를 결정하기 힘들 수 있다.
• 어떤 코드 조각에서는 전방 선언이 필요한지 전체 #include가 필요한지 결정하기 힘들 수 있다. 특히 암시적 변환이 개입될 때 그렇다. 극단적인 경우에는 #include를 전방 선언으로 대체하면 코드의 의미가 조용히 바뀔 수도 있다.
• 헤더에서 여러 기호를 전방 선언하는 것은 단순히 헤더를 #include하는 것보다 장황해질 수 있다.
• 호환성을 깨지 않고 헤더에서 할 수 있었던 변경들이 함수나 템플릿의 전방 선언 때문에 불가능해질 수 있다. 예를 들어 인자 타입을 더 넓은 타입으로 바꾼다거나, 디폴트 값이 있는 템플릿 인자를 추가하는 것 등이 그렇다.
• std:: 네임스페이스의 기호를 전방 선언하면 보통 예상할 수 없는 결과를 유발한다.
• 전방 선언이 가능하도록 코드를 구조화하는 일(예를 들어 객체 멤버 대신 포인터 멤버를 쓰는 일)은 코드를 더 느리고 더 복잡하게 만들 수 있다.
• 전방 선언으로 얻어지는 실질적인 성능 개선은 증명된 적이 없다.

 

결론:

• 헤더 파일에 선언된 함수를 사용할 때, 항상 그 헤더를 #include하라.
• 클래스 템플릿을 사용할 때, 헤더 파일을 #include 하는 것을 선호하라.
• 일반적인 클래스를 사용할 때 전방 선언에 의존하는 것은 괜찮으나 전방 선언이 불충분하거나 부정확한 경우를 조심하라. 고민되는 경우에는 그냥 적절한 헤더를 #include하라.
• 단순히 #include를 피하기 위해서 데이터 멤버를 포인터로 대체하지 말라.

 

항상 필요로 하는 선언 또는 정의를 실제로 제공하는 파일을 #include하라. 다른 헤더를 거쳐 간접적으로 가져온 기호에 의존하지 말라. 하나의 예외로 myfile.cc 파일은 그에 상응하는 myfile.h 헤더에 있는 #include와 전방 선언에 의존할 수 있다.