블로그 이미지
이태원에서 사는 다섯식구의 무직 가장. 흰둥에미

카테고리

분류 전체보기 (184)
Itaewon (2)
ryu's?? (1)
20121210이전 (20)
20130827이전 (147)
soo'study (13)
Total35,270
Today14
Yesterday4

'effective c ++'에 해당되는 글 14건

  1. 2013.01.10 항목 53 - 55 (2)
  2. 2013.01.10 항목 49 - 52
  3. 2013.01.09 항목 46 - 48
  4. 2013.01.09 항목 41 - 45 (1)
  5. 2013.01.08 항목 36 - 40
  6. 2013.01.08 항목 32 - 35
  7. 2013.01.03 항목 29 - 31
  8. 2012.12.22 항목 26 - 28
  9. 2012.12.22 항목 22 - 25
  10. 2012.12.21 항목 18 - 21

항목 53 - 55

20130827이전/EC++ / 2013.01.10 02:27

misc..


항목 53. 컴파일러 경고를 지나치지 말자.

    - 컴파일러 경고는 컴파일러 의존적이므로, 컴파일러에 따라 천차만별.

    - 최고 경고 수준으로도 경고를 발생시키지 않는 쪽으로 코드를 만들자.


항목 54. tr1을 포함한 표준 라이브러리 구성요소와 편안한 친구가 되자.

    - 현재 C++0x를 지원하는 컴파일러가 나오고들 있다. tr1라이브러리의 기능들이 대부분 포함된걸로 안다.

       구 버전의 msvs는 서비스팩을 설치하고, 2012는 포함되어 있던걸로 안다.


항목 55. 부스트를 늘 여러분 가까이에.

    - 항목 54의 내용으로 퉁. boost.org에 자주 놀러가자.

신고

'20130827이전 > EC++' 카테고리의 다른 글

항목 53 - 55  (2) 2013.01.10
항목 49 - 52  (0) 2013.01.10
항목 46 - 48  (0) 2013.01.09
항목 41 - 45  (1) 2013.01.09
항목 36 - 40  (0) 2013.01.08
항목 32 - 35  (0) 2013.01.08
Posted by 흰둥에미

항목 49 - 52

20130827이전/EC++ / 2013.01.10 02:22

메모리 생성과 해제..


항목 49. new 처리자의 동작 원리를 제대로 이해하자

    - 메모리 할당 요청을 operator new 함수가 맞추어 주지 못할 경우에 operator new 함수는 예외를 던짐

       예외를 던지기 전에 에러 처리 함수를 우선적으로 호출하도록 되어 있는데,

       이 에러 처리 함수를 가리켜 new 처리자(new-handler)라고 함.

    - 표준 라이브러리의 set_new_handler로 new 처리자를 지정할 수 있음.

    - new 처리자 함수가 프로그램의 동작에 좋은 영향을 미치기 위해 꼭 하나는 해주어야 할 기능들?

       1. 사용할 수 있는 메모리를 더 많이 확보

       2. 다른 new 처리자를 설치

       3. new 처리자의 설치를 제거

       4. 예외를 던짐.

       5. 복귀하지 않고, 프로그램 종료.

    - 예외 불가 new (new (std::nothrow) CLASS;)는 영향력이 제한.

       메모리 할당 자체에만 적용되기에, 이후 호출되는 생성자에서 얼마든지 예외 발생 가능.


항목 50. new 및 delete를 언제 바꿔야 좋은 소리를 들을지를 파악해 두자.

    - operator new와 operator delete를 바꾸고 싶은 대표적 잉ㅍ.

       1. 잘못된 힙 사용을 탐지하기 위해

       2. 효율을 향상시키기 위해

          (1) 할당 및 해제 속력을 높이기 위해

          (2) 기본 메모리 관리자의 공간 오버헤드를 줄이기 위해

          (3) 적당히 타협한 기본 할당자의 바이트 정렬 동작을 보장하기 위해

          (4) 임의의 관계를 맺고 있는 객체들을 한 군데에 나란히 모아놓기 위해

       3. 동적 할당 메모리의 실제 사용에 관한 통계 정보를 수집하기 위해

       4. 그때그때 원하는 동작을 수행하도록 하기 위해


