SM's Development Log

실생활에서 대화를 할 때, 말을 유창하게 하는 것은 무척 어렵다.나의 생각을 논리정연하게 전달을 할 수 있어야,상대방과 원활한 의사소통이 가능할 것이다.그 방법 중 하나는 '문장 끝내기'라고 생각한다. 상대방과 대화를 하는 도중,상대방의 생각이 머릿속으로 정리가 잘 안된다 싶을 때,그 사람의 표현을 유심히 들어보면'~는데', '~는데'하며 문장이 계속 이어지는 경우가 있다.문장이 점점 길어짐으로써 생각을 정리할 틈을 주지 않는 것이다. 본인도 평소에 이런 부분을 계속 의식해서문장을 온전히 끝낸 후 다시 말을 이어나가고는 한다.말을 유창하게 하는 것이 어렵다면먼저 하나의 완전한 문장을 만드는 것부터 시작해보면 어떨까 싶다.

Programming Principles and Practice Using C++(비야네 스트롭스트룹 저) - 리뷰 Programming Principles and Practice Using C++대상 독자C++을 배우려고 하는 프로그래밍 입문자책 소개C++의 창시자 비야네 스트롭스트룹이 프로그래밍 입문자를 대상으로 쓴 책이다. 저자는 C++을 이용해 (책 제목처럼)프로그래밍의 원칙과 여러 노하우를 전수해주고 있다. 이 책에서는 C++11, C++14표준을 반영하여 모던 C++을 빠르게 익힐 수 있도록 도와주고 있다. 핵심 언어에서부터 표준 라이브러리의 대부분을 살펴보게 되므로, 이 책 한 권을 뗀다면 입문 수준은 뗄 것이라 생각한다. 또한, 상향식 접근으로 입문자에겐 어려울 수 있는 로우레벨보단 하이레..

Item23 - 멤버 함수보다는 비멤버 비프렌드 함수와 더 가까워지자챕터 핵심 내용멤버 함수보다는 비멤버 비프렌드 함수를 자주 사용하자.- 멤버 함수보다는 비멤버 비프렌드 함수를 자주 사용하자.객체 지향 법칙은 할 수 있는 만큼 데이터를 캡슐화 하는 것이다.캡슐화되는 것들이 많아지면, 그것들을 변경할 수 있는 여유도 많아진다.어떤 데이터를 접근하는 함수가 많으면 그 데이터의 캡슐화 정도는 낮은 것이다.비멤버 비프렌드 함수는 어떤 클래스의 private 멤버 부분을 접근할 수 있는 함수의 갯수를 늘리지 않는다.이름공간을 활용하자.편의 함수 전체를 여러 개의 헤더 파일에(그러나 하나의 이름공간에) 나누어 놓으면 편의 함수 집합의 확장도 손쉬워진다.

Item22 - 데이터 멤버가 선언될 곳은 private 영역임을 명심하자챕터 핵심 내용데이터 멤버는 private 멤버로 선언하자.protected는 public보다 더 많이 '보호'받고 있는 것이 절대로 아니다.- 데이터 멤버는 private 멤버로 선언하자.문법적 일관성을 제공한다.해당 데이터에 관해 접근 불가, 읽기 전용, 읽기 쓰기 접근을 우리가 직접 구현할 수 있다.캡슐화(encapsulation)클래스의 불변속성을 항상 유지하는 데 절대로 소홀해질 수 없게 됨.현재의 구현을 나중에 바꾸기로 결정할 수 있는 권한을 예약함.구현상의 융통성을 전부 누릴 수 있다.데이터 멤버를 읽거나 쓸 때 다른 객체에 알림 메세지를 보낸다거나클래스의 불변속성 및 사전조건, 사후조건을 검증하거나스레딩 환경에서 동기..

Item20_'값에 의한 전달'보다는 '상수객체 참조자에 의한 전달' 방식을 택하는 편이 대개 낫다챕터 핵심 내용지역 스택 객체에 대한 포인터나 참조자를 반환하는 일, 혹은 힙에 할당된 객체에 대한 참조자를 반환하는 일, 또는 지역 정적 객체에 대한 포인터나 참조자를 반환하는 일은 그런 객체가 두 개 이상 필요해질 가능성이 있다면 절대로 하지 마라.- 지역 스택 객체에 대한 포인터나 참조자를 반환하는 일, 혹은 힙에 할당된 객체에 대한 참조자를 반환하는 일, 또는 지역 정적 객체에 대한 포인터나 참조자를 반환하는 일은 그런 객체가 두 개 이상 필요해질 가능성이 있다면 절대로 하지 마라.지역 객체에 대한 참조자(혹은 포인터)를 반환하는 함수는 어떤 함수든지 프로그램의 핵폭탄이 된다.힙에 할당된 객체는 누군..

