#define and extern question

    This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

    • #define and extern question

      Hi guys,

      I have a logger system for my scripts and project in which I can send errors out to a file. Heres the problem, I have a macro something like this:

      Source Code

      1. class CLogger
      2. {
      3. ...
      4. WriteLog(std::string err, __LINE__ );
      5. ...
      6. };
      7. #define WriteMyLog(error) Log.WriteLog(std::string err, __LINE__ );


      Now then, in file 'A' I declare "CLoger Log" and open a file for writting. In file 'B' I need to be able to use my macro (i.e. "WriteMyLog("opps")). In file 'C' I need to be able to do the same.

      In file 'B' and 'C' I have tryed to use "extern", 'extern CLoger Log', in hopes that I could use the macro. Also, I have tryed, for example in file 'D':

      Source Code

      1. #include "CLogger.h"
      2. class CLogger;
      3. extern Logger;
      4. ...
      5. MyClass:MyFnction(...)
      6. {
      7. ...
      8. WriteMyLog(error); // error C3861:.. identifier not found, even with argument-dependent lookup
      9. ...
      10. }
      Display All

      Can I bug you guys once again for some help please? How can I get my macro to be used across multiple files in my project?

      Thanks,

      Sabrina.
      PS: I've tryed 101 ways in using "stactic" with "extern" and "#define" with no luck.
    • Quick question.

      Will you even have more than one instance of the CLogger class in use at any one time?

      If not you may want to look at using a singleton and that way you can use the Logging system where ever you like by including the header file rather than using extern anywhere you want to use the log.

      class CLogger
      {
      private:
      CLogger() {};
      CLogger(const CLogger&) {};
      static CLogger m_Instance;
      public:
      static CLogger& Instance() { return m_Instance; }
      }

      Add those lines to your class for speed and for a full template inplementation look up Scott Bilas' singleton template class.

      That will let you use the logger anywhere by typing
      CLogger::Instance().Method();

      Hope that helps a little.
    • Hi guys,

      bonus uk:
      I did try passing around a global pointer to the object (Cloger), but it has problems with the macro. The global pointer is not a singleton. However, you do bring up a point, there will (and should) be only one instance of the CLoger object thus a singleton would be the way to go, however. I will look into this further.

      Kain:
      Assume all files have .h and .cpp. Your thoughts on Singletions? I'd like to get a consensus.

      FYI: I have been "includ[ing]" the "CLoger.h" across all files needing access to the macro.

      Thanks guys :)

      Sabrina
    • I would suggest passing in the CLoger object as part of the macro.

      #define WriteLog(x, y) x.WriteLog(std::string(y), __LINE__);
      Feel you safe and secure in the protection of your pants . . . but one day, one day there shall be a No Pants Day and that shall be the harbinger of your undoing . . .
    • Probably just another artifact of your posted pseudo-code, but your macro parameter is "error," but the definition doesn't contain "error" anywhere.

      Your example will expand as:

      Log.WriteLog(std::string err, __LINE__ );;

      But I think you want:

      Log.WriteLog(error, __LINE__ );

      My guess is that you just need to take a nap.
    • Try this:

      In Logger.h, declare the following line right above your macro:

      Source Code

      1. extern CLogger Log


      And then in Logger.cpp, declare this after your #includes:

      Source Code

      1. CLogger Log


      If you do this, then any file that #includes "Logger.h" will have access to the macro just as much as it has access to the Log object you externed in the header and actually defined in Logger.cpp.

      The reason you may have had some problems before is that when you extern something, it wants only one instance of that something to exist in a cpp... I think.

      Is that what you wanted?

      You asked what I thought of singletons, I like only one singleton in the entire game... that singleton is the game application class (cApp) singleton. Everything else should be a member of this cApp class... even public members would be ok. The reason I favor only one singleton is because I want as much explicit control over the order of construction and destruction of things as possible. If you declare singletons that are actually static class objects, then you do not get explicit (predictable) order of creation and destruction for your "global" objects. It will be hard to predict which static object gets constructed first. This can cause problems down the line if you ever have a global that is dependent on another global's existence.... unless you want to complicate things by having two-phase construction, meaning a constructor that does nothing, and an Init() function that does all the real construction when you tell it to. Then on the destruction side, you'd need two-phase destruction, like a CleanUp() function to do the real destruction before the destructor gets called. That works, too, but I prefer to keep as much code in one place as possible. I also prefer to think that when something is constructed/destructed, then I didn't forget anything and the object is pretty much ready to go.

      That doesn't mean that you will never have an init function because sometimes, you can't avoid having something requiring an Init() function for other reasons.

      On a console, you definitely want full control over when each system gets created/destroyed and where the creation/destruction takes place because there may be times when you want to temporarily delete entire systems to free up memory for certain things, like playing a movie while a level is loading or something.
    • Hi guys,


      ImissEnB:
      The CLogger object is declared in "Main.cpp" which is the start of the program, (Entry point). 'error' is a "enum", so thats not the problem.

      Kain: I already have the code you suggested.
      As far as a Singleton, I've seen singletons for just about all objects in a project, then again, I've seen only one singleton for an entire project, as the way you mentioned. In either case, I've never read any explanation of using multiple singletons, versus multiple singletions for multiple objects. For right now, I will have to look for other arguments to decide if this is an avenue to go with.


      I did forget to mention the error I continue to get: "... 'WriteLog': identifier not found, even with argument-dependent lookup." (Sorry about that)


      Sabrina