[Effective C++ 3판] Chapter 3. 자원 관리 (항목 13~17)

Chapter 3. 자원 관리 정보처리산업기사 시험 & 시골에 제사지내러 내려가느라 포스팅이 늦었습니다 ㅠㅜ 이번 Chapter는 자원 관리입니다. C++의 자원 관리 철학은 RAII이죠~ 객체가 생성되고 소멸될 때 생성자와 소멸자가 호출되는 원리를 이용하여 자원과 객체의 life cycle을 동일시함으로서 더욱 더 편리하고 안정적으로 자원 관리를 할 수 있습니다! 항목 13 : 자원 관리에는 객체가 그만! std::shared_ptr의 소멸자는 기본적으로 내부적으로 delete를 사용합니다. (delete[]가 아니라) 그래서 동적할당된 배열에 대해 std::shared_ptr를 사용하면 안됩니다. 대신에 std::vector나 C++11의 std::array 를 사용함으로서 raw array를 대신하는 방법이 있습니다. 또는 std::shared_ptr의 생성자에 custom deleter를 등록하는 방법이 있습니다. http://stackoverflow.com/questions/13061979/shared-ptr-to-an-array-should-it-be-used [ 이것만은 잊지 말자! ] - 자원 누출을 막기 위해, 생성자 안에서 자원을 획득하고 소멸자에서 그것을 해제하는 RAII객체를 사용합시다. - 일반적으로 널리 쓰이는 RAII 클래스는 tr1::shared_ptr (C++11부터 표준이 되어 std::shared_ptr로 쓰면 된다.) 그리고 auto_ptr (C++11부터 deprecated되었다. 대신에 대체재로서 std::unique_ptr를 사용하면 된다.) 입니다. 항목 14 : 자원 관리 클래스의 복사 동작에 대해 진지하게 고찰하자. RAII객체가 복사될 때 어떤 동작이 이루어져야 할까요? - 복사를 금지합니다. (Uncopyable 클래스 상속, =delete 활용) - 관리하고 있는 자원에 대해 참조 카운팅을 수행합니다. (custom deleter와 함께 std::shared_ptr를 활...

[Effective C++ 3판] Chapter 2. 생성자, 소멸자 및 대입 연산자 (항목 5~12)

Chapter 2 . 생성자, 소멸자 및 대입 연산자 항목 5 : C++가 은근슬쩍 만들어 호출해 버리는 함수들에 촉각을 세우자. 항목 6 : 컴파일러가 만들어낸 함수가 필요 없으면 확실히 이들의 사용을 금해 버리자. 이러한 것과 관련된 규칙으로서 rule of three/five/zero 라는 것이 있다. 아래 링크 참조. http://en.cppreference.com/w/cpp/language/rule_of_three https://en.wikipedia.org/wiki/Rule_of_three_(C%2B%2B_programming) [ 정리해 두고 싶은 것 & 추가적인 사항 ] // C++11에서는 =delete를 사용하면 되긴 하지만, 책을 읽다가 인상깊어서 남겨본다. // 부스트에도 비슷하게 noncopyable이라는게 있다고 한다. class UnCopyable { protected: UnCopyable() {} ~UnCopyable() {} private: // 선언만 함으로서 friend에 대해서도 안전성 확보. UnCopyable(const UnCopyable&); UnCopyable& operator=(const UnCopyable&); }; class Example : private UnCopyable { }; [ 이것만은 잊지 말자! ] - 컴파일러는 경우에 따라 클래스에 대해 기본 생성자, 복사 생성자, 복사 대입 연산자, 소멸자를 암시적으로 만들어 놓을 수 있습니다. (C++11에서는 이동 생성자, 이동 대입 연산자가 암시적으로 생성될 수 있다. - 컴파일러에서 자동으로 제공하는 기능을 허용치 않으려면, 대응되는 멤버 함수를 private로 선언한 후에 구현은 하지 않은 채로 두십시오. Upcopyable과 비슷한 기본 클래스를 쓰는 것도 한 방법입니다. (C++11에서는 =delete 를 활용하자.) 항목 7...

[Effective C++ 3판] Chapter 1. C++에 왔으면 C++의 법을 따릅시다. (항목 1~4)

