Try & Error

본 글을 읽기 전에 다음 글을 읽으시면 도움이 됩니다.  http://hermet.pe.kr/92422706 (c++ 예외처리), 

 

 

예전부터 궁금한 사실이었지만,   과연 try - catch를 사용함에 따른 비용은 어느정도일까?

 

궁금해서 직접 c++을 통해 테스트 해보기로 했습니다.

 

#define ENABLE_EXCEPTION   struct Test {       int    m[100];       Test() { printf( "." ); }  };   int _tmain(int argc, _TCHAR* argv[]) {           DWORD begin = GetTickCount();                  for( int idx = 0; idx < 1000000; ++idx ) {  #ifdef ENABLE_EXCEPTION          try {                 Test* test = new Test();        delete( test );          }catch( ... ) {    printf( "Exception!\n" );        }  #else          Test* test = new Test();          delete( test ); #endif }                  DWORD end = GetTickCount();           printf( "Elapsed - %d\n", end - begin );           return 0; }

 

위 코드에 대해 주목할 것은 어떤 임의의 루프문에서 Test라는 객체를 생성하고 제거하는 것인데,  예외처리 지정일 경우 try - catch 문에서 이를 수행한다는 것입니다.

 

그럼 과연 try-catch를 했을 경우와 하지 않았을 경우의 출력 값은 어떠했을까?

 

예외 처리한 결과 - 85723

안한 결과 -          76503

 

성능 결과는 무려 9초 차이가 납니다. 그리고 언어마다 그 차이는 조금씩 다르겠죠. (매우 클 수도 있고.. -_- )

 

그래도 확실한 것은,  try - catch에 의한 비용은 분명히 있습니다.

 

자, 어찌됐든 위 코드에서 우리는 메모리 할당의 예외 가능성을 예측할 수 있으므로 다음과 같이 수정해 봅시다.

 

Test* test = new Test();   if( test ) {     delete( test ); }else {       printf( "Exception!\n"); }

 

그리고 시간 측정 결과는 다음과 같습니다.

 

예외 처리한 결과 - 85723

안한 결과 -          76503

나의 예외처리 -      78671

 

아무것도 하지 않는 것보다는 약 2초 가량 더 부하가 있긴 하지만, try-catch보단 월등히 낫군요.

 

사실, 시스템 사양에 따라 이런 예외처리 부하는 매우 미미할 수 있을 것이며 80:20 법칙을 고려했을 때도 이는 전체 성능에 거의 눈에 띄지 않을 수도 있겠죠.

 

결국, 예외처리에 대한  선택의 여지는 여러분의 몫이 될 수 밖에 없습니다.

 

 

그리고 예외처리에 대한 저의 철학은 다음과 같습니다.

 

 

"피할수 있다면 하지 않는다."

 

 

try-catch 문에 대해선 위 예와 같이 피할 수 있으면 하지 않습니다. 시스템 콜 사용에 대해선 결과를 알 수 있으므로 대부분 하지 않겠죠.

