책 정리/Effective C++ 3판 검색 결과

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

내가 C++에 조예가 깊어서 글을 남기는 것이 아니라, Effecitve C++ 을 공부하는 사람들이 이 글을 보고, 도움이 되었으면 하는 생각과, 혹시 내가 틀린것이 있다면 지적해 주시지 않을까 란 생각으로 글을 올리는것임을 미리 밝힙니다. - 최익필 이번 항목의 주제는 "템플릿의 최대의 적 코드 비대화를 막는 원리" 에 대해서 이다. 이게 무슨 말인지 모르겠다면, 아래 예저 코드를 통하여, 실제로 컴파일 용량을 확인해 보도록 하자. 예제 1 : 코드 비대화를 보여주는 템플릿 아용 사례, MSVC2005 Debug Mode : 88KB // ikpil.com or ikpil.tistory.com #include // 템플릿의 타입 매개변수와 비타입매개변수 template //
책 정리/Effective C++ 3판 2008. 7. 30. 13:32
항목 43: 템플릿으로 만들어진 기본 클래스 안의 이름에 접근하는 방법을 알아 두자.

내가 C++에 조예가 깊어서 글을 남기는 것이 아니라, Effecitve C++ 을 공부하는 사람들이 이 글을 보고, 도움이 되었으면 하는 생각과, 혹시 내가 틀린것이 있다면 지적해 주시지 않을까 란 생각으로 글을 올리는것임을 미리 밝힙니다. - 최익필 이번 항목의 주제는 "템플릿 기반 클래스를 상속받은 파생 클래스는 '컴파일 타임 상속 체계'가 끊긴다. 그러므로 템플릿 기반 클래스에 접근 하는 방법을 알아 두어야 한다." 이다. 이 컴파일 타임 상속 체계는 컴파일 타임에 컴파일러가 구문해석 체계를 뜻한다. 구문해석 체계에서 잘못 된 것이라면, 컴파일이 되지 않는다. 템플릿 기반 클래스 상속은 상속에 따른 구문해석이 끊기어, 해석 실패가 된다. 못 믿겠다면 예제 코드를 보자. // ikpil.com or..
책 정리/Effective C++ 3판 2008. 7. 28. 02:21
항목 42: typename의 두가지 의미를 제대로 파악하자.

내가 C++에 조예가 깊어서 글을 남기는 것이 아니라, Effecitve C++ 을 공부하는 사람들이 이 글을 보고, 도움이 되었으면 하는 생각과, 혹시 내가 틀린것이 있다면 지적해 주시지 않을까 란 생각으로 글을 올리는것임을 미리 밝힙니다. - 최익필 typename .. 뭐 이렇게만 보면 이런게 있었나 싶다. 하지만 템플릿에서는 흔하게 보는 키워드인데, 이 키워드에 대해서 제대로 파악하자고 하는것 같다. 처음부터 진행하자면 typename 과 class 는 똑같은 의미인데, 이렇게 말만 하면 혼동의 요지가 있으니, 코드도 포함해 주는 센스를 발휘해 본다. // ikpil.com or ikpil.tistory.com #include //template // class _T 와 같은 의미 template..
책 정리/Effective C++ 3판 2008. 7. 25. 21:34
항목 41: 템플릿 프로그래밍의 천릿길도 암시적 인터페이스와 컴파일 타임 다형성부터

내가 C++에 조예가 깊어서 글을 남기는 것이 아니라, Effecitve C++ 을 공부하는 사람들이 이 글을 보고, 도움이 되었으면 하는 생각과, 혹시 내가 틀린것이 있다면 지적해 주시지 않을까 란 생각으로 글을 올리는것임을 미리 밝힙니다. 항목 41의 이야기를 어떻게 풀어 갈지, 감이 오지 않았다. 그 이것은 항목 41을 잘 이해하지 못했다는 것을 증명하기라도 하듯, 나는 책을 여러번 반복해서 읽을 수 밖에 없었다. 시작하기 앞서 한가지만 기억하자, 템플릿 프로그래밍은 모두 컴파일 타임에 결정 된다! 나머지는 그냥 읽기만 하자. 어찌 보면 이 한가지 기억은 Goto 같은 녀석이다.. ..(왜 컴파일 타임에 결정하느냐? 라고 하면 .. 별도로 템플릿 프로그래밍에 관련된 책을 구입하여 공부하는게 좋을듯 ..
책 정리/Effective C++ 3판 2008. 7. 25. 17:53
항목 40: 다중 상속은 심사숙고해서 사용하자.

내가 C++에 조예가 깊어서 글을 남기는 것이 아니라, Effecitve C++ 을 공부하는 사람들이 이 글을 보고, 도움이 되었으면 하는 생각과, 혹시 내가 틀린것이 있다면 지적해 주시지 않을까 란 생각으로 글을 올리는것임을 미리 밝힙니다. 본론으로 들어와서, 나는 설계 단계에서 다중 상속 할까낭~ 하는 생각을 한적은 있었지만, 지금까지 다중 상속을 해서 코딩한적은 없다. 왜냐하면, 일단 설계단계 조차 난해하고, 조금 복잡해지는 경향이 있었다. 그래서 스스로가 "지금 여기에 꼭 필요한가?" 란 질문에 항상 "지금은 아니오" 라고 답하곤 했기 때문이다. 이번 항목 40의 제목처럼 "다중 상속은 심사숙고해서 사용하자" 로 이야기 하고 있다. 그렇다면 나는 이런 생각을 하곤 한다. "왜!? 무엇 때문에!?"..
책 정리/Effective C++ 3판 2008. 7. 25. 01:00
항목 39 : private 상속은 심사숙고해서 구사하자

public 상속이나 protected 상속, private 상속일 때, 인터페이스(접근 할 범위)가 어떻게 바뀌는지 안다는 전제하에서 이야기를 진행한다. private 상속은 (is-implemented-in-terms-of) 패턴을 뜻한다. 즉, ...는 ...를 써서 구현되었다 라고 할수 있다. 38항목에 자세하게 적어 두었으니 읽어 보면 도움이 될 듯 하다. 자 소스 코드가 있어야 이해가 될듯 하여, 소스코드를 포함한다. #include class Ctest { protected: Ctest( ) : a( 1 ) { std::cout
책 정리/Effective C++ 3판 2008. 7. 19. 06:33