책 정리/C++ Coding Standards : C++ 코딩의 정석 검색 결과

해당 글 102건
항목 10 : 전역 데이터와 공유 데이터를 최소화하라. ( Minimize global and shared data. )

이런 정석에는 항상 "왜!?" 라는 것이 따라 다니는데... "전역 데이터"를 왜 최소화 해야 하는가? 전역 데이터는, 전역 네임스페이스에 있는 데이터로써, 어디에서건 접근 할 수 있다. 이 말만 들으면, 아주 좋은 자리에 줄을 선 데이터 이다. 하지만 이 "어디에서건"이 매우 복잡한 상태를 초래하게 된다. 자리가 매우 좋으니, 어디에서건 값을 수정 할 수 있게 된다. 그래서 그 값이 왜 어떻게 언제 수정되었는지 알기가 매우 힘들어 진다. 이런 것이 "아느니 모르니만 못하다" 라는 소리를 듣는 경우이다. 그렇다면, "공유 데이터" 는 무엇을 말하는 것일까? 바로 클래스의 멤버 데이터를 말한다. 이것은 또 왜 문제인가? 바로 전역 데이터 처럼 쓰여지니 문제가 똑같이 된다. 경험으로는. private 멤버 ..
책 정리/C++ Coding Standards : C++ 코딩의 정석 2009. 2. 11. 18:29
항목 9 : 미리 최적화해두어야 할 부분도 있다. ( Don’t pessimize prematurely. )

성급하게 비관하지 마라. 불필요한 복사 생성자를 호출하게 한다든지, 루프내에 불필요한 작업을 한다든지, ..... 뭐 기본적인 내용이다. 이런것들은 디자인을 크게 해치지 않으며, 보기에도 불편한게 아니므로, 크게 생각되지 않는다. Effective C++, Exceptiona C++, 등에 이런 자세한 것들이 많이 나오니, 여기서는 이렇게 정리~ 총평 음..~?
책 정리/C++ Coding Standards : C++ 코딩의 정석 2009. 2. 11. 16:45
항목 8 : 이른 최적화를 피하라. ( Don’t optimize prematurely. )

라틴 속담 채찍을 때린다고 말이 달리고 싶어지는 것은 아니다. 시작을 "라틴 속담"으로 했는데, 그 이유는, 최적화를 한다고 해서, 그게 최적화가 꼭 되는게 아니라는 말을 하고자 함에 있다. 이번 항목은, 이른 최적화가 왜 좋지 않은지, 무엇이 더 좋은 최적화 인지를 논하는 항목이다. 이른 최적화는 디자인과 코드를 보다 복잡하게 만들고 읽기 힘들게 하며, 비록 성능상에 이점이 있다 해도, 최종 목적이 되는 결과물과 비교해서 더 좋은 성능을 발휘하는 경우는 극히 드믈다. 만약, 코드를 변경하게 될 일이 생기게 될 경우, 더 변경이 까다롭게 된다. 이는 다음의 말을 생각나게 한다. "빠른 프로그램을 정확한 프로그램으로 바꾸는 것보다, 정확한 프로그램을 빠른 프로그램으로 바꾸는게 훨씬 쉽다" 그리고, 최적화를..
책 정리/C++ Coding Standards : C++ 코딩의 정석 2009. 2. 11. 16:21
항목 7 : 적절한 규모 유지를 위해서는 '언제, 어떻게'를 아는 것이 중요하다. ( Know when and how to code for scalability. )

여기서 말하는 "적절한 규모" 는 데이터의 처리 속도의 규모 이다. 즉 성능인데, 이 성능은 빠를 수록 좋다. 책에선 '언제, 어떻게'를 아는게 중요하다.란 이야기를 하는 것이다. 그렇다면 여기서 말하는 성능 최적화의 '언제'는 언제인가? '언제'를 알 기란 매우 어려운데, 수 많은 책에서는 '언제'에는 절대 속하지 않을 때가 있다고 한다. 바로 '초기' 이다. 프로그램 코딩의 초기에는 데이터 처리 성능엔 신경을 쓰지 말라고 한다. 왜냐하면, '이른 최적화는 항상, 프로그램이 복잡해 지기 때문' 이라 한다. 그러면 초기에 무엇을 염두해야 하는가? 바로 '얼마나 더 간결하고, 얼마나 더 정확한지' 이다. 그러면 '일반적인 답'이 나왔다. 바로, '프로그램 초기에는 최적화를 하지 않는다' 이다. : ) 그러..
책 정리/C++ Coding Standards : C++ 코딩의 정석 2009. 2. 11. 13:56
항목 6 : 정확성, 간결성, 명확성을 먼저 생각하라. ( Correctness, simplicity, and clarity come first. )

이 정석은 평생 가장 익히기 힘든 것 중에 하나이다. 명언만 써도 바로 이해 될 수 있는 항목일 것이다. 프로그램은 사람이 읽을 수 있또록 쓰여져야 하고, 컴퓨터가 실행할 수 있도록 하는 것은 그 후의 문제이다. - 헤롤드 아벨슨, 제랄드 제이 수스맨 프로그램을 쓸 때는 사람을 먼저 생각하고, 컴퓨터는 두 번째로 생각하라 - 스티브 맥코넬 컴퓨터 시스템의 가장 값싸고, 빠르고 안정적인 구성 요소는 바로, 없는 요소이다 - 고든 벨 빠진 구성 요소야말로 가장 정확한 요소이며(절대 실수하지 않으므로), 가장 안전한 요소이며(부서질 수 없으므로), 디자인하고, 문서화하고, 테스트, 관리하기 가장 쉬운 요소이다. 간결한 디자인의 중요성은 아무리 강조해도 디나치지 않다. - 존 베틀리 이 모든 말은 "하나를 표현..
책 정리/C++ Coding Standards : C++ 코딩의 정석 2009. 2. 6. 03:45
항목 5 : 하나의 엔티티에는 하나의 역활만을 부여하자. ( Give one entity one cohesive responsibility. )

나는 이것을 첫번째 프로젝트 진행 중에 깨닫게 되었다. 1942 게임을 만드는 중에, 연산과 출력, 즉, 비행기의 이동과 비행기의 그림 출력을 하나의 Loop 안에 넣고 돌리고 있었다. 처음, 비행기의 이동과 비행기의 출력을 하나의 함수안에 하나의 루프안에 넣고 나서, 비행기의 이동에 따른 출력을 정상적으로 처리 했으나, 추가적으로 총알의 출력을 처리해야 될 때, 함수 안이 점점 복잡해 졌다. 명언 중에, 바보는 복잡한 것을 무시하고, 현실주의 자는 복잡한 것을 피하거나 괴로워 하고, 천재는 복잡한 것을 없앤다 - 앨런 펄리스가 했던 것이 기억이 난다. 바로 이런 상황이 "복잡한 것" 이다. 복잡한 것은 어디를 수정하든, 다른 곳도 수정해야 "정상적"으로 되는 상황을 뜻한다. 이게 물의 파장처럼 계속 퍼..
책 정리/C++ Coding Standards : C++ 코딩의 정석 2009. 2. 6. 03:22