Disabling RTTI in log4sendpp has no known consequences.

Replacing the regular STL is no problem either. No special features are used so you can use whatever replacement you wish to.

The only real problem is exception handling. You can't simply turn his feature off and continue with the program flow instead of throwing. When throwing an exception an application is typically in a critical state and its objects tend to be unusable. Continuing to use such an object is likely to crash the application. The other problem is the fact that the compiler can't prepare a way back to destroy automatic variables. This causes resource leaks.

Handling exceptions within log4sendpp is not too critical. It is mainly needed for internal switches if a network connection is not working. In case of an error, the secondary appender is used. But maybe you want to know how this is done because your setup needs to know more about such problems. The solution is quite simple: instead of throwing the exception, a function is called. By default this function just outputs the error message to stdout and returns. In this case the calling code must react correctly and maybe return an error code which would not be neccessary with execptions.

The following listing shows a possible scenario without exceptions:

	A user defined handler stores the error information for later use..
	On startup the new handler is registered. The old pointer is stored.
	The old handler is restored when the new handler is not needed anymore.

  void myFailureHandler(unsigned srcline,
                        const std::string &srcfile,
                        const stdd::string &message)
  {
    failure_l = srcline;  
    failure_f = srcfile;
    failure_msg = message;
  }

  FailureHandler old = setFailureHandler(myFailureHandler);  

  .....

  setFailureHandler(old);