이미지
앞으로 Chapter별로 포스팅을 할 계획이다. 책의 내용을 완벽하게 정리하려는게 목적은 아니다. 내가 잘 몰랐던 것과 헷갈리는 것을 위주로 해서 개인적인 생각과 궁금한 것에 대한 추가적인 실험/연구 결과를 정리해나갈 것이다. Chapter 1. C++에 왔으면 C++의 법을 따릅시다. 항목 1 : C++를 언어들의 연합체로 바라보는 안목은 필수. [ 이것만은 잊지 말자! ] - C++을 사용한 효과적인 프로그래밍 규칙은 경우에 따라 달라집니다. 그 경우란, 바로 C++의 어떤 부분을 사용하느냐입니다. 항목 2 : #define을 쓰려거든 const, enum, inline을 떠올리자. #define에게는 유효범위라는 게 없다. 이 점 때문에 외부 라이브러리와 #define이 겹쳐서 고생한 기억이 여러 번 있다. (부들부들..) 그리고 #define은 그냥 단순 치환방식이기 때문에 매우 불안하다. 따라서 상수를 정의할 때는 const 변수를 사용하는 것이 좋다. 혹은 정수 타입에 해당하는 상수를 위해서 나열자 둔갑술 (enum hack)을 사용하는 방법도 있다. 나열자 둔갑술은 단순히 enum { ... }; 이런식으로 선언함으로서 해당 namespace에 한해서 정수형 상수를 정의할 수 있는 방법이다. [ 정리해 두고 싶은 것 & 추가적인 사항 ] - 정적 멤버로 만들어지는 정수류 타입의 클래스 내부 상수는 '정의'가 없어도 된다. [ 이것만은 잊지 말자! ] - 단순한 상수를 쓸 때는, #define보다 const 객체 혹은 enum을 우선 생각합시다. - 함수처럼 쓰이는 매크로를 만들려면 #define 매크로보다 인라인 함수를 우선 생각합시다. 항목 3 : 낌새만 보이면 const를 들이대 보자! [ 정리해 두고 싶은 것 & 추가적인 사항 ] // 컴파일러는 비트수준 상수성만 보장해준다. // 우리는 논리적 상수성을 고려해서 프로그래밍해야한다. cla...

[Effective C++ 3판]

http://book.naver.com/bookdb/book_detail.nhn?bid=2485839 C++을 주력언어로 사용하면서도 그 유명한 Effective 시리즈를 읽은 적이 없다. 그래서 Effective C++ 부터 시작해 More Effective C++, Modern Effective C++ 책을 쭉 읽으면서 블로그에 정리할 계획이다! 일단 Effective C++부터!! Effective C++ 3판은 2006년에 번역되어 나온 책이다. 원서는 http://book.naver.com/bookdb/book_detail.nhn?bid=1546778 로서 2005년에 나왔다. 10년이 넘어서 현재는 Modern C++이 나온 상태이지만, 이 책이 그렇다고 구닥다리같은 책은 아니다. 여전히 많은 것을 배우고 느낄수 있는 책이다. 총 55개의 항목으로 되어있고, 9개의 챕터로 이루어져있다. < 포스팅 리스트 > Chapter 1. C++에 왔으면 C++의 법을 따릅시다. (항목 1~4) Chapter 2. 생성자, 소멸자 및 대입 연산자 (항목 5~12) Chapter 3. 자원 관리 (항목 13~17) Chapter 4. 설계 및 선언 (항목 18~25) Chapter 5. 구현 (항목 26~31) Chapter 6. 상속, 그리고 객체 지향 설계 (항목 32~40) Chapter 7. 템플릿과 일반화 프로그래밍 (항목 41~ 48) Chapter 8. new와 delete를 내 맘대로 (항목 49 ~ 52) Chapter 9. 그 밖의 이야기들 (항목 53 ~ 55) 포스팅 완료 포스팅에서 사용한 코드들은 Github에 올렸습니다. ( https://github.com/taeguk/Effective-Cpp-Series ) 단, 포스팅에 올린 거랑 약간 다를수도 있습니다.

BeautifulSoup4를 relative import하는 방법