항목 51. new 및 delete를 작성할 때 따라야 할 기존의 관례를 잘 알아 두자.

    - 관례적으로, operator new 함수는 메모리 할당을 반복해서 시도하는 무한 루프를 가져야 하고,

       메모리 할당 요구를 만족시킬 수 없을 때 new 처리자를 호출해야 하며, 0바이트에 대한 대책도 있어야 합니다.

       클래스 전용 버전은 자신이 할당하기로 예정된 크기보다 더큰(틀린) 메모리 블록에 대한 요구도 처리해야 합니다.

    - operator delete 함수는 널 포인터가 들어왔을 때 아무 일도 하지 않아야 합니다.

       클래스 전용 버전의 경우에는 예정 크기보다 더 큰 블록을 처리해야 합니다.


항목 52. 위치지정 new를 작성한다면 위치지정 delete도 같이 준비하자.

    - 위치지정 new : 메모리 사이즈 외에, 메모리를 할당할 위치의 포인터를 추가 인자로 받는 operator에서 유래

                             추가 인자가 있는 operator new를 위치지정 new로 일컫기도 함.

    - operator new 함수의 위치지정 버전을 만들 때는, 이 함수와 짝을 이루는 위치지정 버전의 operator delete 함수도 꼭 만들어라.

    - new 및 delete의 위치지정 버전을 선언할 때는, 이들의 표준 버전이 가려지는 일(의도하지 않음)이 생기지 않도록 주의해 주세요.


신고

'20130827이전 > EC++' 카테고리의 다른 글

항목 53 - 55  (2) 2013.01.10
항목 49 - 52  (0) 2013.01.10
항목 46 - 48  (0) 2013.01.09
항목 41 - 45  (1) 2013.01.09
항목 36 - 40  (0) 2013.01.08
항목 32 - 35  (0) 2013.01.08
Posted by 흰둥에미

항목 46 - 48

20130827이전/EC++ / 2013.01.09 16:50

항목 46. 타입 변환이 바람직할 경우에는 비멤버 함수를 클래스 템플릿안엥 정의해 두자.

     - 모든 매개변수에 대해 암시적 타입 변환을 지원하는 템플릿과 관계가 있는 함수를 제공하는 클래스 템플릿을 만들려고 한다면,

       이런 함수는 클래스 템플릿 안에 프렌드 함수로서 정의합시다.


항목 47. 타입에 대한 정보가 필요하다면 특성정보 클래스를 사용하자.

     - traits

     - 특성정보 클래스는 컴파일 도중에 사용할 수 있는 타입 관련 정보를 만들어냅니다.

        또한 특성정보 클래스는 템플릿 및 템플릿 특수화 버전을 사용하여 구현합니다.

     - 함수 오버로딩 기법과 결합하여 특성정보 클래스를 사용하면,

        컴파일 타입에 결정되는 타입별 if... else 점검문을 구사할 수 있습니다.


항목 48. 템플릿 메타프로그래밍, 하지 않겠는가?

     - c++ 컴파일러가 실행시키는, c++로 만들어진 프로그램

     - 재귀 템플릿 인스턴스화

     - 치수 단위의 정확성 확인, 행렬 연산의 최적화(표현식 템플릿), 맞춤식 디자인 패턴 구현의 생성(정책기반설계, 생성식프로그래밍)

     - 템플릿 메타프로그래밍은 기존 작업을 런타임에서 컴파일 타임으로 전환하는 효과를 냅니다.

        따라서 TMP를 쓰면 선행 에러 탐지와 높은 런타임 효율을 손에 거머쥘 수 있습니다.

     - TMP는 정책 선택의 조합에 기반하여 사용자 정의 코드를 생성하는 데 쓸 수 있으며,

        또한 특정 타입에 대해 부적절한 코드가 만들어지는 것을 막는 데도 쓸 수 있습니다.


