책 정리 검색 결과

해당 글 737건
항목 71 : 오류로부터 안전한 코드를 디자인하고 작성하라. ( Design and write error-safe code. )

항목 71 : 오류로부터 안전한 코드를 디자인하고 작성하라 { 라고 .. 책에는 적혀 있다. 번역하다가 Exception 이 오류라고 된거 같다. 본 내용은 예외로부터 안전한 코드를 디자인하고 작성하는 것을 이야기 하는 것이다. 개요 이 포스팅은 발생된 예외:Exception으로 부터 프로그램을 보호해야 하는 이유와 어떤 보호방법들이 있는지, 어떻게 보호해야 하는지에 대해서 정리해 둔 것이다. 본문 발생된 예외로 부터 왜 프로그램을 보호해야 하는가? 보호를 할지 말지는 프로그래머가 정하는 일이다. 만약 "나는 보호하지 않겠어" 라고 한다면, 이 포스팅을 읽지 않아도 된다. 예외가 발생 했을 경우, 그 예외는 자신의 지역에서 처리 할 수 있는 곳이 있는지 살펴보고, 있다면 그곳에 머물러 처리가 될 테니지만..
책 정리/C++ Coding Standards : C++ 코딩의 정석 2009. 4. 29. 13:56
항목 70 : 어디까지가 오류인지 명확히 해두자. ( Distinguish between errors and non-errors. )

{ 개요 에러란 무엇이고, 어디서 발생하는지 이해함으로써, 디버깅 능력 향상을 위해 정리하였습니다. 본문 에러란 무엇인가? 작업이 의도하지 않은 방향으로 가는 것, 이것을 에러라 한다. 이러한 작업의 최소한 단위는 함수인데. 함수가 의도하지 않는 방향으로 간다면, 에러가 발생했다고 봐야 한다. 어디까지 의도하지 않는 방향으로 가야 에러인가? 함수가 자신이 맡은 책임을 다하지 못하고, 다름 함수에게까지 도달한다면, 에러라고 봐야한다. 그렇다면 함수에 어떤 에러가 있을까? 1. 필요한 전제조건이 만족하지 못하고 함수를 호출하는 오류 2. 함수의 결과값이 정상적이지 않는 오류 3. 불변 의무를 가진 변수를 건들거나 복구하지 않는 오류 이러한 오류들이 존재한다. 말로만 설명하지 말고 코드을 보여 줄수 있는가? ..
책 정리/C++ Coding Standards : C++ 코딩의 정석 2009. 4. 28. 20:08
항목 69 : 합리적인 오류 처리 방식을 수립하고, 엄격히 그 방식을 따르라. ( Establish a rational error handling policy, and follow it strictly. )

{ 이 항목은 몸에 와 닿지 않는다. 아무래도 이런 개발 프로세스를 사용해 본적이 한번도 없기 때문이다. 회사에서 로그를 남기는 것으로 처리 하는게 아마도 이런 개발 프로세스 인것 같다. 이것이 왜 중요한가? 보통은 안써도 크게 무리 없지만 프로젝트의 규모가 커지거나, 프로젝트에 붙는 사람들의 숫자가 많아 질 수록 프로젝트의 관리도 더불어 힘들어 진다. 그러면서 디버깅은 점점 힘들어 진다. 만약 오류의 처리 방식, 보고 방식, 표현 방식이 정해져 있다면 좀 더 편할 것이다. 책에서는 모라고 하는가? 개발 초기에 먼저 정하고 개발하라고 한다. 어떻게 정하는가? 오류를 우선 식별하는 기준을 정한다. 예를 들어 babo_num > 30 이면 오류이다. 라고 정한다. 그리고 오류의 수준을 정한다. babo_nu..
책 정리/C++ Coding Standards : C++ 코딩의 정석 2009. 4. 17. 00:11
항목 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