또한 라이브러리 제작 측면에서는 사용자의 잘못된 사용에 대해 if-else 대신 assert (http://hermet.pe.kr/54763810 )로 사전에 방지해 줍니다. 개발 과정에서는 debug 모드로 제작을 하면서 모든 에러 및 잘못된 사용에 대해 사용자들에게 assert로 알려주는 것이지요.

 

그리고 제품 release일 경우엔 이 assert문은 자연스럽게 코드에서 빠지면서 예외처리에 대한 부하도 같이 사라지게 됩니다.

물론 개발과정에서 assert문을 통해 모든 오류를 수정한 후 일것이구요.

 

More Effective C++ 책에 의하면, try - catch 블록을 쓰기만 해도 코드 블록 및 실행 속도가 5 ~ 10 % 늘어난다고 합니다.

또한, 실제 예외가 발생(throw)하여 함수로 복귀하는데에는 1000배 만큼 느려진다고 합니다. 물론 예외는 거의 발생하지 않는다 라고 봤을 때 이런 부하는 눈감아 줄 수도 있겠죠.

 

 

결론을 말하죠.

 

쓸데없이 예외처리를 하지는 마세요. 진짜 예외적인 상황이 발생할 수 있을 때만 합니다.

성능이 문제가 된다면 위 예제 소스와  같이 프로파일링을 해보세요.

그리고 컴파일러 옵션에서 예외지정을 제외하세요.

 

 

 

(참고 - More Effective C++ (정보문화사), 132-134 )

--------------------------------------------------- *초기작성일 : 2003/06/18 *작성/저작: 곽용재(kwak101@hitel.net) --------------------------------------------------- (아시는 분도 있을지 모르지만) 프로그램을 디버깅하던 중, 제가 발견했다는 점에서 이곳에 한번 써 봅니다. :) VC++ 통합환경을 사용할 때 가장 많이 쓰게 되는 기능 중, Build->Start(CTRL+F5)와 Debug->Go(F5)의 차이점중 하나에 대해 알아 보겠습니다. F5는 IDE(통합환경)가 실행 프로세스를 반동결(Soft-ice)상태로 실행시켜, 사용자가 내부 변수의 값을 들여다 볼 수 있거나 중간에 멈출 수 있게 합니다. 디버깅을 할 때에 아주 중요한 역할을 하지요.  반면, CTRL-F5는 IDE가 실행 프로세스를 단순히 생성(fork)하는 역할만 합니다. 즉, 배포된 프로그램을 우리가 설치해서 실행할 때와 똑같은 환경이라고 생각하면 되겠습니다. 이 두 개의 기능은 방금 설명한 것 이외에 조금 다른 실행환경을 제공합니다. 바로 "미초기화 변수의 초기화"입니다. 그리고, 이 양상은 프로그램이 릴리즈 빌드냐, 디버그 빌드냐에 따라 다릅니다. 아래와 같은 구조체와 이것을 사용한 코드(비록 한 줄이지만)있다고 가정합시다. struct Sample {    Sample(bool b_isValid):b_isValid_(b_isValid){}    Sample(){}       inline bool isValid(){return b_isValid_;}    bool  b_isValid_; }; . . . Sample smpl1; bool b = smpl1.isValid();   이 코드를 릴리즈 빌드로 만들고, Start(CTRL+F5)로 실행할 때의 b값과 Go(F5)로 실행할 때의 b값을 체크하면 서로 다르게 나옵니다.  Start의 경우 b의 값이 false가 나오고, Go의 경우 b의 값이 true로 나옵니다. 바꾸어 말하면 Start는 미초기화 변수를 0으로 놓고, Go는 0이 아닌 값으로  세팅한다는 것입니다. (실제로 bool 타입의 false 값을 VC6의 디버거로 읽으면 0입니다. VC7의 경우엔 false라고 나오지만요)   한데, 디버그 빌드의 경우는 어떨까요? 그 경우에는 Start나 Go나 차이를 보이지 않고 b값이 true입니다. 여기서 자그마한 결론을 얻을 수 있습니다.   1. 디버그 빌드를 했거나 F5로 실행시키는 경우, 미초기화 변수는 0이 아닌 값으로 초기화된다.   2.  릴리즈 빌드한 프로그램을 CTRL-F5로 실행시키는 경우, 미초기화 변수는 0으로 초기화된다.   디버깅할 때는 잘 돌던 프로그램이 그냥 실행시킬 땐 오동작을 보이는 경우가 있어 막대한 육체적/정신적 에너지를 낭비하는 경우가 있는데, 그런 경우를 만난다면 이 글의 내용을 한 번쯤 떠올려 보시기 바랍니다. 그리고 다음의 점검을 해보시기 바랍니다.    -기본생성자가 함부로 내동댕이쳐져 있는가?    -복사생성자에서 멤버 간 대입(member-wise assignment)를 잘 하는가?    - 전역변수와 정적변수 초기화를 제대로 했는가?    - 실수로 초기화하지 않고 쓰는 지역변수가 있는가?(요즘 나오는 대부분의 좋은 컴파일러는 경고 메시지를 내주긴 합니다만) 필자의 경우 이것 때문에 반나절을 날리는 고생을 한 적이 있습니다. 참 어이가 없었죠..:)

