SlideShare a Scribd company logo
1 of 16
Download to read offline
항목 1 : 포인터와 참조자를 구별하자
포인터와 참조자는 비슷해보인다.
차이는 포인터는 nullptr 을 가리킬 수, 다시 말해 가리키는 대상이 없을 수 있다.
하지만 참조자는 반드시 가리키는 대상이 있어야 한다.
그리고 포인터는 그 값이 변경되어서 가리키는 대상이 바뀔 수 있지만 참조자는 한 번 가리키기 시작한 대상을 바꿀 수 없다.
그러므로 위의 두 가지 차이점에 따라서 포인터를 쓸 지, 참조자를 쓸 지 결정하면 된다.
예외가 있는데 그건 연산자 함수를 구현할 때이다.
이때 포인터를 사용하면 구현상의 문제는 없지만 코드에서 보여지는 의미가 직관적이지 못하므로 참조자를 쓰자.
항목 2 : 가능한 C++ 스타일의 캐스트를 즐겨 쓰자
EC++ 항목 27과 비슷한 내용
캐스팅이란 사용하지 않는 것이 이상적이지만 필요에 따라서 사용할 때는 주의해야 한다.
특히 C 스타일의 캐스팅은 아무런 제약이 없어서 의도하지 않은 결과를 불러올 수 있다.
그러므로 캐스팅의 성격에 따라서 구분해 놓은 C++ 스타일을 사용하는 것이 좋다.
C++ style casting
const_cast<T> (표현식)
객체의 상수성을 없애는 용도
dynamic_cast<T> (표현식)
안전한 다운캐스팅 – 주어진 객체가 어떤 클래스 상속 계통에 속한 특정 타입인지 판별해서 캐스팅
reinterpret_cast<T> (표현식)
하부 수준의 캐스팅인데 이식성이 없다.
static_cast<T> (표현식)
암시적인 변환을 강제로 수행하게 하는 용도
항목 3 : 배열과 다형성은 같은 수준으로 놓고 볼 것이 아니다
객체지향 프로그래밍의 장점 중 하나인 다형성을 배열을 통해서 사용하지 말자.
그 이유는 배열은 기본적으로 포인터 연산을 통해서 제어되는데,
다형성을 가지는 객체라 하더라도 그 객체의 크기는 서로 다를 수 있기 때문이다.
예를 들어서 기본 객체 배열에 대해 작동하는 함수를 만들고, 파생 클래스를 같은 함수로 작동시키려 하면
배열 내 객체들의 크기가 다르므로 엉뚱한 주소에 대한 포인터로 연산을 하게 된다.
이건 배열을 참조하는 것만이 아니라 해제할 때도 같은 이유로 문제가 발생한다.
다형성이 필요한 배열을 사용해야 한다면 객체를 담지 말고 아예 객체의 포인터를 담아두고 제어하는 것이 좋겠다.
항목 4 : 쓸데 없는 기본 생성자는 그냥 두지 말자
경우에 따라서는 생성과 함께 반드시 초기화가 이루어져야 하는 멤버 변수가 있어서 기본 생성자는 사용하지 않고
매개변수가 있는 생성자만을 사용하는 클래스가 있을 수 있다.
이때 기본 생성자를 그대로 두면 원하지 않는 오작동을 일으키거나,
클래스와 관련된 함수를 작성할 때마다 반드시 초기화가 이루어져야 하는 변수에 대한 유효성을 검사해야 한다.
그래서 기본 생성자를 없애면 당장 배열을 사용할 때 문제가 생긴다.
이를 해결하기 위해서 배열을 힙에 생성하지 않고 생성할 때 직접 모든 배열 내부 데이터를 초기화하는 것이 있지만 그다지 좋지 않다.
그래서 포인터로 배열을 만들고, 각각의 포인터에 클래스를 생성해서 할당하는 방법이 있다.
하지만 나중에 반드시 객체 해제를 수동으로 해야 하는 점과 각 객체 당 포인터 주소만큼의 메모리 공간이 더 필요하다는 단점이 있다.
메모리 공간의 문제는 메모리 지정 new를 통해서 보완이 가능하지만 사용이 그다지 직관적이지는 않다.
기본 생성자가 없으면 템플릿 기반의 클래스를 사용하는데 제약이 생긴다는 단점도 있다.
가상 기본 클래스를 통해서 이 문제를 해결할 수도 있지만 이 경우에는 항상 기본 클래스의 생성자 매개변수를
파생 클래스에서 제공해야 하므로 파생 클래스가 기본 클래스의 모든 정보를 알고, 제공해야 한다.
결국 기본 생성자가 없을 때 얻을 수 있는 이득을 이해하고 상황에 따라서 유리한 것을 선택하는 것이 중요
항목 5 : 사용자 정의 타입변환 함수에 대한 주의를 놓지 말자
컴파일러는 단일 인자 생성자와 암시적 타입변환 연산자를 통해서 마음대로 타입 변환을 한다.
단일 인자 생성자는 말 그대로 생성자의 매개변수가 하나이거나, 하나를 제외한 나머지는 기본값이 있는 것을 말한다.
암시적 타입 변환 연산자는 반환 타입의 이름으로 된 operator 이다.
암시적 타입 변환 연산자로 인해 의도하지 않은 결과가 생기는 것을 막기 위해서는 이름을 타입 이름이 아닌 것으로 만들고,
프로그래머가 직접 필요할 때 그 함수를 호출하도록 하는 것이다.
단일 인자 생성자는 생성자 앞에 explicit 키워드를 붙이는 것으로 암시적 변환을 막을 수 있다.
물론 여전히 명시적으로는 바꿀 수 있다.
항목 6 : 증가 및 감소 연산자의 전위 / 후위 형태를 반드시 구분하자
전위 연산은 먼저 그 변수의 값을 변경하고, 그 변수의 참조를 반환한다.
후위 연산은 변수의 값을 일단 반환하고 그 후에 값을 증가시킨다.
그래서 내부적으로 이전 값을 가진 새로운 변수를 만들어서 반환하고, 변수의 값을 증가시킨다.
이때 반환되는 객체는 const로 선언되는데, 그 이유는 기본 제공 타입에 대한 증가 연산자와 동작이 맞지 않는다는 것과
i++++과 같은 경우에 i++에 의해서 반환되는 객체는 이전 i의 값을 가지는 임시 객체이므로 ++++에서 뒤쪽 ++은 이 임시 객체에 적용된다.
그러므로 i는 1만 증가할 뿐 2가 증가하지 않는다. 이런 애매한 경우를 차단하기 위해 const로 반환한다.
그리고 전위와 후위는 그 결과가 동일함을 보장해야 하므로 후위는 전위 연산을 이용해서 구현되며,
그래서 특별한 이유가 없다면 i++보다 ++i를 상용하는 것이 성능상 유리하다. (하지만 폴리곤 하나 더 줄이는 게 낫겠지요)
항목 7 : &&, ||, 혹은 . 연산자는 오버로딩 대상이 절대로 아니다
&&과 || 중요한 특징 중 하나는 short-circuit semantic 이라는 것이다.
간단하게 관련된 연산을 하다가 뒤에 이어질 연산의 결과가 최종 결과에 영향을 끼치지 못하면
추가적인 연산 없이 결과를 반환하는 것이다.
하지만 &&나 ||를 오버로딩하게 되면 이런 특징을 포기한다는 의미가 되며, 사용하는 사람에게 혼란을 준다.
, 연산의 경우에는 왼쪽에서 오른쪽으로 연산이 진행된다는 특징이 있는데, 이 경우에도 오버로딩하게 되면 이런 특징을 포기하게 된다.
그러니까 괜히 오버로딩하면 안 되는 연산자를 오버로딩하지 말고 있는 걸로 잘 쓰자.
항목 8 : new와 delete의 의미를 정확히 구분하고 이해하자
new 에는 new 연산자와 operator new 두 가지가 있다.
우리가 일반적으로 객체를 힙에 생성할 때 쓰는 new는 new 연산자이며 이는 전역에 선언되어 있다.
이 new 연산자는 생성할 객체의 operator new를 호출해서 객체가 할당될 메모리 주소를 얻고,
생성자를 호출해서 그 위치에 객체를 생성한다.
이때 operator new는 생성될 객체의 크기만큼 메모리를 확보하고 그 메모리의 주소를 반환하는 역할을 한다.
operator new의 경우에는 메모리의 위치를 지정해줄 수 있는데, 이를 메모리 지정 new라고 한다.
delete의 경우 실제 작동은 그 주소에 할당된 객체의 소멸자를 호출하는 것과 메모리를 반환하는 operator delete를 호출하는 것과 같다.
결국 C 의 malloc과 free가 C++의 operator new 와 operator delete라고 할 수 있다.
배열의 경우에는 내부 데이터를 모두다 생성 / 해제를 해야 하므로 new[ ]와 delete[ ]를 사용한다.

