닫힌 fp에 출력을 시도해서 에러가 날거 같은데요.
생성자, 소멸자에서는 멤버 변수 초기화 관련 작업만 하라고 책에서 배운거 같은데. ㅋ

경문님 왜 정답 안알려 주세요? ㅋ

Log 와 App 중 어떤게 먼저 소멸될지가 문제가 되겠군요ㅋ 소멸자중에서도 프로그램 종료와 함께 소멸할경우 각별한 주의가 필요합니다ㅎㅎ

궁금해서 테스트 해봤더니 아래처럼 해주니 에러가 안나네요.

인스턴스 접근이 가능한것을 보니 static으로 생성 되어서 소멸자만

호출하고 메모리 해제는 하지 않은 상태가 되는것 같네요.

void write(const char* msg)
{  
  if(fp == NULL) return;  
  fwrite(msg, 1, strlen(msg), fp);
};

아... 홍문화님, 죄송합니다. ^^

본 문제는 Log 객체가 해제되고 난 이후에 App 객체에서 Log객체를 사용하기 때문에 발생하는 문제입니다. 하상은님이 말씀하신 것처럼  write내부에서 처리를 해 줘도 되지만, 좀 더 근본적인 해결 방안을 얘기해 보겠습니다.

지금 만들고 있는 라이브러리가 있는데, 제가 짠 것만 해도 대략 1만라인 정도가 됩니다. 전역 객체(static 객체 포함)는 가급적 쓰지 않으려고 하지만, 위의 예처럼 Log 객체는 거의 전역으로 사용하는 것이 편합니다. 어쩔 수 없이 전역 객체를 사용을 하는 경우가 있는데, 전역 객체의 의존성 문제때문에 문제가 발생할 수가 있습니다. 위의 코드는 아주 쉽게 예를 든 것이고, 소스 라인 수가 많아 지면 이러한 버그를 찾기가 어렵고, 시간도 무지오래 걸리죠. third party library와 연계를 하고 있어서 외부 소스를 건드릴 수도 없구요. ^^

일반적으로 전역 객체는 다음과 같은 순서로 생성과 해제가 이루어 집니다.

1. non-local static object들을 우선 생성(linker가 알아서 순서가 결정됨).

2. main 함수 진입.

3. local static object 접근할 때 object 생성(프로그램 코드에 따라서 순서가 결정됨).

4. main 함수 끝.

5. 1, 3 과정에서 생성된 object를 해제.

5번에서 object들은 생성된 순서의 반대 순서로 해제가 됩니다(stack에서 관리).

저는 다음과 같은 방법을 사용하였습니다.

1. Dependency라는 template class를 만든다.

// ----------------------------------------------------------------------------
// Dependency
// ----------------------------------------------------------------------------
template <class T>
class Dependency
{
public:
  /// class T must have static void dependency()
  Dependency()          { T::dependency(); }
  virtual ~Dependency() {}
};

2. Log 클래스에서 depencency()하는 method를 제공한다.

// ----------------------------------------------------------------------------
// Log
// ----------------------------------------------------------------------------
class Log
{
  ...
public:
  static void dependency()
  {
    instance();
  }
};

3. App 클래스가 Log클래스와 의존성이 있다고 명시해 놓는다.

/ ----------------------------------------------------------------------------
// App
// ----------------------------------------------------------------------------
class App : public Dependency<Log>
{
  ...
};

이렇게 해 놓으면 App static object가 해제되기 이전에 Log static object가 먼저 해제되는 것을 방지할 수 있습니다.

ps : 방법은 여러가지입니다. 제가 사용한 방법이 최선이라고 할 수는 없습니다. ^^

저는 위의 예제와 같은경우 App 에서 Log 클래스의 인스턴스 포인터 하나를 직접 관리하도록 하는 형태나 프로그램 종료시 명시적으로 순서에 맞춰 해제해주는 방법을 이용했었지만 코드가 덩치가 커지고 많은사람이 협업할땐 힘든일이죠..

"코드를 잘못사용하기 힘들게 설계하라" 는 측면에서 경문님이 소개해주신 예가 좋은것같습니다 객체지향적이고 우아하네요ㅋ

@하상은 네, 감사합니다. ^^

Template class 이름을 조금 바꾸어 봤습니다. 의미 전달이 좀 더 명확할 듯... ^^

http://www.gilgil.net/10260#comment_10429