출처 : http://www.kwak101.pe.kr/bbs/view.php?id=kwak_worksInternDocTip&page=1&sn1=&divpage=1&sn=off&ss=on&sc=on&select_arrange=headnum&desc=asc&no=10

질문 1]

순수 어쩌고 가상함수. 이렇게 명명되는 함수들은 정의가 없습니다.
그래서 이 함수를 포함하고 있는 클래스는 인스턴스를 만들 수 없죠.

그런데 EC++ (3/e)를 읽다보니 순수 가상 함수에 정의를 하고 있는 부분이 나옵니다.
항목7 93~94페이지에 나온 AWOV 클래스인데요,

class AWOV {
public:
  virtual ~AWOV() = 0;
};

이렇게 소멸자가 '순수 가상'으로 되어있음에도 불구하고, 다음 페이지에서

AWOV::~AWOV() {} // 순수 가상 소멸자의 정의

이렇게 정의를 내리고 있습니다.

제가 컴파일을 해보니 또 컴파일도 되더군요-_-; 어떻게 이런 문법이 가능한건가요?

질문 2]
역시 또 EC++(3/e) 항목 31 225페이지에 보면 인터페이스(Java의 그것과 유사한 의미)를 선언하고 있는데요,

class Person {
public:
  virtual ~Person();

  virtual std::string name() const = 0;
  ...
};

여기서는 소멸자를 '단순 가상'함수로 선언하고 있습니다.

왜 '순수 가상'으로 만들지 않는 것인지 의문이 생깁니다.
이 클래스는 '추상 클래스'가 아닌 '인터페이스'로 쓸 것인데 말이죠...

구글링 등 검색을 해봐도 만족할 만한 답변을 얻을 수 없어서 질문 드립니다~

질문도 그렇고 답변도 좀 길 듯하여^^ 별도의 답글로 달아 봤습니다.

질문 1에 대한 답변

C++에서 순수 가상 함수의 기계적 의미는 해당 추상 클래스의 vtbl에서 그 순수 가상 함수의 포인터가 0(=null)로 들어 있다는 것입니다. 즉, AWOV 클래스가 이렇게 되어 있다면,

class AWOV { public: virtual ~AWOV()=0;  virtual foo(); };

이 클래스의 vtbl은 다음과 같이 나옵니다.

vptr -> [ 0                   ]   // 첫째 : AWOV::~AWOV()의 주소
           [ &(AWOV::foo)]   // 둘째 : AWOV::foo()의 주소

하지만, 가상 소멸자의 호출 매커니즘은 파생 클래스의 소멸자가 기본 클래스의 그것을 직접 호출하도록 (컴파일러에 의해) 만들어집니다. vtbl을 통하지 않는다는 것이죠. 따라서 AWOV::~AWOV의 본문이 정의되어 있지 않으면 링크 에러를 내게 됩니다. 이것은 "이렇게 해도 컴파일이 되네" 수준이 아니라 "꼭 이렇게 해야 합니다"라는 의무 조항입니다.

질문 2에 대한 답변

설계상의 선택사항입니다. 순수 가상 함수로 만들 다른 함수가 있으면 구태여 소멸자를 순수 가상으로 만들 필요 없이 비순수 가상으로 만들어도 됩니다.


출처 : http://www.kwak101.pe.kr/bbs/view.php?id=kwk_worksBBS&page=1&sn1=&divpage=1&sn=off&ss=on&sc=on&select_arrange=headnum&desc=asc&no=157

1. 브레인 스토밍 이란?

  앞부분의 크리에이티브 아이디어가 기억나십니까?

크리에이티브의 정의는 ‘기존 소재를 새롭게 해석하여 독창적으로 만들어내는 것.’입니다. 여기서 하나 전제 되어야 할 것이 있습니다. 그것은 한 사람이 아닌 여러 사람에 의해 만들어져야 한다는 것입니다. 이 사람들 간에 유기적인 결합이 있어야만 훌륭한 크리에이티브가 나옵니다.

