Thread: Null object.

  1. #1
    Registered User
    Join Date
    Oct 2003
    Posts
    97

    Question Null object.

    I’m working on a little project that has some subsystems like sound and image and such. So each subsystem is a singleton in the application cause there only needs to be a single sound or image subsystem. The problem I have in some circumstances I don’t need both subsystems available so one of them may not actually exist. While that’s fine, I just return null when I request a pointer to the subsystem, the problem I have is that I need to check in every function that in fact that subsystem exists because I’m still able to call methods of that none existing subsystem which leads to crashes. Is there any way to make all those calls to the non-existing subsystem just return null without doing anything? In code what I do right now is checking that the subsystem I want to use exists every time I want to use it which has a performance cost.
    Code:
    if(myApp::getSoundSubsystem())
    {
    	// We know the sound sybsystem exists, use it.
    }
    And I just want to make the calls and return null every time without having to check that my subsystem exists every time I make a call to that subsystem. The only way I can think of doing that involves creating like a null version of each subsystem but that would take time to write and code I don’t really want to see in my little project. I hope you can help me.

    Thanks in advance.

  2. #2
    Code Goddess Prelude's Avatar
    Join Date
    Sep 2001
    Posts
    9,897
    >Is there any way to make all those calls to the non-existing subsystem just return null without doing anything?
    Why not just allow the calls but do nothing? Then instead of dealing with null pointers, you can use a dummy object that provides a stub interface. If you can manage it, that's a much cleaner solution.
    My best code is written with the delete key.

  3. #3
    Registered User
    Join Date
    Oct 2003
    Posts
    97
    Quote Originally Posted by Prelude
    Why not just allow the calls but do nothing?
    Because that would involve checking that the subsystem actually exists on every call to that subsystem (either check it on the function in the subsystem itself, or checking from the function that wants to use a function of the subsystem), that’s what I want to avoid.

    Quote Originally Posted by Prelude
    Then instead of dealing with null pointers, you can use a dummy object that provides a stub interface. If you can manage it, that's a much cleaner solution.
    But doesn’t that involve creating a new class for every subsystem that has the same functions and variables to return null? I would like to avoid that if possible.

  4. #4
    Code Goddess Prelude's Avatar
    Join Date
    Sep 2001
    Posts
    9,897
    >But doesn’t that involve creating a new class for every subsystem that has the same functions and variables to return null?
    Not if you derive from a base class that provides the stubs. As I said, if you can manage it, it's cleaner. Sometimes you can't manage it. Of course, you haven't provided nearly enough information for me to tell you whether it will work, or offer any remotely useful advice otherwise. My suggestion was a shot in the dark.
    My best code is written with the delete key.

  5. #5
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,895
    Quote Originally Posted by Hulag
    But doesn’t that involve creating a new class for every subsystem that has the same functions and variables to return null? I would like to avoid that if possible.
    It would still be a fraction of the work of checking the object before each use.
    These are your alternatives:
    1) Check before each call that the subsystem exists.
    2) Replace the subsystem by a no-op dummy.

    There are no other options. There is also, inside the constraints of C++ itself, no way to automate writing the dummy.
    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

  6. #6
    Registered User
    Join Date
    May 2006
    Posts
    30
    Quote Originally Posted by CornedBee
    It would still be a fraction of the work of checking the object before each use.
    These are your alternatives:
    1) Check before each call that the subsystem exists.
    2) Replace the subsystem by a no-op dummy.

    There are no other options. There is also, inside the constraints of C++ itself, no way to automate writing the dummy.
    there is one other way, you could create a smart pointer with a template param to your specific class and saving a pointer internally. that way you can overload for example the -> operator and let it check for null pointers. Just a suggestion.
    With the dummy class... that might take up some bigger V-tables wich you might not want. however if you dont require extreme speed or extreme memory saving, the dummy class is the way to go

  7. #7
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,895
    Quote Originally Posted by DV64h
    there is one other way, you could create a smart pointer with a template param to your specific class and saving a pointer internally. that way you can overload for example the -> operator and let it check for null pointers.
    And what would it do when a null pointer is encountered? Throw an exception? That's not much better than accessing the null pointer.

    With the dummy class... that might take up some bigger V-tables
    Only if the original class is not polymorphic in the first place. If the subsystem switch is to work across platforms, then it probably will be.
    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

  8. #8
    Registered User
    Join Date
    Oct 2003
    Posts
    97
    Ok, thanks for showing me the different alternatives. I will go with a no-op dummy. Thanks again guys.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. "Virtual Printer" or "Moving Printjobs"
    By extasic in forum Windows Programming
    Replies: 12
    Last Post: 06-30-2011, 08:33 AM
  2. 20q game problems
    By Nexus-ZERO in forum C Programming
    Replies: 24
    Last Post: 12-17-2008, 05:48 PM
  3. Global Variables
    By Taka in forum C Programming
    Replies: 34
    Last Post: 11-02-2007, 03:25 AM
  4. Compiling 3rd party code problem me too
    By siavoshkc in forum C Programming
    Replies: 1
    Last Post: 09-12-2007, 05:55 AM
  5. Request for comments
    By Prelude in forum A Brief History of Cprogramming.com
    Replies: 15
    Last Post: 01-02-2004, 10:33 AM