More Related Content

What's hot

Effective c++ 1,2
Effective c++ 1,2Effective c++ 1,2
Effective c++ 1,2세빈 정
 
More effective c++ 1
More effective c++ 1More effective c++ 1
More effective c++ 1현찬 양
 
이펙티브 C++ 5,6 장 스터디
이펙티브 C++ 5,6 장 스터디이펙티브 C++ 5,6 장 스터디
이펙티브 C++ 5,6 장 스터디quxn6
 
Effective c++ 4
Effective c++ 4Effective c++ 4
Effective c++ 4현찬 양
 
effective c++ chapter 3~4 정리
effective c++ chapter 3~4 정리effective c++ chapter 3~4 정리
effective c++ chapter 3~4 정리Injae Lee
 
More effective c++ chapter1 2_dcshin
More effective c++ chapter1 2_dcshinMore effective c++ chapter1 2_dcshin
More effective c++ chapter1 2_dcshinDong Chan Shin
 
Effective c++ 2
Effective c++ 2Effective c++ 2
Effective c++ 2현찬 양
 
자바스크립트 핵심 가이드
자바스크립트 핵심 가이드자바스크립트 핵심 가이드
자바스크립트 핵심 가이드재원 변
 
More effective c++ 2
More effective c++ 2More effective c++ 2
More effective c++ 2현찬 양
 