신고

'20130827이전 > EC++' 카테고리의 다른 글

항목 53 - 55  (2) 2013.01.10
항목 49 - 52  (0) 2013.01.10
항목 46 - 48  (0) 2013.01.09
항목 41 - 45  (1) 2013.01.09
항목 36 - 40  (0) 2013.01.08
항목 32 - 35  (0) 2013.01.08
Posted by 흰둥에미

항목 41 - 45

20130827이전/EC++ / 2013.01.09 04:50

템플릿과 일반화 프로그래밍....


항목 41. 템플릿 프로그래밍의 천릿길도 암시적 인터페이스와 컴파일 타임 다형성부터..

      - 클래스 및 템플릿은 모두 인터페이스와 다형성을 지원합니다.

      - 클래스에서, 인터페이스는 명시적이며 함수의 시그너처를 중심으로 구성되어 있습니다.

         다형성은 프로그램 실행 중에 가상 함수를 통해 나타납니다.

      - 템플릿 매개변수의 경우, 인터페이스는 암시적이며 유효 표현식에 기반을 두어 구성됩니다.

        다형성은 컴파일 중에 템플릿 인스턴스화와 함수 오버로딩 모호성 해결을 통해 나타납니다.

        if (w.size() > 10 && w != someW) ... 에서 조건문의 결과가 bool과 호환만 되면 된다.


항목 42. typename의 두 가지 의미를 제대로 파악하자.

      - 템플릿의 타입 매개변수를 선언할 때는 class와 typename의 뜻이 완전히 똑같다.

      - nested dependent type name에 대해 컴파일러가 타입인지 아닌지 알 방법이 없기에,

         typename C::const_iterator iter(container.begin()); 의 형태로 써야 한다.

         단, 중첩 의존 타입 이름이 기본 클래스의 리스트에 있거나,

         멤버 초기화 리스트 내의 기본 클래스 식별자로 있는 경우는 안붙여줌.