Item20_'값에 의한 전달'보다는 '상수객체 참조자에 의한 전달' 방식을 택하는 편이 대개 낫다챕터 핵심 내용'값에 의한 전달'보다는 '상수 객체 참조자에 의한 전달'을 택하자. 대체적으로 효율적일 뿐만 아니라 복사 손실 문제까지 막아준다.이번 항목에서 다룬 법칙은 기본제공 타입 및 STL 반복자, 그리고 함수 객체 타입에는 맞지 않다. 이들에 대해서는 '값에 의한 전달'이 더 적절하다.- '값에 의한 전달'보다는 '상수 객체 참조자에 의한 전달'을 택하자. 대체적으로 효율적일 뿐만 아니라 복사 손실 문제까지 막아준다.참조에 의한 전달 방식으로 매개변수를 넘기면 복사손실 문제(slicing problem)가 없어진다.복사손실 문제 : 파생 클래스 객체가 기본 클래스 객체로서 전달될 때, 값으로 전달되..

Item19_클래스 설계는 타입 설계와 똑같이 취급하자챕터 핵심 내용클래스 설계는 타입 설계이다.- 클래스 설계는 타입 설계이다.좋은 타입은 문법이 자연스럽고, 의미구조가 직관적이며, 효율적인 구현이 한 가지 이상 가능해야 한다.신경 써야 하는 질문들새로 정의한 타입의 객체 생성 및 소멸은 어떻게 이루어져야 하는가?답에 따라 생성자 및 소멸자, 메모리 할당 함수 설계가 바뀐다.객체 초기화는 객체 대입과 어떻게 달라야 하는가?초기화와 대입을 헷갈리지 말자.새로운 타입으로 만든 객체가 값에 의해 전달되는 경우에 어떤 의미를 줄 것인가?값에 의한 전달은 복사 생성자가 구현한다.새로운 타입이 가질 수 있는 적법한 값에 대한 제약은 무엇으로 잡을 것인가?클래스의 불변속성(invariant)을 잘 파악하고, 클래스..

Item18_인터페이스 설계는 제대로 쓰기엔 쉽게, 엉터리로 쓰기엔 어렵게 하자챕터 핵심 내용좋은 인터페이스는 제대로 쓰기에 쉬우며 엉터리로 쓰기에 어렵다.인터페이스의 올바른 사용을 이끄는 방법으로는 인터페이스 사이의 일관성 잡아주기, 그리고 기본제공 타입과의 동작 호환성 유지하기가 있다.사용자의 실수를 방지하는 방법으로는 새로운 타입 만들기, 타입에 대한 연산을 제한하기, 객체의 값에 대해 제약 걸기, 자원 관리 작업을 사용자 책임으로 놓지 않기가 있다.tr1::shared_ptr은 사용자 정의 삭제자를 지원한다. 이 특징 때문에 교차 DLL 문제를 막아 주며, 뮤텍스 등을 자동으로 잠금 해제하는 데 쓸 수 있다.- 좋은 인터페이스는 제대로 쓰기에 쉬우며 엉터리로 쓰기에 어렵다.사용자 쪽에서 뭔가를 외..

Item17_new로 생성한 객체를 스마트 포인터에 저장하는 코드는 별도의 한 문장으로 만들자챕터 핵심 내용new로 생성한 객체를 스마트 포인터로 넣는 코드는 별도의 한 문장으로 만들자. 이것이 안 되어 있다면, 예외가 발생될 때 디버깅하기 힘든 자원 누출이 초래될 수 있다.- new로 생성한 객체를 스마트 포인터로 넣는 코드는 별도의 한 문장으로 만들자. 이것이 안 되어 있다면, 예외가 발생될 때 디버깅하기 힘든 자원 누출이 초래될 수 있다.tr1::shared_ptr의 생성자는 명시적으로 선언되야 한다.함수 호출에 필요한 연산을 만들어 내는 코드는 실행되는 순서가 컴파일러 제작사마다 다르다.후기(postscript)C++11부터는 tr1에 있던 shared_ptr이 표준으로 들어왔다. 또한 위에 해당..

Item16_new 및 delete를 사용할 때는 형태를 반드시 맞추자챕터 핵심 내용new 표현식에 []를 썼으면, 대응되는 delete 표현식에도 []를 써야 한다. 마찬가지로 []를 쓰지 않았다면, delete에도 []를 쓰지 말아야 한다.- new 표현식에 []를 썼으면, 대응되는 delete 표현식에도 []를 써야 한다. 마찬가지로 []를 쓰지 않았다면, delete에도 []를 쓰지 말아야 한다.짝이 맞지 않는다면 미정의 동작을 일으킨다.new의 작동 원리메모리 할당할당된 메모리에 대해 한 개 이상의 생성자 호출delete의 작동 원리할당된 메모리에 대해 한 개 이상의 소멸자 호출메모리 해제힙에 만들어지는 단일 객체 메모리 레이아웃과 객체 배열의 메모리 레이아웃은 다르다.객체 배열의 메모리에는 배..