이미지
BeautifulSoup4를 relative import 할 일이 있었다. 근데 하려했는데 안됐다. (4.4.0, 4.4.1 버전을 이용해봤는데 둘 다 안됐다.) 그 이유는 bs4/builder/__init__.py 에서 from bs4.element import ... 을 하기 때문이다. 즉, bs4 내부 코드에서 bs4의 하부 모듈을 import할 때, 절대경로로 import하기 때문이다.  이 것을 from ..element import ... 처럼 상대경로로 import하도록 수정해야 문제가 발생하지 않는다. 내부적으로 이런 코드가 얼마나 존재할 지를 몰라서, 아래와 같은 코드를 bs4 내에 추가하여 해결하였다. 하지만 이는 깔끔한 해결책은 아니고, 실제로 bs4 내에서 bs4의 하부모듈을 import할 때 relative import를 하도록 코드를 수정해야지 진정한 해결책이 될 것이다. bs4/builder/__init__.py 의 맨 위에 추가 bs4/__init__.py 의 맨 위에 추가 실제로 내가 이 문제를 만났을 때에는 전역적으로 bs4가 설치되어 있어서 위와 같은 import에러는 안뜨고 자꾸 html.parser가 없다는 이상한 에러가 떴다. 그래서 bs4의 코드를 순차적으로 따라가면서 겨우 근본적인 원인을 찾아냈다... ㅠㅠ https://groups.google.com/forum/#!topic/beautifulsoup/n1bFLxqn7SE 그래서 일단 이런 이슈를 community에 남겨놓았다. 혹시 이 것이 나중 버전에 반영이 될 지 안 될지는 모르겠지만,  반영이 안되더라도 bs4를 relative import하고 싶을 땐 위와 같이 하면 될 것 같다.

README.rst가 pypi.python.org에서 formating이 안될때

이미지
README.rst가 pypi.python.org에서 formating이 안되서 구글에 검색을 해봤다.. (깃허브에서는 잘 나왔다.) http://stackoverflow.com/questions/16367770/my-rst-readme-is-not-formatted-on-pypi-python-org http://stackoverflow.com/questions/17401132/restructuredtext-readme-rst-not-parsing-on-pypi 등등... 아무리 봐도 해결책이 안나온다.... 그래서 70줄가까히 되는 README.rst에서 바이너리서치 형태로 대체 어느 줄이 잘 못 됐는지 알아냈다. 수정 전 수정 후 후... 부들부들....  저렇게 하니까 된다....

[Windows Via C/C++] 1독 끝....!

Windows Via C/C++ 1독을 마쳤다~ 사실 마지막 두 챕터는 그냥 스킵하다시피 읽었다... 나중에 필요해지면 참고해도 될만한 내용들??같아서... ㅋㅋㅋ 사실 너무 읽기가 싫었다ㅠㅠ 사실 1독을 마친 것은 한 달전인데, 지금에서야 포스팅을 한다~  윈도우즈 시스템 프로그래밍의 바이블로서 워낙 유명한 책이라 어려울 줄 알았는데 막상 읽어보니 생각보다 어렵지 않았다. 아마 3년 반전부터 윤성우씨 책으로 접해왔던 탓에 아는 내용이 어느정도 있어서 그런 것도 있지만 사실 책 자체가 그렇게 어려운 책은 아닌 것 같다. 물론 지엽적인 내용들은 꽤 많았다. 사실 그런 부분이 현업 개발자나 당장 필요한 사람들에게는 큰 장점이 될 수도 있지만, 나의 경우와 같이 큰 그림을 그리고 전체적인 이해를 우선적으로 하는 사람들에게는 오히려 방해가 되기도 한다. 만약 자신이 윈도우즈 시스템 프로그래밍이 처음이라고 하면 윤성우님의 '윈도우즈 시스템 프로그래밍' 이라는 책을 먼저 읽어보기를 권장한다. 그 책을 먼저 이해한 후 Windows Via C/C++을 읽으면 훨씬 좋을 것 같다 ㅎㅎㅎ  사실 이 책은 원서기준으로 2007.12.12에 5판을 끝으로 더 이상 개정판이 나오지 않고 있다. 대신에 .NET framework기반의 "CLR via C#" 시리즈가 꾸준히 발매되고 있다. 사실상 이 책이 제프리 리처의 네이티브 어플리케이션을 다루는 마지막 책인 것이다. (하지만 개인적으로 최근 내용까지 업데이트되어 6판이 출판되었으면 좋겠다는 마음을 가지고 있다...ㅠㅠ)  사실 요즘 C/C++로 windows api를 직접적으로 이용하여 개발을 하는 경우가 별로 없다. 대부분 다른 라이브러리를 이용해서 개발을 하던가, .Net framework기반에서 C#으로 개발하는 경우가 많은 것 같다. "당장 써먹을 부분"이 없다는 점에서 native programming과 시스템 프로그래밍에 대한 공부를 하는 사람들이 적어지는...