locke 님이 쓰신 글 :
: 좀 어이가 없네요. 예전에 자료구조 같은거 배워도 스택이나 큐에서 값을 가져올때 없으면 null이 나왔었던거 같은데..
: 왜 이놈은 index out of bound 예외가 나죠???
: 에러만 나면 상관이 없는데.. pop을 하기위해 어디 다른데다 동적메모리를 할당해놓고 오류내고 빠지는듯..
: 큐가 아무것도 노드를 안갖고 있는 상태에서 계속 pop()을 호출하면 메모리가 계속 늘어나네요.
: 어디서 누수가 발생을 하나 고민고민 했는데.. TQueue::Pop()이었음. (이래서 돌다리도 두들겨보고 가라고 했던가..믿고 쓰는 vcl..OTL..ㅜㅠ)
: try catch 블록으로 감싸고 있어서 예외가 발생하는걸 몰랐다는..
: 어떻게 생각하세요? TStack도 같지않나..? vcl이 똑같은 델파이는..?
: 참고로 C++builder XE7입니다.
: 이건 해답을 바라고 쓴게 아니라 그냥 다른분들은 어떻게 생각하시나.. 써봅니다.
: -locke
:


VCL이 델파이 파스칼 코드로 만들어져 있고...
에러코드나 NULL 포인터 값을 리턴해서... 리턴 된 에러 코드나 NULL 포인터 값을 갖고 에러 처리를 하는 대신에...
Exception 에 의존하는 방식으로 구현되어 있고, VCL의 거의 대부분의 코드가 예외를 던져 버리는 식으로 만들어져 있죠.

과할 정도로 사소한 부분 까지 예외를 던져 버리기 때문에 퍼포먼스나 효율성에서 유리한 구조는 아닙니다.
Exception 처리라는 게.. 런타임 비용이 크게 문제가 되지 않는 JAVA, C# 같은 언어에서는 괜찮지만 빠른 퍼포먼스나 효율성이
요구되는 Native 환경에선 오히려 독이 되기도 합니다. (Exception 처리를 위해서 내부적으로 상당히 많은 코드가 수행 되어야 함)

VCL 컴포넌트가 IDE와 같은 어드레스 공간에서 같이 로드 돼서 돌아가는 DLL 형태이기 때문에 엠바가 과할 정도로 Exception에
의존하고 있는 거지요.

clang/llvm 컴파일러 툴 체인이 C++11 랭귀지 테크닉을 Full로 이용해서 구현되어 있지만, 컴파일러 툴 체인 자체가 전혀 Exception
을 사용하지 않는 구조로 구현되어 있는 것도 이 때문 입니다.

델파이 코드가 현장에서 버그가 많은 것도 try... finally 를 남용하는 바람에 예외 상황을 먹어 버리는 경우가 많기 때문 이기도 하고요.

되도록 Exception 사용은 피할 수 있는 한 피하고, 사용하지 않는 게 좋고요...

pQueue->Count(); 식으로 사전 체크를 해서 사용하는 패턴을 쓰는 게 나을 겁니다.