분류 전체보기 검색 결과

해당 글 921건
항목 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
항목 95 : C 스타일의 캐스팅은 사용하지 말라. ( Don’t use C-style casts. )

{ 정말 여러가지 이유가 있지만 대표적으로 꼽자면, 가독성이 떨어진다는 점과, reinterpret_cast 보다 더 강력한 cast 이기 때문이다. 그 강력함 중 하나를 설명한다. 포인터는 그 정의가 보이지 않더라도 전방선언으로 마치 보인것 처럼 컴파일러를 속여 컴파일 하게 할 수 있다. 이러한 상태에서 형 변환을 하게 되면, 정의가 보이지 않는데도 형 변환이 가능하게 된다. 이때 해당 정의가 보이지 않기 때문에 메모리 레이아웃을 맞추지 못하고 결국 어떤 일을 할지 모르는 포인터가 만들어 지게 된다. 그런데 VC 2008 에선 .. 잘 된다.. 해당 소스 코드를 첨부 하오니, 한번 테스트 해 보심이 좋을 것 같다. Func.cpp 의 7 라인에 break point 를 걸어서, dp의 멤버 변수가 있고..
책 정리/C++ Coding Standards : C++ 코딩의 정석 2009. 4. 16. 23:56
항목 94 : const 는 캐스팅 하지 말자. ( Avoid casting away const. )

{ 알다시피 메모리에는 상수성 메모리가 존재한다. 또한 개념상 상수성이여야 하는 경우도 있다. 이러한 이유로 const 로 설정된 것을 굳이 비상수성으로 만들어 사용할 이유가 없다.(물론 어쩔수 없을 때가 있긴 하다) 그러므로 상수성을 건들여서 버그가 생기거나, 예측할 수 없는 일이 일어나 하루 종일 디버깅을 하기 싫다면, 상수성만은 건들지 않는게 좋다. 대표적인 예를 한번 들어 보자. #include const char* str = "hello, world"; int main( void ) { std::cout
책 정리/C++ Coding Standards : C++ 코딩의 정석 2009. 4. 16. 23:51