항목 29. 내부 데이터에 대한 "핸들"을 리턴하는 것을 피해라 우선 핸들이란? 1. C++에선 포인터나 레퍼런스를 말한다.(참조자를 뜻한다.) 다시 본론으로.. 이유 1. 내부 데이터는 안정성을 보장하지 못한다. 해결 방법 1. .. 사용하지 마라! 이건 절대다! 2008/06/28 03:25 추가 해결방법 1의 경우, 절대 사용하지 않기보단 상황을 봐가면서 해야 한다고 다시 생각이 든다. 예를 들자면, .. 내부 데이터 객체가 20Byte가 넘는데 이녀석을 임시객체로 반환하기 보다는 상수성이 있는 핸들로 받아 온다면 충분히 성능 향상이 있기 때문이다.(.. 뭐 성능 향상은 알고리즘 개선 더 크겠지만;) 참조 1. 왜냐하면 내부 데이터는 리턴되고 나서 ;
전체 글 검색 결과
유니코드 관련 http://rmsg.tistory.com/tag/LPWSTR C++ 캐스팅 변환 관련 http://sdi1982.springnote.com/pages/491850 http://sdi1982.springnote.com/pages/448338 C++ 형변환 연산자 관련 http://kldp.org/node/93870 http://cafe.naver.com/summary.cafe?iframe_url=/ArticleRead.nhn%3Farticleid=19 C++ 소멸자 관련 http://kldp.org/node/93785 http://kldp.org/node/93782 C++ Get / Set 의 유용성 관련 http://kldp.org/node/93763 C++ 할당자 관련 http://kl..
항목 28. 전역 네임스페이스를 분활한다. 이유 1. 잠재적 모호성을 경계하기 위해 2. 라이브러리 파일의 이식성 증가를 위해 해결 방법 1. using namespace의 사용시 반드시 필요한가 자문해 본다. 2. 간단한 것은 그냥 직접 네임스페이스를 기재해 사용 한다. 3. 네임스페이스를 정의해둔다. 주의 사항 1. 무분별한 namespace는 사용치 않는다. 개인적 생각 1. 어디까지나 이식성과 가독성을 위해서이다. 이 두가지가 21세기형 프로그래밍 기법이다! 라고 저자가 은근히 말하는거 같다; 2. 보기 좋은 떡 먹기도 좋다. 라는 .. 생각이 난다.
항목 27. 의도하지 않은 내부 생성 맴버 함수의 이용을 명시적으로 막는다. 여기서 내부 생성 멤버 함수란? 1. 생성자 2. 소멸자 3. operator= 이유 1. 메모리 릭발생 위험이 있다. (반대로 메모리 릭의 반대 경우가 생길수도 있다. 없는 메모리를 delete) 2. 기본자료형과 같은 연산을 할수 없게 된다. 2008/05/31 14:19 수정 2. 제목 그대로, 의도하지 않은 동자을 일으킬수 있다. 해결방법 1. 재정의 해 준다. 2. 이용자체를 막는다. 덧붙여 해결방법 2의 예 1. operator =와 기본 private로 선언한다. 2008/05/31 14:19 수정 1. 복사생성자와 operator= 를 재정의해주거나, private로 옮겨 정상작동하거나 동작자체를 막는다 2. 함수..
최근댓글