More effective c++ 3
More effective c++ 3More effective c++ 3
More effective c++ 3현찬 양
 
나쁘지만 사용해야 하는 속성들
나쁘지만 사용해야 하는 속성들나쁘지만 사용해야 하는 속성들
나쁘지만 사용해야 하는 속성들BongJin Ko
 
Effective c++ Chapter1,2
Effective c++ Chapter1,2Effective c++ Chapter1,2
Effective c++ Chapter1,2문익 장
 
Ruby - 6th (루비 6장 변수와 식)
Ruby - 6th (루비 6장 변수와 식)Ruby - 6th (루비 6장 변수와 식)
Ruby - 6th (루비 6장 변수와 식)재영 이
 
[Swift] Generics
[Swift] Generics[Swift] Generics
[Swift] GenericsBill Kim
 
Effective c++ 1
Effective c++ 1Effective c++ 1
Effective c++ 1현찬 양
 
[Swift] Optional
[Swift] Optional[Swift] Optional
[Swift] OptionalBill Kim
 
More effective c++ chapter1,2
More effective c++ chapter1,2More effective c++ chapter1,2
More effective c++ chapter1,2문익 장
 
Effective c++ chapter3, 4 요약본
Effective c++ chapter3, 4 요약본Effective c++ chapter3, 4 요약본
Effective c++ chapter3, 4 요약본Dong Chan Shin
 

What's hot (20)

Effective c++ 1,2
Effective c++ 1,2Effective c++ 1,2
Effective c++ 1,2
 
More effective c++ 1
More effective c++ 1More effective c++ 1
More effective c++ 1
 
이펙티브 C++ 5,6 장 스터디
이펙티브 C++ 5,6 장 스터디이펙티브 C++ 5,6 장 스터디
이펙티브 C++ 5,6 장 스터디
 
Effective c++ 4
Effective c++ 4Effective c++ 4
Effective c++ 4
 
effective c++ chapter 3~4 정리
effective c++ chapter 3~4 정리effective c++ chapter 3~4 정리
effective c++ chapter 3~4 정리
 
MEC++ 3,4
MEC++ 3,4MEC++ 3,4
MEC++ 3,4
 
More effective c++ chapter1 2_dcshin
More effective c++ chapter1 2_dcshinMore effective c++ chapter1 2_dcshin
More effective c++ chapter1 2_dcshin
 
5 6 1
5 6 15 6 1
5 6 1
 
Effective c++ 2
Effective c++ 2Effective c++ 2
Effective c++ 2
 
