Delphi Clinic C++Builder Gate Training & Consultancy Delphi Notes Weblog Dr.Bob's Webshop
Dr.Bob's Kylix Kicks
 Borland C++Builder lost+found #9
See Also: C++Builder Papers and Columns

Look Ma! No Pointers
Lately, Micha, Arjan an I have been working on a pension calculator. It features things like bare-bones foreward chaining and backward chaining. The system consists of a Delphi 5 front end and a C++ backend. The C++ backend is written with C++Builder 4. One of the things we accomplished is that there is not a single class in the whole back end that has a pointer interface. I will repeat this. There are no methods that take an argument that is a pointer or return a pointer in all classes that are employed in the backend component. None. Nada.

What's wrong with pointer interfaces
The thing with pointer interfaces is that once you are being passed a pointer, you're obliged to check wether the pointer is nil. In some cases, nil pointers are a sign for a particular condition, but in the general case, nil pointers are a problem, especially if passed to constructors. Handling them leads to all kinds of nasty problems with partially constructed objects of class type and exception handling strategies. On the other hand, returning a pointer that can potentially be nil is also problemtaic for the sole fact that the user of such a function or method is obliged to check the value of the pointer itself before using it. If you have to drill down through a relationship graph, this leads to code similar to:

  Foo* foo = GetFooPointer();
  if (foo != 0)
  {
    Bar* bar = foo->GetBarPointer("x", "y");
    if (bar != 0)
    {
      bar->Process("qux");
    }
    else
    {
      // handle nil Bar pointer
    }
  }
  else
  {
    // handle nil Foo pointer
  }
Now, wouldn't it be nice if we could dispense with all the pointer checks and say:
  GetFoo().GetBar().Process("qux");
and forget about having to check for nil pointers?


This webpage © 2000-2017 by Bob Swart (aka Dr.Bob - www.drbob42.com). All Rights Reserved.