크리에이티브 아이디어를 발상을 위해서 하는 기본 작업이 바로 브레인 스토밍 기법입니다.

 이 방법은 광고회사의 알렉스. F. 오스본에 의해 창안된 방법입니다.

 브레인 스토밍은 일반적으로 두뇌 폭풍으로 번역되는데 ‘두뇌에 충격을 가 한다’는 것이 본래의 의미 입니다. 좀 더 구체적으로 설명하면 ‘서로 갖고 있지 않은 사고나 개성을 보완하고자 하는, 집단으로 행하는 아이디어 창조 방법’입니다. 결국 이 방법은 집단의 힘으로 개발하자는 의도인데 인간 사고의 연쇄반응과 작용을 통해 아이디어의 대량 생산이 가능하여 현재 광고계 비롯한 타분야 에서도 널리 사용되고 있습니다.

 다시 말해, 브레인스토밍이란 어떤 한 가지 주제에 관하여 관계되는 사람이 모여 집단의 효과를 살려 아이디어의 연쇄반응을 일으키게 함으로써 자유분방하게 아이디어를 내는 방법입니다.

 2 . 브레인스토밍(brainstorming) 방법

 (1) 브레인스토밍 전제가 되는 원리는,

① 한 사람보다 다수인 쪽이 제기되는 아이디어가 많다.
② 아이디어 수가 많을수록 질적으로 우수한 아이디어가 나올 가능성이 많다.
③ 일반적으로 아이디어는 비판이 가해지지 않으면 많아진다. 
 등의 원칙에서 구 할 수 있습니다.

회의에는 리더(인원이 적으면 리더가 서기를 겸한다)를 두고, 구성원 수는 10명 내외를 한도로 합니다. 서기를 두는 것도 좋습니다. 시간은 한 시간 정도가 적당합니다.

 (2) 브레인 스토밍의 순서

문제설정 → 인원구성 → 문제제시 → 원칙확인 → 연습 → 진행 → 종결 → 아이디어 낭독 → 추가기록 → 정리 및 활용

 (3) 브레인스토밍을 시작하기 전에 이 질문들을 염두 해 주십시오.

- 브레인스토밍의 주요 목적 또는 목표는 무엇입니까?
- 무엇을 해결하려 합니까? (생각이 제한되는 너무 구체적이지 않은 주제가 좋습니다. 브레인 스토밍 과정에서 세부 목적을 잡아가면서 진행하는 것이 좋습니다.)
- 어떤 결과물이 나오기를 원합니까?
- 활용할 수 있는 창의적인 활동이나 실습과제는 무엇입니까? - 어떤 도구를 사용 할 것입니까?
- 브레인스토밍 활동에 누구를 참석시킬 것 입니까? 그들이 제공할 수 있는 독특한 기술, 경험, 지식은 무엇입니까? 그들이 참석해야 하는 이유는 무엇입니까?

 (4) 목표, 문제, 기회 또는 대상을 정의하십시오.

브레인스토밍을 하는 이유는 일일이 설명할 수 없을 만큼 매우 다양합니다.
문제 해결하는 도구로 브레인스토밍을 고려 할 때 그 문제보다 시각과 정의하는 방법은 여러 가지다. '잘못 되어 있어서 바로잡아야 하는 일'이 아닐 수도 있습니다. 그보다 다음과 같은 개념으로 생각하십시오.

- 필요성 (예: 새로운 상품이나 서비스를 위한 아이디어)
- 판촉을 위한 새로운 기회 (예: 기존 제품으로 새로운 시장에 뛰어들어 활로를 모색함)
- 증진 방안 (예: 휴가 기간에 벌이는 마케팅 활동)
- 장애를 극복하는 방법 (예: 경쟁제품을 물리치기 위한 새로운 마케팅 수단)

 (5) 브레인스토밍 진행 원칙

브레인스토밍을 진행할 때는 지켜야 할 규칙이 있습니다.
다음의 브레인스토밍 네 가지 규칙만 잘 연습시켜도 아이디어 발상력을 키우는데 도움이 됩니다.

