추가로 operator new[]를 직접 구현하게 된다면 원시 메모리의 덩어리를 할당하는 작업만 해야한다.
operator delete의 구현 관례는 매우매우 단순하다. 널 포인터에 대한 delete 적용이 안전하다는 보장만 지켜주면 된다.
틀린 메모리 크기에 대한 우회를 구현했다면 delete에서도 동일하게 처리해주면 된다.
마지막으로 가상 소멸자가 없는 파생 클래스의 객체를 삭제하려는 경우, operator delete의 매개변수인 size_t의 이상할 수도 있다.
◾ 관례적으로, operator new 함수는 메모리 할당을 반복해서 시도하는 무한 루프를 가져야 하고, 메모리 할당 요구를 만족시킬 수 없을 때 new 처리자를 호출해야 하며, 0바이트에 대한 대책도 있어야 합니다. 클래스 전용 버전은 자신이 할당하기로 예정된 크기보다 더 큰(틀린) 메모리 블록에 대한 요구도 처리해야 합니다.
◾ operator delete 함수는 널 포인터가 들어왔을 때 아무 일도 하지 않아야 합니다. 클래스 전용 버전의 경우에는 예정 크기보다 더 큰 블록을 처리해야 합니다.
52. 위치지정 new를 작성한다면 위치지정 delete도 같이 준비하자
new 표현식을 쓰게되면 우선 operator new 호출로 메모리가 할당되고 이후 생성자가 호출되는 구조를 가지게 되어있다.
두개의 함수가 호출되는 것이다.
Widget *pw = new Widget;
만약 operator new 호출로 메모리 할당에는 성공했지만 생성자 호출 도중에 예외가 발생하면 할당된 메모리를 취소시켜야 한다. 하지만 생성자에서 예외가 발생했기 때문에 pw에 포인터가 대입되는 일은 생기지 않는다.
메모리는 할당되었지만 포인터를 돌려받지 못했기 때문에 사용자 입장에서는 해당 메모리에 접근할 방법이 아예 없다.
그래서 런타임 시스템이 할당된 메모리를 대신 반환해준다.
이 때 런타임 시스템은 호출된 operator new와 짝이 되는 operator delete를 호출하게 되는데, 이건 사용자가 준비해두어야 한다.
하지만 템플릿과 일반화 프로그래밍에서는 암시적 인터페이스와 컴파일 타임 다형성이 핵심이다.
명시적 인터페이스는 대개 함수 시그니처로 이루어진다. 함수의 이름, 매개변수 타입, 반환 타입 등등이다.
반면 암시적 인터페이스는 유효 표현식으로 이루어진다.
template<typename T>
void doProcessing(T& w) {
if (w.size() > 10 && w != someNastyWidget) ..
}
이런 경우 타입 T에서 제공될 암시적 인터페이스에는 size와 operator!=를 지원해야 하는 제약이 걸린다.
size 멤버 함수를 지원해야 하는 것은 맞지만 반드시 수치 타입을 반환할 필요까지는 없다. 그저 어떤 X 타입의 객체와 int가 함께 호출될 수 있는 operator>가 성립될 수 있도록 X타입의 객체만 반환하면 된다.
operator!=의 경우 타입의 암시적 변환이 가능하다면 유효 호출로 간주된다.
표현식에 걸리는 제약은 복잡해 보이지만 일반적으로는 평이한 편이다.
예를 들어 위와 같은 조건식인 경우에 size, operator>, operator&&, operator!= 함수에 대한 제약을 일일이 집어내려면 난감하지만, 결과적으로 if문의 조건식 부분은 boolean 표현식이어야 하기 때문에 표현식에서 쓰이는 것들이 정확히 어떤 값을 내놓던지 간에 bool과 호환되면 된다.
이 제약이 암시적 인터페이스의 일부이다.
if (w.size() > 10 && w != someNastyWidget) ...
// w.size()는 반드시 int size(void)일 필요는 없다
// X size(void)가 되더라도 X객체가 operator>를 지원하기만 하면 된다
결과적으로 조건식이 성립하기만 하면 명시적 인터페이스가 아니라도 괜찮은 것이다.
템플릿 안에서 어떤 객체를 쓰려고 할 때, 암시적 인터페이스를 그 객체가 지원하지 않으면 컴파일 오류가 발생한다.
◾ 클래스 및 템플릿은 모두 인터페이스와 다형성을 지원합니다.
◾ 클래스의 경우, 인터페이스는 명시적이며 함수의 시그니처를 중심으로 구성되어 있습니다.
◾ 템플릿 매개변수의 경우, 인터페이스는 암시적이며 유효 표현식에 기반을 두어 구성됩니다. 다형성은 컴파일 중에 템플릿 인스턴스화와 함수 오버로딩 모호성 해결을 통해 나타납니다.
42. typename의 두 가지 의미를 제대로 파악하자
템플릿의 타입 매개변수를 선언할 때 class와 typename은 뜻이 완전히 똑같다.
하지만 typename에는 한가지 의미가 더 있다. (추가: 모던 C++에서는 차이가 아예 없는것 같다)
template<typename T>
void print(const T& container) {
if (container.size() >= 2) {
T::const_iterator iter(container.begin());
// 만약 T::const_iterator가 타입이 아니라 그냥 정적 멤버라면?
++iter;
int value = *iter;
std::cout << value;
}
}
위와 같이 const_iterator가 T에 의존하는 중첩 의존 타입 이름(종속적 형식 이름)이라면 모호성이 발생할 가능성이 생긴다.
T::const_iterator는 반드시 타입이어야만 하는데 전역 변수이거나 정적 멤버일 가능성이 있기 때문이다.
template<typename T> // typename 쓸 수 있음
void f(const T& container, // typename 쓰면 안됨
typename T::iterator iter); // typename 꼭 써야함
template<typename T>
class Derived: public Base<T>::Nested { // 상속받는 기본 클래스는 typename 쓰면 안됨
public:
explicit Derived(int x) : Base<T>::Nested(x) { // 초기화 리스트의 기본 클래스는 typename 쓰면 안됨
typename Base<T>::Nested temp; // 중첩 의존 타입 이름이기 때문에 typename 반드시 필요
}
};
예외적으로 기본 클래스의 리스트에 있거나 멤버 초기화 리스트의 기본 클래스 식별자로 존재하는 경우는 붙여줘서는 안된다.
32. public 상속 모형은 반드시 "is-a(...는 ...의 일종이다)"를 따르도록 만들자
public 상속과 is-a 관계는 똑같은 뜻이다.
파생 클래스의 타입이 기본 클래스의 타입이 될 수는 있지만 반대는 성립할 수 없다.
public 상속을 받을수록 일반적인 개념에서 특수한 개념으로 점점 좁혀진다.
public 상속은 기본 클래스가 가진 모든 것들이 파생 클래스에도 그대로 적용된다고 단정하는 것이다.
◾ public 상속의 의미는 "is-a(...는 ...의 일종)"입니다. 기본 클래스에 적용되는 모든 것들이 파생 클래스에 그대로 적용되어야 합니다. 왜냐하면 모든 파생 클래스 객체는 기본 클래스 객체의 일종이기 떄문입니다.
33. 상속된 이름을 숨기는 일은 피하자
유효범위에 관련된 내용이다.
class Base {
private:
int x;
public:
virtual void mf1() = 0;
virtual void mf2();
void mf3();
};
class Derived: public Base {
public:
virtual void mf1();
void mf4();
}
위와 같은 코드의 경우 데이터 멤버와 함수의 유효 범위는 그림과 같다.
만약 Derived의 mf4에서 mf2를 호출하게 된다면 컴파일러는 mf2 함수의 선언문이 들어있는 유효 범위를 탐색한다.
바로 Base::mf2에 접근하는 것이 아니라, 안에서부터 바깥으로 탐색을 넓혀나간다.
탐색 순서
함수 오버로딩의 경우에도 이름이 가려진다.
class Base {
public:
virtual void mf1() = 0;
virtual void mf1(int);
void mf3();
void mf3(double);
};
class Derived: public Base {
public:
virtual void mf1();
void mf3();
void mf4();
};
Derived d;
int x;
d.mf1(); // Derived::mf1 호출
d.mf1(x); // error. Derived::mf1에 가려짐
d.mf3(); // Derived::mf3 호출
d.mf3(x); // error. Derived::mf3에 가려짐
가상 함수와 비가상 함수 여부나 매개변수 타입이 달라도 전혀 관련이 없이 이름이 가려진다.
애초에 public 상속을 쓰면서 오버로딩을 모두 상속받지 않으면 is-a 관계가 위반된다.
가려진 이름은 using 선언으로 꺼낼 수도 있다.
class Derived: public Base {
public:
using Base::mf1;
using Base::mf3;
};
파생 클래스 내부에서 가려지는 오버로드된 함수를 using 선언을 통해 Derived의 유효범위 안에서 볼 수 있게 만들어준다.
결과적으로 기본 클래스를 상속 받을 때, 오버로드된 함수의 일부만 재정의 하고 싶다면 using 선언을 붙여주어야 한다.
class Base
{
public:
virtual void mf1() { std::cout << "mf1()" << '\n'; }
virtual void mf1(int x) { std::cout << "mf1(x)" << '\n'; }
};
class Derived1 : private Base
{
public:
using Base::mf1;
};
class Derived2 : public Derived1 {};
int main(void)
{
Derived2 d;
d.mf1(10); // Derived1이 private 상속임에도 접근이 가능해진다
return 0;
}
만약 파생 클래스가 private 상속을 받고 일부만 재정의 한 뒤에 또 파생이 된다면 using 선언을 사용해선 안된다.해당되는 이름이 모두 파생 클래스로 내려가 버리기 때문이다.
class Derived1 : private Base
{
public:
virtual void mf1() { Base::mf1(); }
};
class Derived2 : public Derived1 {};
int main(void)
{
Derived2 d;
d.mf1(); // ok
d.mf1(10); // error
return 0;
}
이 때는 using 선언 대신 기본 클래스의 함수를 호출하는 전달 함수를 사용하면 된다.
◾ 파생 클래스의 이름은 기본 클래스의 이름을 가립니다. public 상속에서는 이런 이름 가림 현상은 바람직하지 않습니다.
◾ 가려진 이름을 다시 볼 수 있게 하는 방법으로, using 선언 혹은 전달 함수를 쓸 수 있습니다.
34. 인터페이스 상속과 구현 상속의 차이를 제대로 파악하고 구별하자
public 상속의 개념은 인터페이스 상속과 함수 구현 상속 두가지로 나뉜다.
class Shape {
public:
virtual void draw() const = 0;
virtual void error(const std::string& msg);
int objectID() const;
};
순수 가상 함수, 단순 가상 함수, 비가상 함수의 목적은 각기 다르다.
◾ 순수 가상 함수를 선언하는 목적은 파생 클래스에게 함수의 인터페이스만을 물려주려는 것이다.
인터페이스만 물려받았기 때문에 파생 클래스에서는 반드시 구현을 해야한다.
◾ 단순 가상 함수를 선언하는 목적은 파생 클래스에게 함수의 인터페이스뿐만 아니라 기본 구현도 물려주려는 것이다.
둘 다 물려받았기 때문에 필요에 따라 재정의를 해도 되고 안해도 된다. 다만 재정의를 해야 할 상황에서 잊어버리고 재정의를 하지 않았을 때, 의도치 않은 동작이 이루어지는 것을 주의해야한다.
class Airplane {
public:
virtual void fly(const Airport& destination);
};
class ModelA: public Airplane {
public:
virtual void fly(const Airport& destination);
};
class ModelB: public Airplane {
public:
virtual void fly(const Airport& destination);
};
class ModelC: public Airplane {}; // 재정의를 깜빡함
Airport PDX();
Airplane* pa = new ModelC;
pa->fly(PDX); // 하지만 동작함
이런 문제는 가상 함수의 인터페이스와 기본 구현을 잇는 연결 관계를 끊으면 조금은 해소할 수 있다.
class Airplane {
public:
virtual void fly(const Airport& destination) = 0;
protected:
void defaultFly(const Airport& destination); // 비가상함수. 재정의불가
};
class ModelA: public Airplane {
public:
virtual void fly(const Airport& destination) { defaultFly(destination); }
};
class ModelB: public Airplane {
public:
virtual void fly(const Airport& destination) { defaultFly(destination); }
};
class ModelC: public Airplane {}; // 재정의를 깜빡함
Airport PDX();
Airplane* pa = new ModelC;
pa->fly(PDX); // error
복붙같은 문제를 해결할 수는 없지만 인터페이스와 구현을 분리함으로써 조금은 나아진다.
혹은 기본 클래스의 순수 가상 함수를 구현함으로써 외견을 깔끔하게 할 수 있다.
defaultFly를 구현하고 호출하는 대신 Airplane::fly를 호출하면 된다. 설계는 거의 똑같다.
◾ 비가상 함수를 선언하는 목적은 파생 클래스에게 함수의 인터페이스뿐만 아니라 필수적인 구현도 물려주는 것이다.
가상 함수와는 다르게 재정의가 불가능하기 때문에 모든 파생 클래스에서 똑같이 작동한다.
◾ 인터페이스 상속은 구현 상속과 다릅니다. public 상속에서, 파생 클래스는 항상 기본 클래스의 인터페이스를 모두 물려받습니다.
◾ 순수 가상 함수는 인터페이스 상속만을 허용합니다.
◾ 단순(비순수) 가상 함수는 인터페이스 상속과 더불어 기본 구현의 상속도 가능하도록 지정합니다.
◾ 비가상 함수는 인터페이스 상속과 더불어 필수 구현의 상속도 가하도록 지정합니다.
35. 가상 함수 대신 쓸 것들도 생각해 두는 자세를 시시때때로 길러 두자
◾ 비가상 인터페이스 관용구를 통한 템플릿 메서드 패턴
public 비가상 함수를 호출하면 내부 동작은 private 가상 함수에 의해 일부분이 다르게 동작하게 설계한다.
class GameCharacter {
public:
int healthValue() const
{
...
int retVal = doHealthValue();
...
return retVal;
}
private:
virtual int doHealthValue() const { ... } // 파생 클래스 재정의 가능
};
가상 함수가 private으로 선언되어 있어도 재정의는 가능하다. 단, 자기 자신의 가상 함수만 접근할 수 있다.
파생 클래스는 구현만 할 뿐이고 실제 호출은 기본 클래스의 비가상 함수에서 이루어지기 때문에 재정의에 아무런 문제가 없다.
위와 같은 설계를 비가상 함수 인터페이스(NVI) 관용구라고 부른다. 템플릿 메서드라고도 한다.
◾ 함수 포인터로 구현한 전략 패턴
체력을 계산하는 작업이 굳이 캐릭터의 일부일 필요가 없어서 각 생성자에 체력을 계산하는 함수의 포인터를 넘겨주는 방식을 택할 수 있다.
class GameCharacter; // 전방 선언
int defaultHealthCalc(const GameCharacter& gc); // 체력 계산 기본 구현 함수
class GameCharacter {
public:
typedef int (*HealthCalcFunc)(const GameCharacter&);
explicit GameCharacter(HealthCalcFunc hcf = defaultHealthCalc) : healthFunc(hcf) {}
int healthValue() const { return healthFunc(*this); }
private:
HealthCalcFunc healthFunc;
};
class EvilBadGuy: public GameCharacter {
public:
explicit EvilBadGuy(HealthCalcFunc hcf = defaultHealthCalc) : GameCharacter(hcf) {}
};
int loseHealthQuickly(const GameCharacter&);
int lostHealthSlowly(const GameCharacter&);
EvilBadGuy ebg1(loseHealthQuickly);
EvilBadGuy ebg2(loseHealthSlowly); // 동일한 객체이지만 함수를 다르게 설정 가능
가상 함수 대신 함수 포인터로 대체되었다.
템플릿 메서드 패턴과 크게 다른 점이 있는데, 템플릿 메서드는 타입이 같은 객체라면 체력 계산 알고리즘이 동일하지만 함수 포인터는 타입이 같은 객체라도 다른 함수를 사용하거나 타입이 다른 객체라도 같은 함수를 사용할 수 있게 된다.
그대신 클래스 외부로 빠져나왔기 때문에 public 멤버를 제외한 데이터에 접근이 불가능해진다.
위와 같은 개념을 디자인 패턴화 시킨 것이 전략(Strategy)패턴이다.
추후 체력 계산 알고리즘이 변경되어도 클래스에서 변하는 것은 아무것도 없다.
◾ tr1::function으로 구현한 전략 패턴
함수 대신 함수 객체를 사용한다. (참고: VC에서는 tr1 이름 공간이 더이상 사용되지 않음. 그냥 std::function이다.)
함수 포인터와 다른점은 대상 시그니처와 호환되는 함수호출성 개체를 어떤 것도 가질 수 있게된다. (암시적 변환)
특정 객체의 멤버 함수를 사용할 수도 있다. (std::bind 이용 시)
using GameCharacter;
typedef std::function<int(const GameCharacter&)> HealthCalcFunc;
// using HealthCalcFunc = std::function<int(const GameCharacter&)>; 둘 다 똑같다
class GameLevel {
public:
float health(const GameCharacter&) const;
};
...
EvilBadGuy ebg1(calcHealth); // 함수 사용
EyeCandycharacter ecc1(HealthCalculator()); // 함수 객체 사용
GameLevel currentLevel;
EvilBadGuy ebg2(std::bind(&GameLevel::health, currentLevel, _1)); // 멤버 함수 사용
_1은 std::placeholder이다. 매개 변수를 자유롭게 받겠다는 의미이다.
◾ "고전적인" 전략 패턴
함수 포인터나 함수 객체가 아니라 체력 계산 함수를 나타내는 클래스를 따로 만들고 실제 계산하는 함수를 가상 함수로 만드는 것이다.
class GameCharacter;
class HealthCalcFunc {
public:
virtual int calc(const GameCharacter& gc) const { ... }
};
HealthCalcFunc defaultHealthCalc;
class GameCharacter {
public:
explicit GameCharacter(HealthCalcFunc *phcf = &defaultHealthCalc) : pHealthCalc(phcf) {}
int healthValue() const { return pHealthCalc->calc(*this); }
private:
HealthCalcFunc* pHealthCalc;
};
기존의 함수 포인터나 함수 객체와 구조가 크게 다르지는 않다. 그저 표준적인 전략 패턴일 뿐이다.
요약
◾ 비가상 인터페이스 관용구(NVI 관용구)를 사용한다
공개되지 않은 가상 함수를 비가상 public 멤버 함수로 감싸서 호출하는, 템플릿 메서드 패턴의 한 형태이다.
◾ 가상 함수를 함수 포인터 데이터 멤버로 대체한다
전력 패턴의 핵심만을 보여주는 형태이다.
◾ 가상 함수를 함수 객체 데이터 멤버로 대체한다
호환성을 높인다. 전략 패턴의 한 형태이다.
◾ 한쪽 클래스 계통에 속해 있는 가상 함수를 다른 쪽 계통에 속해 있는 가상 함수로 대체한다
전략 패턴의 전통적인 구현 형태이다.
◾ 가상 함수 대신에 쓸 수 있는 다른 방법으로 NVI 관용구 및 전략 패턴을 들 수 있습니다. 이 중 NVI 관용구는 그 자체가 템플릿 메서드 패턴의 한 예입니다.
◾ 객체에 필요한 기능을 멤버 함수로부터 클래스 외부의 비멤버 함수로 옮기면, 그 비멤버 함수는 그 클래스의 public 멤버가 아닌 것들을 접근할 수 없다는 단점이 생깁니다.
◾ tr1::function 객체는 일반화된 함수 포인터처럼 동작합니다. 이 객체는 주어진 대상 시그니처와 호환되는 모든 함수호출성 개체를 지원합니다.
36. 상속받은 비가상 함수를 파생 클래스에서 재정의하는 것은 절대 금물!
가상 함수는 동적 바인딩으로 묶이지만 비가상 함수는 정적 바인딩으로 묶이기 때문에 재정의를 한다면 의도치 않은 동작을 하게된다.
그것보다는 앞서 언급했듯이 비가상 함수를 상속받으면 불변성이 보장되어야 하는데 재정의를 하는 순간 불변성이 깨져버린다.
◾ 상속받은 비가상 함수를 재정의하는 일은 절대로 하지 맙시다.
37. 어떤 함수에 대해서도 상속받은 기본 매개변수 값은 절대로 재정의하지 말자
가상 함수가 동적으로 바인딩 된다 하더라도 기본 매개변수 값은 정적으로 바인딩 된다.
◾ 상속받은 기본 매개변수 값은 절대로 재정의해서는 안 됩니다. 왜냐하면 기본 매개변수 값은 정적으로 바인딩되는 반면, 가상 함수는 동적으로 바인딩되기 때문입니다.
38. "has-a(...는...를 가짐)" 혹은 "is-implemented-in-terms-of(...는...를 써서 구현됨)"를 모형화할 때는 객체 합성을 사용하자
컴포지션은 객체 안에 객체가 포함되는 경우를 얘기한다.
is-a 관계와 has-a 관계는 헷갈일 일이 거의 없지만 is-a 관계와 is-implemented-in-terms-of 관계는 헷갈릴 수 있다.
예를 들어서 list를 이용해 set를 구현한다고 했을 때, is-a 관계는 기본 클래스에서 참인 것들이 파생 클래스에서도 모두 참이어야 하지만 list는 중복 원소를 가질 수 있으므로 is-a 관계가 성립하지 않는다.
대신 list 객체를 사용해서 구현하는 형태(is-implemented-in-terms-of)를 가질 수 있다.
template<typename T>
class Set: public std::list<T> { ... }; // is-a 관계가 성립하지 않음
template<class T>
class Set {
public:
bool member(const T& item) const;
...
private:
std::list<T> rep;
}
template<typename T>
bool Set<T>::member(const T& item) const
{
return std::find(rep.begin(), rep.end(), item) != rep.end(); // list를 사용한 구현
}
◾ 객체 합성의 의미는 public 상속이 가진 의미와 완전히 다릅니다.
◾ 응용 영역에서 객체 합성의 의미는 has-a(...는...를 가짐)입니다. 구현 영역에서는 is-implemented-in-terms-of(...는 ...를 써서 구현됨)의 의미를 갖습니다.
39. private 상속은 심사숙고해서 구사하자
클래스 사이의 상속 관계가 private이라면 파생 클래스 객체를 기본 클래스 객체로 변환하지 않는다. (업캐스팅X)
class Person {};
class Student : private Person {};
void eat(const Person& p) {}
Person p;
Student s;
eat(p);
eat(s); // error
또한 상속이 private으로 이루어지면 기본 클래스에서 멤버들의 접근 지정자가 어떻게 되었던 간에 파생 클래스에서 전부 private 멤버가 되어버린다.
결론적으로 private 상속의 의미는 is-implemented-in-terms-of이다. private 상속 자체로 구현 기법 중 하나가 된다.
기본 클래스를 private으로 상속하는것은 기능 몇 개를 활용할 목적이 있는것이지 어떤 개념적 관계가 있어서 하는 행동이 아니다. 구현만 물려받을 뿐 인터페이스는 일절 제공하지 않는다.
앞서 컴포지션은 has-a 또는 is-implemented-in-terms-of 둘 중 하나라고 언급했었다.
컴포지션이 이미 존재하는데 private 상속은 언제 사용해야 하는걸까?
답은 가능하면 컴포지션을 사용하고 객체의 비공개 멤버에 접근하거나 가상 함수를 재정의 할 필요가 있을때 private 상속을 사용하면 된다.
다만 파생은 가능하게 하되 파생 클래스에서 재정의를 막거나 컴파일 의존성을 최소화하고 싶을 때 컴포지션이 더 좋기때문에 컴포지션이 더 자주 쓰인다.
◾ private 상속의 의미는 is-implemented-in-terms-of입니다. 대개 객체 합성과 비교해서 쓰이는 분야가 많지는 않지만, 파생 클래스 쪽에서 기본 클래스의 protected 멤버에 접근해야 할 경우 혹은 상속받은 가상 함수를 재정의해야 할 경우에는 private 상속이 나름대로 의미가 있습니다.
◾ 객체 합성과 달리, private 상속은 공백 기본 클래스 최적화(EBO)를 활성화시킬 수 있습니다. 이 점은 객체 크기를 가지고 고민하는 라이브러리 개발자에게 꽤 매력적인 특징이 되기도 합니다.
40. 다중 상속은 심사숙고해서 사용하자
다중 상속은 똑같은 이름을 물려받을 가능성이 생긴다.
만약 다중 상속으로 인해 기본 클래스와 파생 클래스 사이의 경로가 두 개 이상이 된다면 데이터 멤버를 중복 생성하거나 가상 상속을 통해 해결해야 한다.
정확한 동작의 관점에서 보면 public 상속은 항상 가상 상속이어야 맞지만 성능상의 이유로 무조건 사용할 수는 없다.
때문에 쓸 필요가 없다면 가상 기본 클래스를 쓰지 말아야 한다. 만약 반드시 써야할 상황이라면 가상 기본 클래스에는 데이터를 넣지 않도록 각별히 신경써야 한다. 초기화 규칙에서 자유로워지기 때문이다.
가능하면 단일 상속을 사용하려고 하되, 정말 필요하다고 확신이 들면 다중 상속을 사용하도록 한다.
◾ 다중 상속은 단일 상속보다 확실히 복잡합니다. 새로운 모호성 문제를 일으킬 뿐만 아니라 가상 상속이 필요해질 수도 있습니다.
◾ 가상 상속을 쓰면 크기 비용, 속도 비용이 늘어나며, 초기화 및 대입 연산의 복잡도가 커집니다. 따라서 가상 기본 클래스에는 데이터를 두지 않는 것이 현실적으로 가장 실용적입니다.
◾ 다중 상속을 적법하게 쓸 수 있는 경우가 있습니다. 여러 시나리오 중 하나는, 인터페이스 클래스로부터 public 상속을 시킴과 동시에 구현을 돕는 클래스로부터 private 상속을 시키는 것입니다.
C 스타일의 구형 캐스트보다는 C++ 스타일의 캐스트를 사용하는 것이 바람직하다. 가독성도 좋아지고 사용 범위를 좁히기 때문에 컴파일러 쪽에서 오류를 확인할 수 있다.
class Window {
public:
virtual void onResize() { ... }
};
class SpecialWindow : public Window {
public:
virtual void onResize() {
static_cast<Window>(*this).onResize(); // Window의 복사 생성자가 호출된다
}
};
SpecialWindow sw;
sw.onResize();
캐스팅을 통한 형 변환 시, 임시 객체가 생성되어서 *this가 아닌 임시 객체의 onResize를 호출하게 된다.
static_cast<Window>(*this).onResize(); // X
Window::onResize(); // O
기본 클래스의 멤버 함수를 호출하고 싶다면 캐스팅이 아니라 직접 호출하도록 한다.
dynamic_cast는 다운 캐스팅을 안전하게 할 수 있지만 사용 비용이 높다.
파생 클래스들을 컨테이너에 담아서 접근할때마다 dynamic_cast를 하는것은 바람직하지 않다.
우회 방법으로 파생 클래스의 스마트 포인터만을 담을 수 있는 컨테이너를 만들거나 파생 클래스에 존재하는 함수를 기본 클래스에 가상 함수로 정의하는 것이다.
// 전자
typedef std::vector<std::shared_ptr<SpecialWindow>> VPSW; // 파생 클래스 스마트 포인터를 담는 vector
VPSW winPtrs;
for (VPSW::iterator iter = winPtrs.begin(); iter != winPtrs.end(); ++iter) {
(*iter)->blink(); // 캐스팅이 필요 없다
}
/* */
// 후자
class Window {
public:
virtual void blink() {}
};
typedef std::vector<std::shared_ptr<Window>> VPW; // 기본 클래스 스마트 포인터를 담는 vector
VPW winPtrs;
for (VPW::iterator iter = winPtrs.begin(); iter != winPtrs.end(); ++iter) {
(*iter)->blink(); // 가상 함수로 구현되어있기 때문에 가능
}
전자는 파생 클래스 갯수만큼 컨테이너 여러개를 만들어야 할 것이고 후자는 파생 클래스에서 해당 함수를 사용하지 않더라도 기본 클래스의 함수가 호출이 된다.
if (dynamic_cast<SpecialWindow1*>(iter->get()) { ... }
else if (dynamic_cast<SpecialWindow2*>(iter->get()) { ... }
else if (dynamic_cast<SpecialWindow3*>(iter->get()) { ... }
그렇다고 이딴 식으로(폭포식) 설계하는것은 절대로 해서는 안된다.
속도도 느릴뿐더러 파생 클래스가 추가될 때마다 유지보수가 어려워진다.
◾ 다른 방법이 가능하다면 캐스팅은 피하십시오. 특히 수행 성능에 민감한 코드에서 dynamic_cast는 몇 번이고 다시 생각하십시오. 설계 중에 캐스팅이 필요해졌다면, 캐스팅을 쓰지 않는 다른 방법을 시도해 보십시오.
◾ 캐스팅이 어쩔 수 없이 필요하다면, 함수 안에 숨길 수 있도록 해 보십시오. 이렇게 하면 최소한 사용자는 자신의 코드에 캐스팅을 넣지 않고 이 함수를 호출할 수 있게 됩니다.
◾ 구형 스타일의 캐스트를 쓰려거든 C++ 스타일의 캐스트를 선호하십시오. 발견하기도 쉽고, 설계자가 어떤 역할을 의도했는지가 더 자세하게 드러납니다.
28. 내부에서 사용하는 객체에 대한 '핸들'을 반환하는 코드는 되도록 피하자
class Point {
public:
void setX(int newVal);
void setY(int newVal);
};
struct RectData {
Point ulhc;
Point lrhc;
};
class Rectangle {
public:
Point& upperLeft() const { return pData->ulhc; }
Point& lowerRight() const { return pData->lrhc; }
private:
std::shared_ptr<RectData> pData;
};
upperLeft와 lowerRight는 상수 멤버 함수이고 사각형의 꼭짓점 정보를 알아낼 수 있는 방법만 제공하는 것이 목적이다.
뮤텍스와 같은 자원은 앞서 말했던대로 객체로 관리하는 것이 좋다. 따로 신경쓰지 않아도 함수를 벗어날 때 알아서 해제해주기 때문이다. 자원이 새지 않기 때문에 첫 번째 요구사항을 만족하게 된다.
두 번째 요구사항인 자료구조 오염 방지는 우선 예외 안전성을 갖춘 함수가 필요하다.
예외 안전성을 갖춘 함수는 아래의 세 가지 보장중 한 가지를 제공한다.
◾ 기본적인 보장
예외 발생 시, 실행 중인 프로그램에 관련된 모든 것들을 유효한 상태로 유지하겠다는 보장. 하지만 프로그램의 상태를 정확히 예측하기 어렵다.
◾ 강력한 보장
예외 발생 시, 프로그램 상태를 절대로 변경하지 않겠다는 보장. (원자적 동작)
호출이 성공하면 의도한 대로 마무리까지 완벽하게 진행되고 예외 발생 시, 함수 호출 이전의 상태로 되돌아간다.
사용 편의성 측면에서 기본 보장을 제공하는 함수보다 예측 가능한 상태가 두 개밖에 안되기 때문에 더 쉽다.
◾ 예외불가 보장
무슨 일이 있어도 예외를 절대로 던지지 않겠다는 보장. 약속한 동작은 언제나 끝까지 완수한다는 의미이다.
아무 보장도 제공하지 않으면 예외에 안전한 함수가 아니다. 일반적으로 기본적인 보장과 강력한 보장 중 한가지를 선택한다.
class PrettyMenu {
...
std::shared_ptr<Image> bgImage;
};
void PrettyMenu::changeBackground(std::istream& imgSrc) {
Lock ml(&mutex);
bgImage.reset(new Image(imgSrc)); // 내부 포인터 교체
++imageChanges;
}
위와 같이 자원 관리 객체들을 이용해서 구현하는 경우, 다 좋지만 딱 하나의 옥의 티가 있다. reset이 호출되려면 Image가 생성되어야 하는데, Image의 생성자가 실행 도중 예외를 일으키면 입력 스트림의 읽기 표시자가 이동한 채로 남아 있을 가능성이 충분히 있고, 이것이 전체 프로그램에 영향을 미칠 가능성도 존재하게 된다.
복사 후 맞바꾸기를 통해 강력한 예외 안전성 보장을 좀 더 완성시킬 수 있다. pimpl 관용구를 사용한다.
struct PMImpl {
std::shared_ptr<Image> bgImage;
int imageChanges;
};
class PrettyMenu {
private:
Mutex mutex;
std::shared_ptr<PMImpl> pImpl;
};
void PrettyMenu::changeBackground(std::istream& imgSrc) {
using std::swap;
Lock ml(&mutex);
std::shared_ptr<PMImpl> pNew(new PMImpl(*pImpl)); // 객체 데이터 복사
pNew->bgImage.reset(new Image(imgSrc)); // 사본 수정
++pNew->imageChanges;
swap(pImpl, pNew); // 복사 후 맞바꾸기
}
그렇지만 이것도 함수 전체가 강력한 예외 안전성을 갖도록 보장할 수 없다.
함수 내부에서 또 다른 함수를 호출할 때, 그 함수가 강력한 예외 안전성을 보장하지 못하면 덩달아서 같이 강력한 예외 안전성을 보장하기 어려워진다. (side effect)
또한 효율적인 측면에서도 마냥 좋지는 않다. 복사 후 맞바꾸기는 수정할 객체를 복사해 둘 공간과 거기에 걸리는 시간을 감수해야 하기 때문이다.
실용성이 확보될 때만 강력한 보장을 제공하는데에 힘 쓰고, 기본적인 보장을 우선적으로 삼으면 된다.
언제나 예외에 안전한 코드를 만들지를 진지하게 고민하는 버릇을 들여야 한다.
정말 어쩔 수 없이 재래식 코드를 호출해서 예외 안전성의 보장이 무너질 경우, 반드시 문서로 남겨야 한다.
◾ 예외 안전성을갖춘 함수는 실행 중 예외가 발생되더라도 자우너을 누출시키지 않으며 자료구조를 더럽힌 채로 내버려 두지 않습니다. 이런 함수들이 제공할 수 있는 예외 안전성 보장은 기본적인 보장, 강력한 보장, 예외 금지 보장이 있습니다.
◾ 강력한 예외 안전성 보장은 '복사-후-맞바꾸기' 방법을 써서 구현할 수 있지만, 모든 함수에 대해 강력한 보장이 실용적인 것은 아닙니다.
◾ 어떤 함수가 제공하는 예외 안전성 보장의 강도는, 그 함수가 내부적으로 호출하는 함수들이 제공하는 가장 약한 보장을 넘지 않습니다.
30. 인라인 함수는 미주알고주알 따져서 이해해 두자
인라인 함수는 함수처럼 보이고 함수처럼 동작하지만 매크로보다 훨씬 안전하고 쓰기 좋다.
하지만 함수 본문을 바꿔치기 해주는 것 뿐이라서 인라인 함수를 남발하는 것은 목적 코드의 크기가 매우 커지기 때문에 메모리 사용에 있어서 그다지 좋지 않다.
가상 메모리를 쓰는 환경이라면 페이징 횟수도 늘어나고 캐시 적중률이 떨어질 가능성도 높아지기 때문에 성능저하가 일어날 수 있다.
인라인 함수는 대체적으로 헤더 파일에 들어 있어야 하는 게 맞다.
또한 인라인 함수는 컴파일러에게 요청하는 것이지 명령이 아니다. 복잡하거나 가상 함수인 경우 인라인 함수라고 명시적으로 선언되어 있어도 컴파일러가 묵살할 수 있다. 인라인 함수의 주소를 취하는 코드가 있는 경우에도 묵살된다.
inline void f() {...}
void (*pf)() = f;
f(); // 인라인 된다
pf(); // 인라인 되지 않는다
// f는 인라인, 아웃라인 함수 둘 다 존재하게 된다
덧붙여서 생성자와 소멸자는 인라인하기 좋지 않은 함수이다.
사실 인라인 함수는 이러저러한 이유보다 디버깅이 용이하지 않을 수 있다는 점 한가지가 크게 와닿는다.
어떤 함수가 인라인화 된다면 중단점도 안걸리고 호출 스택에 잡히지 않기 때문에 디버깅에 애로사항이 꽃필수 있다.
◾ 함수 인라인은 작고, 자주 호출되는 함수에 대해서만 하는 것으로 묶어둡시다. 이렇게 하면 디버깅 및 라이브러리의 바이너리 업그레이드가 용이해지고, 자칫 생길 수 있는 코드 부풀림 현상이 최소화되며, 프로그램의 속력이 더 빨라질 수 있는 여지가 최고로 많아집니다.
◾ 함수 템플릿이 대개 헤더 파일에 들어간다는 일반적인 부분만 생각해서 이들을 inline으로 선언하면 안 됩니다.
31. 파일 사이의 컴파일 의존성을 최대로 줄이자
헤더파일 안에서 헤더파일을 include 하는 경우 헤더파일 사이에 컴파일 의존성이 생기게 된다.
// A.h
#include <iostream>
class A {};
// B.h
#include "A.h"
// C.h
#include "B.h"
위와 같은 구조로 컴파일 의존성이 생기게 되면 A 헤더 파일의 아주 간단한 사항만 변경해도 B와 C 헤더 파일 역시 컴파일이 이루어져야 한다.
전방선언을 통해 인터페이스와 구현을 둘로 나누면 컴파일 의존성을 낮출 수 있다. 단, 표준 라이브러리는 전방선언 할 필요가 없다.
◾ 객체 참조자 및 포인터로 충분한 경우에는 객체를 직접 쓰지 않는다
어떤 타입의 포인터나 참조자를 정의할 때는 해당 타입의 선언부만 있으면 된다. 하지만 객체를 정의할 때는 정의가 준비되어 있어야 한다.
◾ 할 수 있으면 클래스 정의 대신 클래스 선언에 최대한 의존하도록 만든다
class Date; // 전방 선언
Data today();
void clearAppointmets(Date d);
◾ 선언부와 정의부에 대해 별도의 헤더 파일을 제공한다
class Date;
class Adress;
class PersonImpl;
class Person { // PersomImpl의 인터페이스
public:
Person() {}
Person(const std::string& name, const Date& birthday, const Address& addr);
std::string name() const;
std::string birthDate() const;
std;:string address() const;
private:
std::shared_ptr<PersonImpl> pImpl; // pimpl idiom
Person같이 pimpl 관용구를 사용하는 클래스를 핸들 클래스라고 한다.
구현(PersonImpl)과 핸들(Person)을 두개로 쪼개서 사용한다. 둘의 멤버 함수는 일대일로 대응되기 때문에 인터페이스는 동일하다.
Person을 핸들 클래스가 아닌 인터페이스 클래스로 만드는 방법도 있다. 추상 클래스로 만드는 것이다.
class Person { // 인터페이스 클래스
public:
virtual Person();
virtual ~Person();
virtual std::string name() const = 0;
...
static std::shared_ptr<Person> create(...); // 객체 생성 함수
};
std::shared_ptr<Person> pp(Person::create(...));
인터페이스 클래스를 사용하기 위해서는 객체 생성 수단이 최소한 하나는 있어야 하고 주로 정적 멤버 함수로 만들어서 사용한다.(팩토리 함수/가상 생성자)
◾ 컴파일 의존성을 최소화하는 작업의 배경이 되는 가장 기본적인 아이디어는 '정의' 대신에 '선언'에 의존하게 만들자는 것입니다. 이 아이디어에 기반한 두 가지 접근 방법은 핸들 클래스와 인터페이스 클래스입니다.
◾ 라이브러리 헤더는 그 자체로 모든 것을 갖추어야 하며 선언부만 갖고 있는 형태여야 합니다. 이 규칙은 템플릿이 쓰이거나 쓰이지 않거나 동일하게 적용합시다.