항목 43. 템플릿으로 만들어진 기본 클래스 안의 이름에 접근하는 방법을 알아 두자.

      - template<>

        class A : public B<Special> {....      -> 완전 템플릿 특수화.

      - 위와 같은 완전 템플릿 특수화의 가능성으로 인해 기본 클래스의 함수를 그냥 호출하는 것은 불가능.

      - 방법 1. this->method();

      - 방법 2. using 선언을 이용하여 사용.

      - 방법 3. 기본클래스에 한정자를 붙여 호출(호출되는 함수가 가상 함수인 경우, 가상 함수 바인딩이 무시되므로 비추)


항목 44. 매개변수에 독립적인 코드는 템플릿으로부터 분리시키자.

      - 템플릿 사용으로 인한 코드 비대화를 막기위해..

      - 공통성 및 가변성 분석

      - 템플릿을 사용하면 비슷비슷한 클래스와 함수가 여러 벌 만들어집니다.

         따라서 템플릿 매개변수에 종속되지 않은 템플릿 코드는 비대화의 원인이 됩니다.

      - 비타입 템플릿 매개변수로 생기는 코드 비대화의 경우,

         템플릿 매개변수를 함수 매개변수 혹은 클래스 데이터 멤버로 대체함으로써 비대화를 종종 없앨 수 있습니다.

      - 타입 매개변수로 생기는 코드 비대화의 경우, 동일한 이진 표현구조를 가지고 인스턴스화되는 타입들이

         한 가지 함수 구현을 공유하게 만듦으로서 비대화를 감소시킬 수 있습니다.

항목 45. "호환되는 모든 타입"을 받아들이는 데는 멤버 함수 템플릿이 직방!

      - 생성자를 만들어내는 템플릿을 사용 (일반화 복사 생성자)

      - 멤버 함수 템플릿 - 어떤 클래스의 멤버 함수를 찍어내는 템플릿

      - 호환되는 모든 타입을 받아들이는 멤버 함수를 만들려면 멤버 함수 템플릿을 사용합니다.

      - 일반화된 복사 생성 연산과 일반화된 대입 연산을 위해 멤버 템플릿을 선언했다 하더라도,

         보통의 복사 생성자와 복사 대입 연산자는 여전히 직접 선언해야 합니다.


신고

'20130827이전 > EC++' 카테고리의 다른 글

항목 49 - 52  (0) 2013.01.10
항목 46 - 48  (0) 2013.01.09
항목 41 - 45  (1) 2013.01.09
항목 36 - 40  (0) 2013.01.08
항목 32 - 35  (0) 2013.01.08
항목 29 - 31  (0) 2013.01.03
Posted by 흰둥에미

항목 36 - 40

20130827이전/EC++ / 2013.01.08 15:25

항목 36. 상속받은 비가상 함수를 파생 클래스에서 재정의하는 것은 절대 금물!

       - 비가상 함수는 정적 바인딩으로 묶이고, 가상 함수는 동적 바인딩으로 묶임.

       - 따라서 파생 클래스를 부모 클래스의 포인터에 넣고 비가상 함수 호출시, 부모의 함수가 수행됨.


항목 37. 어떤 함수에 대해서도 상속받은 기본 매개변수 값은 절대로 재정의하지 말자.

       - 가상 함수는 동적으로 바인딩 되지만, 기본 매개변수는 정적으로 바인딩 된다.

       - 항목 36가 비슷한 연유로, 위험.


항목 38. "has a" 혹은 "is implemented in terms of"를 모형화할 때는 객체 합성을 사용하자.

       - A has a B (A is implemented in terms of B) 이면 B는 A의 멤버로...


항목 39. private 상속은 심사숙고해서 구사하자.

       - private 상속이 필요한 경우는, is implemented in terms of(멤버쯤)처럼 사용하면서 비공개 멤버를 접근할 때,

         혹은 가상 함수를 재정의할 경우에 사용하자.

       - private상속보다 public상속에 객체 합성 조합이 더 좋은 이유

          1. 가상 함수의 재정의를 설계차원에서 막을 때

          2. 컴파일 의존성을 최소화하고 싶을 때.

       - private 상속이 유용한 경우 - 공백 기본 클래스 최적화


항목 40. 다중 상속은 심사숙고해서 사용하자.

       - 마름모꼴의 다중 상속에서, 기본은 데이터 멤버를 중복생성 시키지만, 가상 기본 클래스로 만들면 중복생성되지 않는다.

       - 가상 상속을 쓰면 크기, 속도 비용이 늘어나며, 초기화 및 대입 연산의 복잡도가 커짐.

         따라서 가상 기본 클래스에는 데이터를 두지 않는 것이 현실적으로 가장 실용적

       - 다중 상속을 적절하게 사용하는 법은, 인터페이스 클래스로부터 public 상속과 동시에 구현을 돕는 클래스로부터 private 상속


신고

'20130827이전 > EC++' 카테고리의 다른 글

항목 46 - 48  (0) 2013.01.09
항목 41 - 45  (1) 2013.01.09
항목 36 - 40  (0) 2013.01.08
항목 32 - 35  (0) 2013.01.08
항목 29 - 31  (0) 2013.01.03
항목 26 - 28  (0) 2012.12.22
Posted by 흰둥에미

항목 32 - 35

20130827이전/EC++ / 2013.01.08 15:18

항목 32. public 상속 모형은 반드시 "is a..."를 따르도록 만들자.

      - 기본 클래스에 적용되는 모든 것들이 파생 클래스에 그대로 적용되어야 함.


항목 33. 상속된 이름을 숨기는 일은 피하자.

      - 파생 클래스의 이름은 기본 클래스의 이름을 가림, 가려진 이름은 using선언이나, 전달 함수를 이용해 쓸 수 있음.


항목 34. 인터페이스 상속과 구현 상속의 차이를 제대로 파악하고 구별하자.

      - 순수 가상 함수를 선언하는 목적은 파생 클래스에게 함수의 인터페이스만을 물려줌.

      - 단순 가상 함수는 인터페이스 상속과 더불어 기본 구현의 상속도 가능하게 함.

      - 비가상 함수는 인터페이스 상속과 더불어 필수 구현도 상속하게 함.


항목 35. 가상 함수 대신 쓸 것들도 생각해 두는 자세를 시시때때로 길러 두자.

      - 비가상 인터페이스 관용구를 통한 템플릿 메서드 패턴

         (비가상 함수에서 가상 함수를 호출하게 하고, 파생 클래스에서는 그 가상 함수들을 오버라이딩)

      - 함수 포인터를 이용한 strategy pattern, 파생 클래스 생성시 필요한 함수의 포인터를 전달하여, 각각의 동작을 정함.

      - tr1::function을 이용한 strategy pattern, 함수 포인터를 이용한 것과 비슷한 개념으로 융통성이 증가.

      - 고전적인 strategy pattern,

        파생 클래스 생성시 원하는 동작의 함수가 구현된 클래스를 넘기고, 그 클래스의 가상함수를 통해 각자의 동작을 수행.

신고

'20130827이전 > EC++' 카테고리의 다른 글

항목 41 - 45  (1) 2013.01.09
항목 36 - 40  (0) 2013.01.08
항목 32 - 35  (0) 2013.01.08
항목 29 - 31  (0) 2013.01.03
항목 26 - 28  (0) 2012.12.22
항목 22 - 25  (0) 2012.12.22
Posted by 흰둥에미

항목 29 - 31

20130827이전/EC++ / 2013.01.03 17:31

항목 29. 예외 안전성이 확보되는 그날 위해 싸우고 또 싸우자.

          - 자원이 새지 않도록 만든다.

          - 자료구조가 더럽혀지는 것을 허용하지 않는다.

          - 예외 안전성 - 기본적인 보장, 강력한 보장, 예외불가 보장.

          - 어떤 함수가 제공하는 예외 안전성 보장의 강도는, 그 함수가 내부적으로 호출하는 함수들이 제공하는 가장 약한 보장을 넘지

            못함.


항목 30. 인라인 함수는 미주알고주알 따져서 이해해 두자.

          - 인라인 함수는 대체적으로 헤더 파일에 들어 있어야 한다.

          - 루프나 재귀 함수의 경우 인라인화 하지 않음.

          - 함수 포인터를 통해 호출하는 함수는 인라인화 되지 않음.

          - 생성자, 소멸자는 인라인화 되지 않음

          - 작고, 자주 호출되는 함수에 대해서만 인라인화 하자.


항목 31. 파일 사이의 컴파일 의존성을 최대로 줄이자.

          - 헤더에서는 전방선언

          - pimpl 관용구를 사용하자.(Proxy랑 비슷한 느낌이긴 한데..) - 핸들 클래스

          - 추상 기본클래스와 팩토리 함수를 제공하여 사용한다 - 인터페이스 클래스

          - 객체 참조자 및 포인터로 충분한 경우에는 객체를 직접 쓰지 않습니다.

          - 할 수 있으면 클래스 정의 대신 클래스 선언에 최대한 의존하도록 만듭니다.

          - 선언부와 정의부에 대해 별도의 헤더 파일을 제공합니다.


신고

'20130827이전 > EC++' 카테고리의 다른 글

항목 36 - 40  (0) 2013.01.08
항목 32 - 35  (0) 2013.01.08
항목 29 - 31  (0) 2013.01.03
항목 26 - 28  (0) 2012.12.22
항목 22 - 25  (0) 2012.12.22
항목 18 - 21  (0) 2012.12.21
Posted by 흰둥에미

항목 26 - 28

20130827이전/EC++ / 2012.12.22 04:16

구현....


항목 26. 변수 정의는 늦출 수 있는 데까지 늦추는 근성을 발휘하자.

더보기

               상황이나, 생성, 소멸자 호출의 비용에 따라 적절한 루프를 적용하자.


항목 27. 캐스팅은 절약, 또 절약! 잊지 말자.

            구형 스타일의 캐스팅은 자제하자. 소스에서 찾기도 힘들고, 실제로 어떤 캐스팅이 이루어지는지 가독성이 좋지 않다.

            물론 꼭 필요한 상황이 아니라면, 캐스팅을 사용하지 않는 쪽으로 구현, 최소한 함수안에 숨겨라.

            const_cast - 객체의 상수성을 없애는 용도 (혹은 휘발성을 제거하는 용도로도 쓰임)

            dynamic_cast - 안전한 다운캐스팅, 실패시 nullptr 반환, 런타임 비용이 높음.

            reinterpret_cast - 포인터를 int로 바꾸는 등의 하부 수준 캐스팅, 이식성이 없음.

            static_cast - 암시적 변환을 강제로 진행할 때 사용. 흔히들 이루어지는 타입 변환을 거꾸로 수행하는 용도.


항목 28. 내부에서 사용하는 객체에 대한 '핸들'을 반환하는 코드는 되도록 피하자.

            멤버 함수에서 데이터 멤버의 참조자를 꼭 반환해야 하는 상황이라면, const를 붙여라.


신고

'20130827이전 > EC++' 카테고리의 다른 글

항목 32 - 35  (0) 2013.01.08
항목 29 - 31  (0) 2013.01.03
항목 26 - 28  (0) 2012.12.22
항목 22 - 25  (0) 2012.12.22
항목 18 - 21  (0) 2012.12.21
항목 13 - 17  (1) 2012.12.21
Posted by 흰둥에미

항목 22 - 25

20130827이전/EC++ / 2012.12.22 03:40

항목 22. 데이터 멤버가 선언될 곳은 private 영역임을 명심하자.

            문법적 일관성을 위해 - 데이터 멤버의 읽기, 쓰기에 대한 권한을 함수로써 구현할 수 있음.

            캡슐화 - 함수를 통해 데이터 멤버에 접근할 수 있도록 구현해 두면, 데이터 멤버를 나중에 계산식으로 대체할 수 있다.

                         구현상의 융통성을 가질 수 있음.


항목 23. 멤버 함수보다는 비멤버 비프렌드 함수와 더 가까워지자.

            캡슐화의 정도가 높아지고, 패키징 유연성도 커지며, 기능적인 확장성도 늘어난다.

            class WebBrowser { void clearBrowser(); } 보단, void clearBrowser(WebBrowser& wb); 가 낫다.

            동일한 namespace에 대해 기능에 따라 다른 헤더 파일에 나눌 수 있다.


항목 24. 타입 변환이 모든 매개변수에 대해 적용되어야 한다면 비멤버 함수를 선언하자.

            어떤 함수에 들어가는 모든 매개변수(this 포인터가 가리키는 객체도 포함해서)에 대해 타입 변환을 해 줄 필요가 있다면,

            그 함수는 비멤버이어야 한다.


항목 25. 예외를 던지지 않는 swap에 대한 지원도 생각해 보자.

            std::swap의 완전 템플릿 특수화

더보기

            함수 템플릿의 부분 특수화가 불가능 하므로 아래와 같이 비멤버 버전의 함수 제공.

더보기

            사용시, using std::swap;

                       swap(obj1, obj2); ---> (1) 타입T와 동일한 네임스페이스 안에서 T 전용의 swap을 찾음.

                                                         (2) T에 대한 std::swap의 특수화 버전을 찾음.

                                                         (3) std의 swap이 호출됨.

신고

'20130827이전 > EC++' 카테고리의 다른 글

항목 29 - 31  (0) 2013.01.03
항목 26 - 28  (0) 2012.12.22
항목 22 - 25  (0) 2012.12.22
항목 18 - 21  (0) 2012.12.21
항목 13 - 17  (1) 2012.12.21
항목 9 - 12  (0) 2012.12.21
Posted by 흰둥에미

항목 18 - 21

20130827이전/EC++ / 2012.12.21 23:32

설계 및 선언


항목 18. 인터페이스 설계는 제대로 쓰기엔 쉽게, 엉터리로 쓰기엔 어렵게 하자.

            Date d(Month(3), Day(30), Year(1995));  --> 숫자를 직접 인자로 받는다면, 순서가 헷갈릴 수 있음.

            레퍼런스 반환 함수의 반환 타입에 const를 붙여 if (a * b = c) 등의 오타로 인한 버그 방지.

            When in doubt, do as the ints do.

            인터페이스 사이의 일관성 잡아주기.

            팩토리 함수가 스마트 포인터를 반환하여 사용자가 객체 소멸이나, 직접 스마트 포인터를 생성치 않게 한다.

            특히, tr1::shared_ptr의 경우 교차 dll 문제를 해결해 준다.(객체 생성과 삭제를 다른 dll에서 할 때의 문제)


항목 19. 클래스 설계는 타입 설계와 똑같이 취급하자.

            좋은 타입은 일단 문법이 자연스럽고, 의미구조가 직관적이며, 효율적인 구현이 한가지 이상 가능해야 함.

            (1) 새로 정의한 타입의 객체 생성 및 소멸은 어떻게 이루어져야 하는가?

            (2) 객체 초기화는 객체 대입과 어떻게 달라야 하는가?

            (3) 새로운 타입으로 만든 객체가 값에 의해 전달되는 경우에 어떤 의미를 줄 것인가?

            (4) 새로운 타입이 가질 수 있는 적법한 값에 대한 제약은 무엇으로 잡을 것인가?

            (5) 기존의 클래스 상속 계통망에 맞출 것인가?

            (6) 어떤 종류의 타입 변환을 허용할 것인가?

            (7) 어떤 연산자와 함수를 두어야 의미가 있을까?

            (8) 표준 함수들 중 어떤 것을 허용하지 말 것인가?

            (9) 새로운 타입의 멤버에 대한 접근권한을 어느 쪽에 줄 것인가?

            (10) '선언되지 않은 인터페이스'로 무엇을 둘 것인가?

            (11) 새로 만드는 타입이 얼마나 일반적인가?

            (12) 정말로 꼭 필요한 타입인가?


항목 20. '값에 의한 전달'보다는 '상수객체 참조자에 의한 전달'방식을 택하는 편이 대개 낫다.

             사본을 만들어 내지 않는다.

             복사 손실 문제(slicing problem)가 없어짐

            (파생 클래스 객체가 기본 클래스 객체로서 전달될 때, 복사시 기본 클래스의 복사 생성자만 호출됨.)

            기본 제공 타입은 '값에 의한 전달'을 해도 그럭저럭 괜찮다.


항목 21. 함수에서 객체를 반환해야 할 경우, 참조자를 반환하려고 들지 말자.

            inline const A operator*(const A& lhs, const A& rhs) { return A(lhs...., rhs.....); }

            RVO(Return Value Optimization) - 반환 값 최적화

신고

'20130827이전 > EC++' 카테고리의 다른 글

항목 26 - 28  (0) 2012.12.22
항목 22 - 25  (0) 2012.12.22
항목 18 - 21  (0) 2012.12.21
항목 13 - 17  (1) 2012.12.21
항목 9 - 12  (0) 2012.12.21
항목 5 - 8  (0) 2012.12.18
Posted by 흰둥에미

최근에 달린 댓글

최근에 받은 트랙백

글 보관함