code toolbox

try와 if는 장단점이 존재하고 있었습니다. 일단 둘의 차이점은 try 구문에서 예외가 발생하면 그 즉시 블록이 종료가 되고 catch 블록으로 제어가 이동된다고 합니다. 그리고 try/catch는 “블럭”if/else 는 “구문”이라는 점이 다릅니다.

if/else 로 에러를 처리한다면 에러가 발생한 객체에 대해서 수명이 유지되기 때문에 에러를 처리하는 동안에도 에러가 발생한 객체를 참조하는 코드가 정상적으로 컴파일 된다. 어떤 예외가 발생했을 경우 try/catch 안의 모든 객체는 스코프를 벗어나 참조 할 수 없게 되지만 if/else 문은 스코프가 벗어 나지 않게 되므로 try/catch 보다 더 위험합니다. 또한 활성 스택에서 생성되는 지역객체들의 자동 소멸을 위해 그것의 정보들을 유지합니다. 따라서 if문의 예외처리와는 달리 지역 객체들의 소멸자가 자동으로 호출되므로 메모리 등 리소스 누수의 문제를 조금이나마 해결할 수 있습니다.

하지만 try/catch 의 단점도 존재하게 됩니다. try/catch 블록은 유지해야 할 정보도 많고 또 실제 예외가 발생 했을 때도 해주어야 할 일이 많기 때문에 당연히 코드 크기나 예외 발생시 처리 속도는if/else의 전통적인 반환 값을 통한 오류처리와는 비교하기 힘듭니다.

하지만 try/catch는 자동으로 해주는 일이 많으며 당연히 더 느립니다. 하지만 우리가 만들어낸 코드가 컴파일러가 자동으로 만들어준 코드보다 더 안전하다고 말하기는 힘들겠네요.

예외를 던질 때 단순히 기본형을 넘기는 것이 아니라, 예외 처리를 위해 미리 만들어진 클래스의 임시 객체를 넘기면 보다 자세한 정보를 catch 핸들러가 얻을 수 있습니다.

하지만 try/catch 를 사용하는 것은 검사코드가 포함되고 stack unwinding을 위한 코드가 추가되기 때문에 실행 파일의 크기를 약간 증가시키고 실행 속도를 약간 감소시킵니다.
예외 처리의 이러한 단점 때문에, 예외 처리는 사용되어야 할 곳에만 사용하는 것이 바람직합니다. (어떤 프로그래머는 DirectX로 개발하는 게임 프로그램의 렌더링 루프에서는 try/catch를 사용하지 않는다고 한다.)

 #pragma pack은 구조체의 저장 크기를 결정하는 명령어입니다.

 BYTE 의 멤버 변수를 1바이트로 실제 저장하는가 아니면 2, 4바이트로 저장하는가를 설정합니다.

#pragma pack(push,2) <---- gcc, vs에서 이렇게 사용합니다.

    struct KBITMAPFILEHEADER

    {

        WORD bfType;

        DWORD bfSize;

        WORD bfReserved1;

        WORD bfReserved2;

        DWORD bfOffBits;

    };

#pragma pack(pop)