부재 : 처리 비용의 거품을 빼자. (과도 선행 평가) 이유 1. 자주 요구되는 작업의 데이터는 미리 해두어, 프로그램 효율을 높일수 있다. 구현방법 1. 캐싱 예) 데이터 베이스에 접근 하려 할때 2. 미리가져오기 예) 시스템 프로세스를 사용 할때. 참조 1. STL의 반복자 it 으로 it->second 로 쓸수 있겠지만 STL의 반복자는 포인터가 아니라 객체이기 때문에 (*it).second 이 이식성 면에서 더 좋다 하지만 1995년 7월 STL 반복자는 -> 를 지원해야 한다고 했기 때문에 요즘은 ->를 써도 무난하다. 개인적인 생각 1. 지연 평가와 선행평가는 무엇을 쓰던 상관이 없을것 같다. 정작 중요한건 둘다 필요한 부분에서 쓸수 있다면 효율이 매우 높을거 같다. 2. 모든것을 즉시평가 기..
책 정리/More Effective C++ 1판 검색 결과
부재 : 해야 할 때만 하자. 이유 1. 최선의 속도를 내는 방법은 아무것도 하지 않는 것이기 때문이다. 구현 방법 1. 참조 카운팅(불필요한 객체 복사 피하기) 2.데이터 읽기와 쓰기를 구분하기(특화된 작업으로 처리하기) 3. 지연 방식의 데이터 가져오기(필요한 할때 필요한 부분만 읽어 오기) 4. 지연 방식의 표현식 평가(필요할 때에 필요한 값을 평가 하기) 주의점 1. 지연 평가는 만병 통치약이 아니다. 오히려 성능을 나쁘게 할때가 있다.(몰아서 처리 하려고 할때) 개인적인 생각 1. 확실히 미세튜닝으로 성능 향상을 노리는것 보다, 알고리즘을 더 개선시키는게 더 효율적이다.
부재 : 경험과 프로파일러를 사용하여, 20%를 찾아 내자. 이유 1. 코드의 20% 부분이 실행시간의 80%를 찾이 하기 때문이다. 2. 제일 효과적인 부분만 찾아내어 최적화를 하는것이 제일 효율이 높다. 구현 방법 1. 어느 부위에서 병목현상이 일어날지 경험을 쌓아라. 2. 프로파일러를 잘 쓰면 병목현상 부위를 찾는데 수월할 것이다. 개인적인 생각 1. .. 프로그래머에게 있어서 효율과 성능 개선은 .. 자존심이다.
부재 : 안전성인가? 속도인가? 햄릿에 고뇌에 빠져보자. 이유 1. 예외를 안쓰면 쓴것에 비해 속도도 빠르고 크기도 작다. 2. try 블록만으로 5~10% 실행속도가 저하된다. 3. 예외 지정 기능 역시 2번과 비슷한 저하가 일어 난다. 구형 방법 : 없음 주의 점 1. try 블록과 예외지정은 꼭 필요할 부분에서만 사용 한다. 2. 예외를 발생시키는 일도 진짜 예외적인 상황이라고 판단될때만 정의한다. 3. 예외 발생은 극히 드믈기 때문에, 예외 처리 비용에 대해서는 정확히 예측하기 힘들다. 4. 예외 처리에 비용이 든다는것을 알고, 경계를 늦추지 말면서 사용 해야 한다.
부재 : 예외지정을 알고나서 쓰자. 이유 1. 예외 지정 리스트에 없는 예외를 발생시킬 경우, 런타임 에러와 unexpected 함수 발생시켜 프로그램이 칼같이 종료될수 있음 구현방법 1. 템플릿에는 예외 지정을 두지 않는다 2. 예외 지정이 안 된 함수를 호출할 가능성을 가진 함수에는 예외 지정을 두지 않는다. 3. unexpected 를 다른 함수로 교체 한다.(set_unexpected()함수를 이용해서 바꿀수 있음) 주의점 1. 사용자는 예외지정의 일치성을 어기기가 쉽기 때문에, 뜨거운 가슴으로 부터 예외 지정을 해야 하는지 생각해 보고 써야 한다.
이유 1. 예외처리 중 객체의 유효범위(scope)를 벗어날수 있기 때문에 포인터로는 받을수 없다(있지만 복잡함) 2. 1번의 경우때문에 값을 복사 해서 넘기는 방법이 편하지만 효율적인 면에서 두번의 복사가 부담스러움 3. 2번의 경우는 슬라이스 문제(클래스 계통에 따른 정적복사는 값이 짤려 나갈 경우가 있음)가 도사리고 있음 구현 방법 1. try 에선 값으로 보내고 catch 에선 참조자(레퍼런스)로 받아 주면 된다. 코드 try { // Validation_error는 exception으로부터 파생 된 객체이다. 그러므로 임시 객체 생성된것을 전달함 if(유효성 검사 실패했을 경우) throw Validation_error(); 된것임 } catch (exception &ex) { // 처리 하고~..
최근댓글