Effective c++ 정리 chapter 4

EFFECTIVE C++ 정리
Chapter 4
설계 및 선언

잘쓰기는 쉽게
못쓰기는 어렵게
ITEM 18

Item 18: 잘쓰기 쉽게 못쓰기 어렵게
• 인터페이스
• 유저와 코드가 접하는 경로
• 잘쓰기는 쉽게 못쓰기는 어렵게 만들자
• 유저가 생각하는 대로 동작하게 하자.
• 잘못 쓴 경우 뭔가 항의의 몸부림을 치자.
• 사용자가 실수하는 경우를 머리에 두고 있자.

• 날짜 클래스의 생성자
Date( int month, int day, int year);
• 매개변수 순서를 잘못 입력한 경우
Data d(30, 3, 1995); //3, 30이 올바른 사용
• 가능한 범위를 넘어가는 경우
Data d(3, 40, 1995); //3월 40일은 없다.

• Day, Month, Year 각각 wrapper 타입을 만들자.
• struct Day {explicit Day(int day)…} //Month, Year 이하 동일
• Data (const Month& m, const Day& d, const Year& y);
• Date d(30, 3, 1995); //타입 체크 오류
• Data d(Day(30), Month(3), Year(1995)); //타입 체크 오류
• Data d(Month(3), Day(30), Year(1995); //올바른 사용

• 타입의 값에 제약을 가해보자.
• 유효한 Month는 12개 뿐
• Enum ? 타입 안전성이 불안해 (http://ozt88.tistory.com/15 참고)
• static 함수로 Month를 반환하는 방식을 사용하자. (item 4참고)
public:
static Month Jan(){return Month(1); … //Month를 만드는 유일한 창구
private:
explicit Month(int m); //생성자를 private해서 안전하게

• 또 다른 제약 붙이기 const (item 3 참조)
• operator*의 반환 타입을 const로 한정한 이유
• if( a * b = c )… //이런 실수를 막기 위해서
• 별다른 이유가 없다면 클래스는 기본 타입처럼 동작하게 하자
• 기존 int 역시 *연산에 다른 값을 대입할 수 없게 만들어져있음.
• 유사한 쓰임새의 기본타입의 동작을 모방하자
• 일관성 있는 인터페이스의 제공

• STL에서 나타나는 비일관성의 예
• 데이터의 길이 또는 크기를 나타낼 떄
• Array는 length 프로퍼티로
• String은 length 메서드로
• List는 size 메서드로
• 비 일관성은 인터페이스를 해친다.

• 사용자 쪽에서 뭔가 외워야 하는 인터페이스는 잘못 되었다.
• Investment* createInvestment(); //팩토리 함수 (in item 13)
• 사용자 측에서 delete하는 것을 잊어서는 안 된다.
• 사용자 측에서 별 고민 없이 그냥 사용할 수 있게
• std::shared_ptr<Investment> createInvestment(); //스마트포인터 반환
• 자동 해제되어 편하게 사용가능
• 사용자 실수를 원천 봉쇄 ( deleter도 설계자가 지정 가능 )

• 교차 DLL 문제
• 자원 할당된 포인터가 여기저기 돌아다니는 경우
• 객체 생성시에 특정 DLL에 있는 new를 사용
• 해제 시에는 다른 DLL에 있는 delete 를 사용
• tr1::std::shared_ptr은 그런 걱정 ㄴㄴ
• Shared_ptr은 자신의 deleter를 control block에서 관리하기 때문
• 훌륭한 인터페이스의 대표적 사례 (http://ozt88.tistory.com/28 참조)

클래스 설계는
타입을 설계하듯
ITEM 19

Item 19: 클래스 설계는 타입을 설계하듯
• 클래스를 설계할 때, 새로운 언어의 타입을 설계하듯
• 자연스러운 구문, 의미체계의 구축
• 직관적이며 동시에 효율적인 기능 구현
• 고려사항들 1
• 객체 생성 소멸 방식
• 객체 초기화와 대입연산의 차이
• 값 복사의 의미와 구문

• 타입의 domain 설정
• 값 제약
• Setter들에서 조건 체크
• 멤버 상속여부
• 상속 받았다면 어떤 멤버의 속성을 상속받아 사용할 것인가?
• 상속해 줄 것이라면 어떤 멤버를 가상으로 설정할 것인가?

• 타입 변환
• 어떤 타입들로 변환을 허락할 것인가
• 암시적 변환/ 명시적 변환
• 적당한 연산자와 멤버 함수 선정
• special function 중 어떤 것을 취사 선택하여 사용할 것인가?
• Private로 봉인 가능
• 멤버함수 접근 권한 설정 (public/private/protected)

• 선언되지 않은 인터페이스
• 보장할 자원, 성능, 예외 안정성
• 일반적 템플릿을 만들어야 하는가?
• 정말로 필요한 타입인가?
• 비슷한 클래스가 있고 기능이 몇 개 추가되지 않는다면
• 일반 비멤버 함수를 만들거나 템플릿을 몇 개 더 정의하는 게 낫다.

객체 전달은 const T&
ITEM 20

Item 20: 객체 전달은 const T&
• C++ 함수의 동작은 기본적으로 값에 의한 전달
• 일반 객체 paramete는 argumen에 대한 사본으로 생성
• 반환 값의 사본을 만들어 반환 객체를 받는다.
• 예제 코드 Person class와 그를 상속받는 Student Class

• class Person{
public:
Person();
virtual ~Person();
private:
std::string name;
std::string address;
};
• class Student : public Person{
public:
Student();
virtual ~Student();
private:
std::string schoolName;
std::string schoolAddress;
};

• Student를 인자로 전달받는 함수 validateStudent
bool validataStudent(Student s);
…
Student plato;
bool platoIsOK = validateStudent(plato);
• 객체 전달에 필요한 비용
• Parameter의 Student 복사 생성자 호출
• Argument의 Student 소멸자 호출

• 좀더 구체적인 비용
• Student 생성할 때 덩달아 불리는 생성자들
• 멤버변수 SchoolName 생성자, SchoolAddress 생성자 호출
• 상속받은 Person의 생성자 호출
• Person의 멤버변수 address, name 생성자 호출
• Student 해제할때 덩달아 호출되는 소멸자들
• 위에서 생성된 모든 객체들 각각 해제
• TOTAL : 생성자 6번, 소멸자 6번

• 비효율적인 값 전달의 대체제 const T&
• Reference-to-Const
• 어차피 값으로 전달하면, 기존 객체의 값이 바뀔 일이 없다는 의미
• 상수성이 유지되면 사본을 만드는 대신 상수 객체의 참조를 넘기는게 이득
• No 생성 No 소멸 No 복사
• bool validateStudent( const Student& s );
• 복사손실 문제를 해결
• 정적 타입이 부모 클래스인 경우, 부모클래스의 복사 생성자 호출로 데이터 손실
• Window 클래스와 그것을 상속받은 WindowWIthScrollBars 클래스 예제

• Class Window{
public:
…
std::string name() const;
virtual void display() const;
};
• Class WindowWithScrollBars
:public Window{
public:
…
virtual void display() const;
};

• 윈도우의 이름을 출력하고 윈도우를 화면에 출력하는 함수
• void printNameAndDisplay(window w)
• 여기에 WindowWithScrollBars 객체를 전달
• WindowWithScrollBars wwsb;
printNameAndDisplay(wwsb); //복사 손실발생!
• 여기에서도 해결책은 Reference-to-Const
• void printNameAndDisplay(const Window& w);
• 기존 매개변수의 참조만 사용하므로 데이터를 유지한 상태로 사용됨.

• const T&가 만능은 아니다.
• 참조자는 근본적으로는 포인터로 구현된다.
• 전달 타입이 기본(primitive)타입인 경우 값 전달이 효율적이다.
• STL의 반복자와 함수객체에서도 동일한 convention이 적용
• 반복자와 함수객체의 복사 생성자/할당자의 효율을 고려해야 한다.
• 복사 손실 문제를 해결해야 한다.

• 기본 타입이 아닌 값 전달의 위험성
(크기 작다고 값 복사 하지마)
• 객체 크기가 작아도 복사 비용이 적은 것은 아님
• 포인터 타입의 깊은 복사의 경우
• 사용자 정의 타입은 연산 자체가 다르다.
• Double 하나만 있는 객체와 Double을 다루는 방식이 다름
• 기본 double은 레지스터 하나로 처리, 하지만 객체는 다르다!
• 포인터/참조는 무조건 레지스터 하나에 들어감
• 사용자 정의 타입의 크기는 변화가능하다.

함수 반환에서
참조반환을 피하자
ITEM 21

Item 21: 함수 반환에서 참조 반환을 피하자.
• 참조 전달 만능주의에 빠지지 말자.
• 반환형이 참조일 때, 이미 소멸된 객체의 참조를 반환할 가능성
• Rational 클래스에서 friend 함수 operator*의 예시
class Rational {
…
friend
const Rational operator* (const Rational& lhs, const Rational& rhs);
}

• 곱셈 결과를 값으로 반환하는 것이 정당한가?
• 참조자를 반환하면 생성과 소멸에 드는 비용을 줄일 수 있다.
• 참조자는 alias 즉 이미 존재하는 객체에 대한 참조
• 참조로 반환하는 경우 반환된 객체가 따로 어딘가에 존재해야 한다!
• Rational을 참조로 반환하고 싶다면
• Operator*에서 Rational 객체를 따로 생성해야 한다.
• 힙에 할당하거나, 스택에 생성하거나, 또는 static(^^)

• 스택에 생성하는 경우
const Rational& operator* (const Rational& lhs,
const Rational& rhs)
{
Rational result(lhs.n * rhs.n, lhs.d * rhs.d); //반환값 스택에 생성
return result;
}
• 생성자 호출을 피하기위한 참조 반환이었지만 결국엔 생성해야한다.
• 반환된 참조의 대상은 함수 종료 후 소멸된다. (댕글링 참조자)

• 힙에 생성하는 경우
{
Rational* result = new Rational(lhs.n * rhs.n, lhs.d * rhs.d);
return *result;
}
• 여전히 생성자 호출의 비용은 그대로
• 할당한 메모리 해제를 어떻게 할 것인가?

• 힙에 생성한 객체의 참조반환
• Rational w, x, y, z;
w = x * y * z; //operator*(operator*(x, y), z);
• 사용자 측에서 반환되는 참조자의 포인터에 접근할 방법이 없다.
• 함수 내에서는 해제하면 안 된다. (댕글링 참조자 문제)
• delete는 어디서 누가 어떻게 왜!!?

• 마지막 발악. static으로 반환할 Rational을 정의한 경우
{
static Rational result(lhs.n * rhs.n, lhs.d * rhs.d);
return result;
}
• Rational a, b, c, d;
If( (a * b) == (c * d) ) … //반환값이 static에 대한 참조이므로 항상 true

• 가능하면 그냥 값 전달하자. 물론 정석은 있다.
inline const Rational operator* (const Rational& lhs,
{return Rational ( lhs.n * rhs.n, lhs.d * rhs.d );}
• inline 키워드를 사용하여 불필요한 생성/소멸자 호출 방지
• 컴파일러 최적화에 맡기자.

데이터 멤버들은
private에 선언하자
ITEM 22

Item 22: 데이터 멤버들은 private에 선언하자
• Public 데이터 멤버 무엇이 문제인가?
• 사용자의 문법적 일관성을 해친다.
• 어떤 멤버는 데이터고 어떤 멤버는 함수다?
• 사용자가 객체에 접근 가능한 방법이 모두 함수인 편이 일관성이 높다.
• 사용자의 데이터 접근을 제어할 수 없다.
• 데이터 멤버에 대해 자유로운 접근이 가능하다.
• Private하면 직접 함수로 접근 방식을 커스터마이징 할 수 있다.

• Public 데이터 멤버 무엇이 문제인가? 2
• 클래스의 온전한 캡슐화를 할 수 없다.
• 클래스 캡슐화의 좋은 예
class SpeedDataCollection {
public:
void addValue(int speed); //새로운 데이터 추가.
double averageSoFar() const; //평균 속도 반환
}

• SpeedDataCollection 예시
• averageSoFar() 함수 어떻게 구현할 것인가?
• 속도 평균값을 저장하는 데이터 멤버를 유지하고 그 값을 반환한다.
• 성능 향성 but 객체 비대화
• 호출할 때마다 평균을 계산하여 반환한다.
• 성능 구림 but 작은 사이즈 객체
• 상황에 따라 적합한 방식으로 구현해야 한다.

• SpeedDataCollection 예시
• 평균값에 대한 캡슐화가 이루어지지 않았다면?
• 구현방식이 바뀔 때마다 접근방식도 변경될 것이다.
• 캡슐화를 통해서 외부 객체는 항상 동일한 방식으로 원하는 결과를 받을 수 있다.
• 구현상의 융통성을 위한 캡슐화
• 함수를 통해 전달하기 때문에 데이터 전달 시 이벤트/동기화등 다양한 작업이 가능
• Public으로 선언된 멤버들을 변경하면 접근하는 방식을 손 봐야 한다는 의미
• 캡슐화는 클래스의 불변속성을 유지하는데 유리하다.
• 유일한 통로를 통해 접근하므로, 함부로 변경되는 것을 막을 수 있다.

• Protected의 데이터 멤버 무엇이 문제인가?
• Public과 동일한 상황
• 데이터 멤버가 바뀌면 (제거되면) 깨지는 코드의 양과 캡슐화는 반비례
• 결국 protected인 데이터 멤버를 사용하는 모든 파생클래스들이 의존상태인 것.
• 부모 클래스의 protected인 데이터 멤버가 변경되면 많은 코드가 변경돼야 한다.
• 진짜 캡슐화를 하고 싶으면 데이터 멤버들은 private해라!

비멤버 비프렌드 함수의
장점
ITEM 23

Item 23: 비멤버 비프렌드 함수의 장점
• WebBrowser 클래스의 사례
• clearCache, History, Cookie를
한번에 하고 싶다면?
• 함수 clearEverything();
• 멤버 함수로 할 것인가?
• 비멤버 함수로 할 것인가?
class WebBrowser {
public:
...
void clearCache();
void clearHistory();
void removeCookies();
};

• 캡슐화의 측면
• 캡슐화는 데이터에 접근 가능한 루트가 적을 수록 증가한다.
• 멤버함수는 객체의 private 데이터에 접근 가능하다.
• 비멤버 + 비프랜드 함수는 private 데이터에 접근 불가능하다.
• 캡슐화를 강화하는 것은 비멤버 + 비 프렌드 함수를 사용하는 것!
• 다른 비 프랜드 객체의 멤버함수를 사용하는 것도 훌륭한 선택이다.

• 비 멤버 함수와 해당 객체를 같은 네임스페이스 안에 두자
• Namespace WebBrowserStuff {
class WebBrowser {…};
void clearBrowser (WebBrowser& wb);
}
• Utility 함수를 다루는 매우 훌륭한 방법
• 같은 네임스페이스를 여러 개의 소스로 나누어서 사용하는 것이 가능하다.
• 다양한 utility 기능들을 기능별로 헤더로 분리하여 선언하는 것이 가능

• //in WebBrowser.h
Namespace WebBrowserStuff {
class WebBrowser { … };
}
//in WebBrowserBookmarks.h
Namespace WebBrowserStuff {
…
}
• Std 표준 라이브러리도 이런
형식으로 구성된다.
• 필요한 기능만 include 해서
사용할 수 있도록
• 실제로 사용하는 요소만 컴파
일 의존성을 고려하면 된다.
• 패키징 유연성!

• Utility 함수 집합의 확장
• 해당 네임스페이스에 비멤버 비프랜드 함수를 추가하면 됨
• 새로운 헤더 만들고 네임스페이스에 원하는 함수들 추가하면 끝
• 캡슐화가 잘되고 확장도 쉬운 비멤버 비프렌드 함수 씁시다.

멤버함수의 Blind Sight
ITEM 24

Item 24: 멤버함수의 Blind Sight
• 다시 Rational class (지겹다)
• 곱셈 연산을 지원하고 싶다.
• 멤버함수 / 비멤버 함수/ 비멤버 프렌드 함수 (선택지가 너무 많아)
• 객체 지향 파워로 돌파해보자.
• 곱셈 연산은 Rational 클래스 자체랑 관련이 있으니까
• 멤버함수로 넣어주는 게 적절할 것만 같아.
• Item 23에서는 캡슐화가 어쩌고 했지만 넘어가도록 하자

• const Rational operator* (const Rational& rhs);
• Rational oneEight (1, 8);
Rational oneHalf (1, 2);
Rational result = oneHalf * oneEight;
result = result * oneEight;
• 자~알 돌아간다.

• const Rational Rational::operator* (const Rational& rhs);
클래스 멤버함수로 operator*를 정의하자
• Rational oneEight (1, 8);
Rational oneHalf (1, 2);
Rational result = oneHalf * oneEight;
result = result * oneEight;
• 자~알 돌아간다.

• 혼합형 수치 연산하고 싶다. 헠헠 Int * Rational 같은거…
result = oneHalf * 2; //OK
result = 2 * oneHalf //에러?! 왜?!
• 문제의 원인
result = oneHalf. operator*(2); //Rational에서 메소드 호출
result = 2. operator*(oneHalf); //Int에서 메소드 호출??

• 다른 방법의 돌파구
result = operator*(2, oneHalf); //에러!?
• Rational::operator*는 좌변에 반드시 this를 사용하기 때문!
• 우변은 암시적 형변환으로 자연스러운 처리
Rational temp(2);
result = oneHalf.operator*( temp );
• 생성자가 explicit였으면 형변환 불가능으로 이마저도 에러

• 양변에 모두 암시적 형변환을 지원하고 싶다면?
• 멤버 함수로는 안된다.
• 비멤버 함수로 처리
const Rational operator*(const Rational& lhs, const Rational& rhs);
{//좌변과 우변을 모두 설정가능
return Rational(lhs.numerator() * rhs.numerator(), //캡슐화된 접근
lhs.denominator() * rhs.denominator());
}

• 완벽하게 캡슐화된 접근방식으로 operator*를 구현가능하다.
• 쓸데없이 friend 선언해서 캡슐화를 줄이지 말자.
• 객체를 다루는 함수는 가능하면 비 friend 함수로 캡슐화된 접근을 통
해 문제를 해결하자.

예외처리 없는 swap
ITEM 25

Item 25: 예외 처리 없는 swap
• Swap의 중요성
• 예외 안전성 프로그래밍에 반드시 필요한 역할 수행
• 자기 대입 현상에 대처하는데 핵심적 역할 (item 11참조)
• STL에 추가됨
• 잘 동작하는 swap을 만들어 두자.

• 표준의 std::swap
• 전형적인 구현
• T가 복사연산만 지원한다면 제
대로 동작한다.
• 세 번의 복사 연산 비용
• 썩 훌륭해 보이지 않는다.
• Template<typename T>
void swap(T& a, T& b)
{
T temp(a);
a = b;
b = temp;
}

• Pimple Idiom 사용하는 객체의 swap
• Pimple Idiom은 (http://ozt88.tistory.com/32 참조)
• Swap에서 Impl*의 포인터 pImpl의 주소값만 맞바꿔주면 충분하다.
• 하지만 std::swap의 코드대로라면 깊은 복사를 3번 수행한다.
• 초 비효율

• std::swap에 템플릿 특수화를 더하여 해결하자
• Pimple Idiom을 사용하는 객체 Widget에 swap() 메소드 준비
• template<>
void swap<Widget>(Widget& a, Widget& b){
a.swap(b);
}

• 좀더 확장해보자.
• Pimpl에 들어가는 데이터 타입을 매개변수로 받는 클래스 템플릿
• Widget<T>
template<typename T>
void swap<Widget<T>>(Widget<T>& a, Widget<T>& b)
{ a. swap( b ); } //에러??!!
• 함수 템플릿에서 부분 특수화를 허용하지 않는다.
• 클래스 템플릿은 허용한다.

• 부분 특수화 대신 swap을 오버로딩 하는 방법으로 해결가능
void swap(Widget<T>& a, Widget<T>& b)
{ a.swap(b); } //템플릿 특수화를 버리고 일반 오버로딩을 사용
• 하지만 이 코드는 제대로 동작하지 않는다.
• std에 새로운 함수를 추가하는 것이 불가능하기 때문
• std 밖에서도 쉽게 사용할 수 있는 방법은?

• Widget<T>와 오버로딩할
swap함수를 같은 네임스페이스
에 선언한다.
• 컴파일러의 이름탐색 규칙에 따
라서 같은 네임스페이스 안에
있는 swap이 먼저 호출된다.
namespace WidgetStuff {
class Widget { … };
…
void swap(Widget<T>& a ,
Widget<T>& b);
…
}

• 사용자가 swap을 쓰려면?
• 타입 전용 swap이 있는지 없는지도
모르는 상황
• 오른쪽 처럼 쓰면 OK
• using std::swap
• 표준 swap쓸 수 있게 준비
• 실제 swap 호출에서 먼저 이름탐색 규
칙에 따라 T나 네임스페이스에 맞는
swap을 먼저 찾고 없으면 std::swap 씀
Template<typename T>
void doSomething(T& ob1, T&
ob2)
{
using std::swap;
…
swap(ob1, ob2);
}

• 요점정리
• Swap 효율이 나쁘지 않으면 그냥 써라
• 따로 Swap을 만들어 쓰고싶다면
• 해당 타입의 public 멤버함수로 원하는 swap을 정의해라
• 클래스 또는 템플릿이 있는 네임스페이스에 멤버함수 swap을 호출하는
비멤버 swap을 만들어 넣어라.
• 일반 클래스에대한 특수화는 std::swap에서 템플릿 특수화하는 것으로 충분하다.
• swap 호출전에 using std::swap;을 선언하자.

Effective c++ 정리 chapter 4

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (10)

Ähnlich wie Effective c++ 정리 chapter 4

Ähnlich wie Effective c++ 정리 chapter 4 (20)

Effective c++ 정리 chapter 4