① 창출된 아이디어를 비난하거나 평가해서는 안 된다.
② 아무리 우스꽝스러운 아이디어라도 수용되어야 한다.
③ 아이디어는 많을수록 좋다.
④ 이미 제안된 아이디어로부터 다른 아이디어를 이끌어 낼 수 있도록 한다.

 이러한 4가지 규칙은 한 번에 한 가지씩 훈련해 봐도 좋습니다. 미국의심리학자인 토란스가 성인들을 대상으로 연구한 결과, 첫 번째 규칙을 훈련시킨 후에는 10개의 아이디어를 창출하고, 두 번째까지 훈련시킨 경우는 20개, 세 번째까지 시킨 경우는 30개, 네 번째 규칙까지를 모두 익힌 후에는 40개 정도의 아이디어를 제안했다고 합니다.

 각 규칙을 다시 상세히 살펴봅시다.

 ① 비난하거나 평가해서는 안 됩니다.

누가 낸 의견을 다른 사람이 '좋다' '나쁘다' '맞다' 틀리다'는 식으로 평가를 하거나 비판하지 않습니다. 따라서 제시된 아이디어는 모두 수용하는 것을 원칙으로 합니다.
브레인스토밍의 장점은 판단을 유보하는 데 있습니다. 이것은 비판을 배제하는 것을 의미합니다.  

② 우스꽝스러운 아이디어라도 수용되어야 합니다.

창의적인 사고는 자유로운 분위기에서 일어납니다. 그러나 우리의 사회는 이러한 창의적인 분위기를 조성해 주기는커녕 오히려 그 발달을 저해하고 있습니다. 아무리 이상한 아이디어라도 일단 받아들일 줄 아는 태도가 필요합니다. 자유롭게 느낀 대로, 생각한 대로 아이디어를 낼 수 있게 함으로써 두뇌 활동은 더욱 촉진되고, 더 많은 양의 아이디어를 낼 수 있는 것입니다.

브레인스토밍을 진행할 때는 제시한 것 중에서 엉뚱한 의견도 있고, 주제와는 관련 없는 대답을 하기도 하는데, 이것도 받아 주어야 합니다.

또 강압적인 분위기보다는 즐겁고 재미있는 분위기를 만들어 흥미를 느낄 수 있도록 이끌어 가는 것이 중요합니다.

 

③ 아이디어는 많을수록 좋습니다.

브레인스토밍에서는 아이디어의 양이 강조되는데, 이는 아이디어가 많으면 많을수록 유용한 아이디어가 나올 가능성이 높기 때문입니다.

좋은 아이디어를 내려고 긴장하면 오히려 좋은 아이디어가 떠오르지 않는 경우가 있습니다. 그리고 좋은 아이디어는 처음부터 나오지 않기 때문에 자유로운 분위기 속에서 많은 아이디어를 내도록 하고, 질을 중시하는 질문은 피하도록 합니다.

브레인스토밍은 아이디어의 질보다는 양을 더 중요하게 생각합니다. 아이디어가 많으면 많을수록 유용한 아이디어가 나올 가능성이 높기 때문입니다.

양적으로 축적된 아이디어를 목록별로 정리하고 발전시켜 원하는 최종 산출물을 얻습니다. 그리고 아이디어의 질을 고려하는 것은 곧 평가를 의미하는데, 이러한 질에 대한 평가는 브레인스토밍이 끝난 뒤에 하도록 합니다.

 ④ 이미 제안된 아이디어로부터 다른 아이디어를 이끌어 낼 수 있도록 합니다.

이미 제안된 아이디어로부터 다른 아이디어를 이끌어 내는 '히치 하이킹'을 이용하도록 합니다. 자신의 아이디어에 다른 사람이 발표한 아이디어의 좋은 점을 결합시킬 수 있도록 도와주는 것도 브레인스토밍의 중요한 원칙 가운데 하나입니다. 이 때 다른 사람의 아이디어를 비판 없이 받아들이는 것이 아니라 자기가 선택해 자기 것으로 바꾸는 한 단계 진전된 방법입니다.

  참고자료
브레인스토밍 100배잘하기 - 21세기북스 [제이슨 리치 지음, 정명진 옮김]

 

http://blog.naver.com/lsm30815?Redirect=Log&logNo=80104876555

NiNew등의 Ni 관련 함수들은

NiInit() 이후에 와야 되는 것 같다.

같은 동적할당이라 생각하고 NiInit() 이전에 했더니 컴파일 에러는 안나는데..

런타임 에러가 난다.

기억해 두자.