항목 33. 인라인을 선별적으로 사용하라. 우선 인라인 함수란? http://janine.egloos.com/1330489 http://blog.naver.com/phoogu?Redirect=Log&logNo=110017171831 트랙백도 추가해 주는 센스! 이유 1. 코드의 크기가 증가되어, 실행파일의 크기가 크게 된다. - 이 때문에 실행시 많은 작업을 하게 된다. 2. 명령어 캐시의 적중률을 감소시켜 캐시 메모리에서 메인 메모리로의 명령어 페치 속도를 떨어뜨린다. - 명령어 캐쉬란? CPU에 보면 L1 캐쉬 L2 캐쉬 등이 있는데, 여기에 이 명령어들이 올라간다. 그리고 명령어를 기억해두었다가 같은 명령어가 들어오면 바로 수행하게 되지만, ... 인라인의 남용으로 계속 이 명령어 캐쉬가 바뀌므로써..
Effective C++ 검색 결과
항목 32. 변수 정의는 가능한 뒤로 늦춰라 우선 1. C 철학에 따르자면 변수의 정의는 블록의 시작부분에 놓아야 한다! 필자는 이제 그 철학은 버리라고 말한다(.. 여간 내기가 아닌데!) 이유 1. 부담스럽다. - 변수 선언은 생성자를 동반하고, 소멸자도 동반한다. 많으면 많을수록 부담스럽다. 2. 부자연 스럽다. - 아직 쓰지도 않을 변수를 미리 하여, 가독성을 떨어 뜨린다. 해결 방법 1. 가능한 변수 정의가 필요할때까지 코딩하다가 필요할대만 정의하여 사용한다! 필자의 생각 1. 이제 블록을 열자마다 변수를 정의하는 습관자체를 버릴 때다! 개인적 생각 1. 조건문 안에서는 변수 선언이 안된다! 잘 파악해서 최대한 미루어 변수 선언하라는 뜻이다. 1. 확인해 보았는데, VC2005 C++ 에서 조건문..
항목 31. 지역 객체에 대한 참조나 함수 내에서 new를 이용해 초기화된 포인터를 가리키는 참조를 리턴하지 말라 : 정말 제목을 자세하게 적었다.. 이유 1. 항목 29와 중복 2. new에 대해선 관리가 상당히 까다롭게 변한다. (빈대 잡으려다 집태운 격, 배보다 배꼽이 큰 격) 해결 방법 1. 아예 사용 하지 말라니까... 참조 내부 객체가 있는 함수가 내부객체의 포인터나 레퍼런스를 리턴할 시 발생하는 일 1. 동적(?)으로 내부 객체 생성(동적인지는 모르겠으나 그 상황이 동적메모리 처럼 보인다) 2008/06/07 02:30 수정 1. 스택에 함수내부에서 사용될 객체를 생성 2. 내부 객체 사용 3. 내부객체 리턴 4. 바로 내부 객체 파괴 개인적 생각 이것을 피하기 위해서 new을 사용한다면, ..
항목 30. 접근하기 어려운 멤버에 대한 비상수 포인터나 레퍼런스를 리턴하는 멤버 함수 사용을 피해라 이유 1. private의 데이터를 포인터나 레퍼런스로 리턴은 정보은닉 자체를 파괴하는 행위이다. - 설계를 할때 성능에 중점을 둔다면 이런 경우가 생길수 있다고 필자는 설명한다. 해결방법 1. 우선 하지 말라; 2. 만약 할수밖에 없다면, 상수로써 전달한다. const 주의점 1. 만약 상수성을 제거해야지만 사용해되어야 한다면, 그 데이터를 사용 할때 데이터가 변경되지 않는다는 보장이 있어야 한다, 2008/06/28 03:25 추가 주의점 1번의 경우, 내부 데이터를 상수성이 있는 핸들로 받아놨는데, 만약, 그것이 함수에 들어 갈때, 상수성을 없에야만 한다면(간혹 이런 함수들이 있었다.), 그 함수 ..
항목 29. 내부 데이터에 대한 "핸들"을 리턴하는 것을 피해라 우선 핸들이란? 1. C++에선 포인터나 레퍼런스를 말한다.(참조자를 뜻한다.) 다시 본론으로.. 이유 1. 내부 데이터는 안정성을 보장하지 못한다. 해결 방법 1. .. 사용하지 마라! 이건 절대다! 2008/06/28 03:25 추가 해결방법 1의 경우, 절대 사용하지 않기보단 상황을 봐가면서 해야 한다고 다시 생각이 든다. 예를 들자면, .. 내부 데이터 객체가 20Byte가 넘는데 이녀석을 임시객체로 반환하기 보다는 상수성이 있는 핸들로 받아 온다면 충분히 성능 향상이 있기 때문이다.(.. 뭐 성능 향상은 알고리즘 개선 더 크겠지만;) 참조 1. 왜냐하면 내부 데이터는 리턴되고 나서 ;
항목 28. 전역 네임스페이스를 분활한다. 이유 1. 잠재적 모호성을 경계하기 위해 2. 라이브러리 파일의 이식성 증가를 위해 해결 방법 1. using namespace의 사용시 반드시 필요한가 자문해 본다. 2. 간단한 것은 그냥 직접 네임스페이스를 기재해 사용 한다. 3. 네임스페이스를 정의해둔다. 주의 사항 1. 무분별한 namespace는 사용치 않는다. 개인적 생각 1. 어디까지나 이식성과 가독성을 위해서이다. 이 두가지가 21세기형 프로그래밍 기법이다! 라고 저자가 은근히 말하는거 같다; 2. 보기 좋은 떡 먹기도 좋다. 라는 .. 생각이 난다.
최근댓글