자바스크립트 핵심 가이드
자바스크립트 핵심 가이드자바스크립트 핵심 가이드
자바스크립트 핵심 가이드
 
More effective c++ 2
More effective c++ 2More effective c++ 2
More effective c++ 2
 
More effective c++ 3
More effective c++ 3More effective c++ 3
More effective c++ 3
 
나쁘지만 사용해야 하는 속성들
나쁘지만 사용해야 하는 속성들나쁘지만 사용해야 하는 속성들
나쁘지만 사용해야 하는 속성들
 
Effective c++ Chapter1,2
Effective c++ Chapter1,2Effective c++ Chapter1,2
Effective c++ Chapter1,2
 
Ruby - 6th (루비 6장 변수와 식)
Ruby - 6th (루비 6장 변수와 식)Ruby - 6th (루비 6장 변수와 식)
Ruby - 6th (루비 6장 변수와 식)
 
[Swift] Generics
[Swift] Generics[Swift] Generics
[Swift] Generics
 
Effective c++ 1
Effective c++ 1Effective c++ 1
Effective c++ 1
 
[Swift] Optional
[Swift] Optional[Swift] Optional
[Swift] Optional
 
More effective c++ chapter1,2
More effective c++ chapter1,2More effective c++ chapter1,2
More effective c++ chapter1,2
 
Effective c++ chapter3, 4 요약본
Effective c++ chapter3, 4 요약본Effective c++ chapter3, 4 요약본
Effective c++ chapter3, 4 요약본
 

Similar to MEC++ 1, 2

Effective c++ chapter 1,2 요약
Effective c++ chapter 1,2 요약Effective c++ chapter 1,2 요약
Effective c++ chapter 1,2 요약Nam Hyeonuk
 
Effective c++chapter4
Effective c++chapter4Effective c++chapter4
Effective c++chapter4성연 김
 
Effective c++ 1~8장
Effective c++ 1~8장 Effective c++ 1~8장
Effective c++ 1~8장 Shin heemin
 
Effective c++chapter1 and2
Effective c++chapter1 and2Effective c++chapter1 and2
Effective c++chapter1 and2성연 김
 
Effective c++ 3
Effective c++ 3Effective c++ 3
Effective c++ 3현찬 양
 
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계Eb Styles
 
More effective c++ chapter4 이후 항목 29까지
More effective c++ chapter4 이후 항목 29까지More effective c++ chapter4 이후 항목 29까지
More effective c++ chapter4 이후 항목 29까지Dong Chan Shin
 
Python 이해하기 20160815
Python 이해하기 20160815Python 이해하기 20160815
Python 이해하기 20160815Yong Joon Moon
 
M5 1 1
M5 1 1M5 1 1
M5 1 1nexthw
 
디자인패턴 1~13
디자인패턴 1~13디자인패턴 1~13
디자인패턴 1~13Shin heemin
 
Head first디자인패턴 1~13_희민_호준
Head first디자인패턴 1~13_희민_호준Head first디자인패턴 1~13_희민_호준
Head first디자인패턴 1~13_희민_호준HoJun Sung
 
2014-15 Intermediate C++ Study #6
2014-15 Intermediate C++ Study #62014-15 Intermediate C++ Study #6
2014-15 Intermediate C++ Study #6Chris Ohk
 
Effective java
Effective javaEffective java
Effective javaHaeil Yi
 
More effective c++ 챕터3~4ppt
More effective c++ 챕터3~4pptMore effective c++ 챕터3~4ppt
More effective c++ 챕터3~4pptInjae Lee
 
The art of readable code ch4 ch8
The art of readable code ch4   ch8The art of readable code ch4   ch8
The art of readable code ch4 ch8Ki Sung Bae
 
Chapter7~9 ppt
Chapter7~9 pptChapter7~9 ppt
Chapter7~9 pptInjae Lee
 
[HaU] 신입 기술 면접 준비 java
[HaU] 신입 기술 면접 준비 java[HaU] 신입 기술 면접 준비 java
[HaU] 신입 기술 면접 준비 java유리 하
 
Effective c++ chapter 7,8
Effective c++ chapter 7,8Effective c++ chapter 7,8
Effective c++ chapter 7,8문익 장
 

Similar to MEC++ 1, 2 (20)

EC 789
EC 789EC 789
EC 789
 
