전체 글 검색 결과

해당 글 921건
항목 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
Exceptional C++ Style (익셉셔널 C++ 스타일 : ECPPS ) 목차

제1장 일반적 프로그래밍과 C++ 표준 라이브러리 1. vector의 올바른 용법과 잘못된 용법 2. 문자열 포매팅, 1부: sprintf 3. 문자열 포매팅, 2부: 표준의 세련된 대안들 4. 표준 라이브러리 멤버 함수 5. 여러 수준의 일반성, 1부: 기초 6. 여러 수준의 일반성, 2부: 충분히 일반적인가? 7. 함수 템플릿을 특수화하지 말아야 하는 이유 8. 템플릿 친구 만들기 9. export의 한계, 1부: 기초 10. export의 한계, 2부: 상호작용, 유용성 문제, 지침들 제2장 예외 안전성 문제와 기법 11. try와 catch 12. 예외 안전성: 추구할 가치가 있는가? 13. 예외 명세에 대한 실용적인 고찰 제3장 클래스 설계, 상속, 다형성 14. 순서의 중요성 15. 접근 권한..
책 정리/Exceptional C++ Style 2009. 2. 10. 05:34
항목 40 : 일체적 클래스의 해악, 4부 : std::string 대미 ( 난이도 : 6 )

1 ) std::string::erase가 비멤버 함수가 될 수 있을까? 2 ) std::string의 나머지 멤버 함수들을 분석하고, 비멤버 함수들로 만들 수 잇는지(또는 그렇게 하는 것이 좋은지) 설명하라 a. replace b. copy와 substr c. compare d. find 군(find, find_*, rfind ) 이렇게 질문이 있는데, 하나의 진리에서 나온 것들이다. "클래스 구현시, non-member, non-friend function 으로 만들 수 없는 함수만, member 함수로 만들어라." 이번 항목의 요약을 책에서 그대로 옮긴다. 분활과 캡슐화는 좋은것이다. 특히 C++의 경우에는, 알고리즘과 컨테이너를 분리시키는 것이 좋다. STL도 대부분 그런 원칙에 따라 만들어 졌다..
책 정리/Exceptional C++ Style 2009. 2. 10. 05:25