   .DLL or static library
  so now I'm tired of rewriting a logging class for each project I make, so I'm planning to write a logging-library but what would be the best aproach for that one?would it be easier to share one instance of the logging class between .exe and some other .dll  if I run it as an .dll file because my static lib have problems with that, the instance that is created in the .dll file only works there. altough I can create some exporting stuff that make the .dll export the functions for the .exe but that feels like some kind of nasty hack than a nice perfect solution.   
  First off, I'd like to reccommend a nice free logging library that you can drop in, so it acts like a static library more or less. Just letting you know of that, not sure if you want to use it or your own, I found that really helpful, but note that when you use it, and you use in in debug, your app will slow down greatly if you are continously logging in real time (just the effect of any logger though). If you're just logging key parts here and there you should not have a problem with it. Anyways for your question, I've always provided drop in code or a static library over a DLL for a logger class. It's easier to use drop in code because you can modify it to suit your specific application a lot better than having to use a static lib or DLL which you cannot change. I'd say not to use a DLL because then it'd add an extra dependecy for your program and could work against you when you are debugging if not done correctly.   ;  I agree with Drew there.  Plus, static libraries are so much easier to throw together.  you don't need to worry about interfaces or anything like that, you don't have to use any nasty tricks to export classes or any of that other nastiness.  I think a logging class is a prime example of where to use a static library (I do the same thing for my profiler).   ;  Drew_Benton > I'll look into that one, Thank you :)but lets say I don't like that one or just want to make my own anyway. How can a static library be better than a dynamic one... well I don't have to deal with exporting symbols... but what if I use the same one in Engine.dll and Game.exe then it will complain because the same symbols for the logging (don't remember exactly) will exist in the .dll when compiling/linking the .exe file that is anoying... and if it works they still use different memory allocations so that the logger in the .exe file will not be put into the log file created by the .dll file.   ;  >... and if it works they still use different memory allocations so that the >logger in the Just like with the same memory-model (ie multithreaded dll (debug)) and you won't have any problems with that :)