Effective c++ chapter 1,2 요약
Effective c++ chapter 1,2 요약Effective c++ chapter 1,2 요약
Effective c++ chapter 1,2 요약
 
Effective c++chapter4
Effective c++chapter4Effective c++chapter4
Effective c++chapter4
 
MEC++ 5
MEC++ 5MEC++ 5
MEC++ 5
 
Effective c++ 1~8장
Effective c++ 1~8장 Effective c++ 1~8장
Effective c++ 1~8장
 
Effective c++chapter1 and2
Effective c++chapter1 and2Effective c++chapter1 and2
Effective c++chapter1 and2
 
Effective c++ 3
Effective c++ 3Effective c++ 3
Effective c++ 3
 
보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계보다 나은 웹 어플리케이션 설계
보다 나은 웹 어플리케이션 설계
 
More effective c++ chapter4 이후 항목 29까지
More effective c++ chapter4 이후 항목 29까지More effective c++ chapter4 이후 항목 29까지
More effective c++ chapter4 이후 항목 29까지
 
Python 이해하기 20160815
Python 이해하기 20160815Python 이해하기 20160815
Python 이해하기 20160815
 
M5 1 1
M5 1 1M5 1 1
M5 1 1
 
디자인패턴 1~13
디자인패턴 1~13디자인패턴 1~13
디자인패턴 1~13
 
Head first디자인패턴 1~13_희민_호준
Head first디자인패턴 1~13_희민_호준Head first디자인패턴 1~13_희민_호준
Head first디자인패턴 1~13_희민_호준
 
2014-15 Intermediate C++ Study #6
2014-15 Intermediate C++ Study #62014-15 Intermediate C++ Study #6
2014-15 Intermediate C++ Study #6
 
Effective java
Effective javaEffective java
Effective java
 
More effective c++ 챕터3~4ppt
More effective c++ 챕터3~4pptMore effective c++ 챕터3~4ppt
More effective c++ 챕터3~4ppt
 
The art of readable code ch4 ch8
The art of readable code ch4   ch8The art of readable code ch4   ch8
The art of readable code ch4 ch8
 
Chapter7~9 ppt
Chapter7~9 pptChapter7~9 ppt
Chapter7~9 ppt
 
[HaU] 신입 기술 면접 준비 java
[HaU] 신입 기술 면접 준비 java[HaU] 신입 기술 면접 준비 java
[HaU] 신입 기술 면접 준비 java
 
Effective c++ chapter 7,8
Effective c++ chapter 7,8Effective c++ chapter 7,8
Effective c++ chapter 7,8
 

More from Gyeongwook Choi

introduction to dynamic programming and linear programming
introduction to dynamic programming and linear programmingintroduction to dynamic programming and linear programming
introduction to dynamic programming and linear programmingGyeongwook Choi
 
Postmortem d ao_c_최경욱
Postmortem d ao_c_최경욱Postmortem d ao_c_최경욱
Postmortem d ao_c_최경욱Gyeongwook Choi
 

More from Gyeongwook Choi (6)

Mec 56
Mec 56Mec 56
Mec 56
 
JSON with C++ & C#
JSON with C++ & C#JSON with C++ & C#
JSON with C++ & C#
 
approximation algorithm
approximation algorithmapproximation algorithm
approximation algorithm
 
introduction to dynamic programming and linear programming
introduction to dynamic programming and linear programmingintroduction to dynamic programming and linear programming
introduction to dynamic programming and linear programming
 
STL study (skyLab)
STL study (skyLab)STL study (skyLab)
STL study (skyLab)
 
Postmortem d ao_c_최경욱
Postmortem d ao_c_최경욱Postmortem d ao_c_최경욱
Postmortem d ao_c_최경욱
 

