Bad practice or acceptable?

This is a discussion on Bad practice or acceptable? within the C++ Programming forums, part of the General Programming Boards category; Say you have a singleton thats accessed like this .... SomeSingletonClass::Instance()->FunctionCall(); would doing .... #define gSomeSing SomeSingletonClass::Instance() and then making ...

  1. #1
    Registered User Noose's Avatar
    Join Date
    Jul 2003
    Posts
    11

    Bad practice or acceptable?

    Say you have a singleton thats accessed like this ....

    SomeSingletonClass::Instance()->FunctionCall();

    would doing ....

    #define gSomeSing SomeSingletonClass::Instance()

    and then making calls like this ...

    gSomeSing->FunctionCall();

    be a dumb thing to do ? Seems to work, but are there any down falls not related to naming?

  2. #2
    vae victus! skorman00's Avatar
    Join Date
    Nov 2003
    Posts
    594
    Macro's are a touchy subject. I don't see anything wrong with doing that. Just remember that you did that while you're debugging because it tend to cause confusing errors. It's easy to create a bug in a macro and never find it because you forgot you even made the macro.

    Also, if you use that to call several functions continuously, it might benefit you to hold the result of Instance() in a seperate pointer.

  3. #3
    Toaster Zach L.'s Avatar
    Join Date
    Aug 2001
    Posts
    2,686
    Right, as skorman00 was implying, the following is a much better idea:
    Code:
    SomeSingletonClass* inst = SomeSingletonClass::Instance();
    inst->whatever(); // ... etc ...
    Remember that macros actually change your code before the compiler sees it, so the compiler does not see the same thing that you do. In this case, there is probably little harm, but in general, I'd recommend not using macros unless there is a truly compelling reason to use them.

  4. #4
    Registered User
    Join Date
    Aug 2003
    Posts
    470
    I think that's bad practice because it disguises the use of the singleton. It's not dumb though. I just think having two names for a singleton object a bit confusing. You'd also need to develop a standard naming convention for your #define's to avoid this problem.

  5. #5
    Registered User Noose's Avatar
    Join Date
    Jul 2003
    Posts
    11
    Yes you are right, I can see if your making several function calls with this singleton within a single function it would be best to store the pointer at the top of the function and call however many times. Plus saving the overhead if the call is something like this


    Code:
    ManagedObject* mobj = SomeSingletonObjct::Instance()->GetManagedObject("name");
    where GetManagedObject() may have to do a search, writing


    Code:
    mobj->DoSomething();
    and searching once is much better than writing this


    Code:
    SomeSingletonObjct::Instance()->GetManagedObject("name")->DoSomething();
    and searching eight times. What I originally was looking to do was to quckly shorten something like this

    Code:
    SomeSingletonObjct::Instance()->GetManagedObject("name")->DoSomething();
    
    to
    
    gSomeSing->GetManagedObject("name")->DoSomething();
    
    or
    
    gSomeSing->DoSomething();
    when its being used in a place where it only needs to be called once and storing the pointer has no purpose because its used once either way. Thx for the replies.

  6. #6
    Registered User jlou's Avatar
    Join Date
    Jul 2003
    Posts
    1,088
    Perhaps better than a macro is an inline function that returns the instance:
    Code:
    inline SomeSingletonObjct* gSomeSing() { return SomeSingletonObjct::Instance(); }
    // or
    inline SomeManagedObject* gSomeSing() { return SomeSingletonObjct::Instance()->GetManagedObject("name"); }
    
    // use as
    gSomeSing()->DoSomething();

  7. #7
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,892
    I'd also return a reference to the singleton instead of a pointer, but that's of course a completely different subject.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. How bad is bad
    By caroundw5h in forum A Brief History of Cprogramming.com
    Replies: 21
    Last Post: 11-12-2004, 08:26 AM
  2. Replies: 11
    Last Post: 11-13-2002, 12:29 PM
  3. Bad Practice??
    By Unregistered in forum C Programming
    Replies: 2
    Last Post: 11-25-2001, 07:37 AM
  4. good news and bad news
    By Garfield in forum A Brief History of Cprogramming.com
    Replies: 25
    Last Post: 10-27-2001, 07:31 AM
  5. Bad code or bad compiler?
    By musayume in forum C Programming
    Replies: 3
    Last Post: 10-22-2001, 09:08 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21