CPPCS 검색 결과

해당 글 85건
항목 68 : 내부적인 가정과 규칙을 확실하게 명시하라. ( Assert liberally to document internal assumptions and invariants. )

{ 즉, 자신 또는 우리가 만들어 놓은 프로그램이 올바르게 작동하기 위해서 내부적인 가정과 규칙을 확실하게 명시해 둘 필요가 있다는 이야기이다. 여기서 말하는 규칙과 가정은 무엇을 말하는가? 오류의 보고와 오류의 표현, 오류의 범위을 뜻한다. 이것을 왜 확실하게 명시해야 하는가? 나 혼자 작업을 한다면, 일관성 있게 유지해야 함은 나 자신에게 무척 도움이 된다.(나중에 봐도 알 수 있으니까) 마찬가지로 팀에서도 명시된 룰을 적용하면, 모두가 좋다. 대표적으로 assert를 사용하는 사람과 사용하지 않는 사람이 같이 작업을 했다고 했을 때, 릴리즈 모드와 디버깅 모드에서 다른 결과를 볼 수 있는 것을 예로 들 수 있다. 그러므로 확실하게 명시하는 편이 좋다. 부수적인 이야기 assert 이야기가 나와으니 ..
책 정리/C++ Coding Standards : C++ 코딩의 정석 2009. 4. 17. 00:09
항목 99 : 올바르지 않은 개체와 안전하지 않은 함수는 사용하지 말라. ( Don’t use invalid objects. Don’t use unsafe functions. )

{ 올바르지 않은 개체는 무엇을 뜻하는가? 제거된 객체, 소멸자가 이미 호출된 객체, 핸들의 대상이 사라진 핸들, 형 변환을 통해서 얻은 데이터 등이 있다. 그렇다면 안전하지 않은 함수는? sprintf, memcpy 등 범위 검사가 전혀 없으면서 메모리 작업을 하는 함수들이 있다. 그러면 어떻게 해야 하는가? 간단하다, boost 라이브러리를 적극 활용하거나, 안쓰면 된다. ㅋㅋ 실제로 이 이야기는 KGC2008 컨퍼런스에 갔다가, 마소에서 나온 어떤 개발자를 통해서 들었다. 관련링크 http://www.ikpil.com/710 }
책 정리/C++ Coding Standards : C++ 코딩의 정석 2009. 4. 17. 00:06
항목 98 : 가변 인자의 사용을 피하라. ( Don’t use varargs (ellipsis). )

{ C++ 에서도 가변 인자가 필요한 경우가 있긴 있다. 하지만 C++ 높은 수준의 구조체나 boost 라이브러리 등을 이용하면 굳이 사용하지 않아도 된다. 그렇다면 왜 사용하지 말아야 하는가? 그 이유는 타입 안전성에 약하다. 일단 가변 인자는 타입 안전성 검사를 모두 중단하는 것이다. 그리고 프로그래머가 그 가변 인자를 관리해 주어야 한다. 역시 귀찮은 작업이다. 그리고 클래스 타입의 개체에 대한 결과는 예상하기 힘들다. .. 가변인자를 클래스의 개체를 넣는다면 .. 정말 그 결과를 예상하기 힘들다. 마지막으로 인자의 갯수를 아는 방법이 없다. 하지만 sprintf 등의 함수류에서 무척 간편하게 사용하기도 하고, 로그를 남길 때라든지 무척 편하다는 장점이 있다. 자, 선택은 자신의 몫! 아 그리고 b..
책 정리/C++ Coding Standards : C++ 코딩의 정석 2009. 4. 17. 00:04
항목 97 : union 사용을 주의하라. ( Don’t use unions to reinterpret representation. )

{ union 이 무엇인지 안다면, 어떨때 에러가 나는지 알 수 있을 것이다. union 은 사실 같은 데이터형의 확장을 하나의 형에 몰아 넣어 호환성을 극대화 할 때 사용하면 매우 좋다. .. 물론 이렇게 말만 하니 무슨 말인지 모를 것이다. 다음 예제를 보자. #include #include // 소켓 주소 담는 곳 union addr_system { sockaddr base; sockaddr_in v4; sockaddr_in6 v6; SOCKADDR_STORAGE storage; }; int main( void ) { addr_system addr_; } 이렇게 정의 하면 bind 나 기타 다른 sockaddr 이 필요한 곳에 &addr_.base; 로만 넘겨 줘도 된다. 또한 경우가 바뀌여서 v6..
책 정리/C++ Coding Standards : C++ 코딩의 정석 2009. 4. 17. 00:02
항목 96 : POD가 아닌 데이터를 memcpy 또는 memcmp하지 말라. ( Don’t memcpy or memcmp non-PODs. )

{ 뭐 다들 알겠지만 C++ 에선 클래스의 내부 값이 스마트 포인터, 각종 핸들, 카운팅 객체, 상속성 객체 등이 즐비하므로, memcpy 했다가 정체를 알수 없는 행동을 한다거나 memcpy 했다가 같은 것임에도 다르다고 비교 될 수 있는 경우가 반드시 생긴다. KGCA15기 임훈 형이 만든, 메모리 풀(물론 공부 목적으로 만든 것이다)에서 문제점이 없는지 찾아 봐달라고 요청이 왔을 때, 문제점의 냄새는 맡았으나, 어떤 냄새인지 정의를 내리지 못하였다. 그런데 이 책을 보다가 아! 이거구나! 했었다. 그런데 사실 memcpy 나 memcmp 를 사용한 적이 별로 없더라 ... }
책 정리/C++ Coding Standards : C++ 코딩의 정석 2009. 4. 17. 00:00