MEC++ 1, 2

  • 1. 항목 1 : 포인터와 참조자를 구별하자
  • 2. 포인터와 참조자는 비슷해보인다. 차이는 포인터는 nullptr 을 가리킬 수, 다시 말해 가리키는 대상이 없을 수 있다. 하지만 참조자는 반드시 가리키는 대상이 있어야 한다. 그리고 포인터는 그 값이 변경되어서 가리키는 대상이 바뀔 수 있지만 참조자는 한 번 가리키기 시작한 대상을 바꿀 수 없다. 그러므로 위의 두 가지 차이점에 따라서 포인터를 쓸 지, 참조자를 쓸 지 결정하면 된다. 예외가 있는데 그건 연산자 함수를 구현할 때이다. 이때 포인터를 사용하면 구현상의 문제는 없지만 코드에서 보여지는 의미가 직관적이지 못하므로 참조자를 쓰자.
  • 3. 항목 2 : 가능한 C++ 스타일의 캐스트를 즐겨 쓰자
  • 4. EC++ 항목 27과 비슷한 내용 캐스팅이란 사용하지 않는 것이 이상적이지만 필요에 따라서 사용할 때는 주의해야 한다. 특히 C 스타일의 캐스팅은 아무런 제약이 없어서 의도하지 않은 결과를 불러올 수 있다. 그러므로 캐스팅의 성격에 따라서 구분해 놓은 C++ 스타일을 사용하는 것이 좋다. C++ style casting const_cast<T> (표현식) 객체의 상수성을 없애는 용도 dynamic_cast<T> (표현식) 안전한 다운캐스팅 – 주어진 객체가 어떤 클래스 상속 계통에 속한 특정 타입인지 판별해서 캐스팅 reinterpret_cast<T> (표현식) 하부 수준의 캐스팅인데 이식성이 없다. static_cast<T> (표현식) 암시적인 변환을 강제로 수행하게 하는 용도
  • 5. 항목 3 : 배열과 다형성은 같은 수준으로 놓고 볼 것이 아니다
  • 6. 객체지향 프로그래밍의 장점 중 하나인 다형성을 배열을 통해서 사용하지 말자. 그 이유는 배열은 기본적으로 포인터 연산을 통해서 제어되는데, 다형성을 가지는 객체라 하더라도 그 객체의 크기는 서로 다를 수 있기 때문이다. 예를 들어서 기본 객체 배열에 대해 작동하는 함수를 만들고, 파생 클래스를 같은 함수로 작동시키려 하면 배열 내 객체들의 크기가 다르므로 엉뚱한 주소에 대한 포인터로 연산을 하게 된다. 이건 배열을 참조하는 것만이 아니라 해제할 때도 같은 이유로 문제가 발생한다. 다형성이 필요한 배열을 사용해야 한다면 객체를 담지 말고 아예 객체의 포인터를 담아두고 제어하는 것이 좋겠다.
  • 7. 항목 4 : 쓸데 없는 기본 생성자는 그냥 두지 말자
  • 8. 경우에 따라서는 생성과 함께 반드시 초기화가 이루어져야 하는 멤버 변수가 있어서 기본 생성자는 사용하지 않고 매개변수가 있는 생성자만을 사용하는 클래스가 있을 수 있다. 이때 기본 생성자를 그대로 두면 원하지 않는 오작동을 일으키거나, 클래스와 관련된 함수를 작성할 때마다 반드시 초기화가 이루어져야 하는 변수에 대한 유효성을 검사해야 한다. 그래서 기본 생성자를 없애면 당장 배열을 사용할 때 문제가 생긴다. 이를 해결하기 위해서 배열을 힙에 생성하지 않고 생성할 때 직접 모든 배열 내부 데이터를 초기화하는 것이 있지만 그다지 좋지 않다. 그래서 포인터로 배열을 만들고, 각각의 포인터에 클래스를 생성해서 할당하는 방법이 있다. 하지만 나중에 반드시 객체 해제를 수동으로 해야 하는 점과 각 객체 당 포인터 주소만큼의 메모리 공간이 더 필요하다는 단점이 있다. 메모리 공간의 문제는 메모리 지정 new를 통해서 보완이 가능하지만 사용이 그다지 직관적이지는 않다. 기본 생성자가 없으면 템플릿 기반의 클래스를 사용하는데 제약이 생긴다는 단점도 있다. 가상 기본 클래스를 통해서 이 문제를 해결할 수도 있지만 이 경우에는 항상 기본 클래스의 생성자 매개변수를 파생 클래스에서 제공해야 하므로 파생 클래스가 기본 클래스의 모든 정보를 알고, 제공해야 한다. 결국 기본 생성자가 없을 때 얻을 수 있는 이득을 이해하고 상황에 따라서 유리한 것을 선택하는 것이 중요
  • 9. 항목 5 : 사용자 정의 타입변환 함수에 대한 주의를 놓지 말자
  • 10. 컴파일러는 단일 인자 생성자와 암시적 타입변환 연산자를 통해서 마음대로 타입 변환을 한다. 단일 인자 생성자는 말 그대로 생성자의 매개변수가 하나이거나, 하나를 제외한 나머지는 기본값이 있는 것을 말한다. 암시적 타입 변환 연산자는 반환 타입의 이름으로 된 operator 이다. 암시적 타입 변환 연산자로 인해 의도하지 않은 결과가 생기는 것을 막기 위해서는 이름을 타입 이름이 아닌 것으로 만들고, 프로그래머가 직접 필요할 때 그 함수를 호출하도록 하는 것이다. 단일 인자 생성자는 생성자 앞에 explicit 키워드를 붙이는 것으로 암시적 변환을 막을 수 있다. 물론 여전히 명시적으로는 바꿀 수 있다.
  • 11. 항목 6 : 증가 및 감소 연산자의 전위 / 후위 형태를 반드시 구분하자
  • 12. 전위 연산은 먼저 그 변수의 값을 변경하고, 그 변수의 참조를 반환한다. 후위 연산은 변수의 값을 일단 반환하고 그 후에 값을 증가시킨다. 그래서 내부적으로 이전 값을 가진 새로운 변수를 만들어서 반환하고, 변수의 값을 증가시킨다. 이때 반환되는 객체는 const로 선언되는데, 그 이유는 기본 제공 타입에 대한 증가 연산자와 동작이 맞지 않는다는 것과 i++++과 같은 경우에 i++에 의해서 반환되는 객체는 이전 i의 값을 가지는 임시 객체이므로 ++++에서 뒤쪽 ++은 이 임시 객체에 적용된다. 그러므로 i는 1만 증가할 뿐 2가 증가하지 않는다. 이런 애매한 경우를 차단하기 위해 const로 반환한다. 그리고 전위와 후위는 그 결과가 동일함을 보장해야 하므로 후위는 전위 연산을 이용해서 구현되며, 그래서 특별한 이유가 없다면 i++보다 ++i를 상용하는 것이 성능상 유리하다. (하지만 폴리곤 하나 더 줄이는 게 낫겠지요)
  • 13. 항목 7 : &&, ||, 혹은 . 연산자는 오버로딩 대상이 절대로 아니다
  • 14. &&과 || 중요한 특징 중 하나는 short-circuit semantic 이라는 것이다. 간단하게 관련된 연산을 하다가 뒤에 이어질 연산의 결과가 최종 결과에 영향을 끼치지 못하면 추가적인 연산 없이 결과를 반환하는 것이다. 하지만 &&나 ||를 오버로딩하게 되면 이런 특징을 포기한다는 의미가 되며, 사용하는 사람에게 혼란을 준다. , 연산의 경우에는 왼쪽에서 오른쪽으로 연산이 진행된다는 특징이 있는데, 이 경우에도 오버로딩하게 되면 이런 특징을 포기하게 된다. 그러니까 괜히 오버로딩하면 안 되는 연산자를 오버로딩하지 말고 있는 걸로 잘 쓰자.
  • 15. 항목 8 : new와 delete의 의미를 정확히 구분하고 이해하자
  • 16. new 에는 new 연산자와 operator new 두 가지가 있다. 우리가 일반적으로 객체를 힙에 생성할 때 쓰는 new는 new 연산자이며 이는 전역에 선언되어 있다. 이 new 연산자는 생성할 객체의 operator new를 호출해서 객체가 할당될 메모리 주소를 얻고, 생성자를 호출해서 그 위치에 객체를 생성한다. 이때 operator new는 생성될 객체의 크기만큼 메모리를 확보하고 그 메모리의 주소를 반환하는 역할을 한다. operator new의 경우에는 메모리의 위치를 지정해줄 수 있는데, 이를 메모리 지정 new라고 한다. delete의 경우 실제 작동은 그 주소에 할당된 객체의 소멸자를 호출하는 것과 메모리를 반환하는 operator delete를 호출하는 것과 같다. 결국 C 의 malloc과 free가 C++의 operator new 와 operator delete라고 할 수 있다. 배열의 경우에는 내부 데이터를 모두다 생성 / 해제를 해야 하므로 new[ ]와 delete[ ]를 사용한다.