Delphi Clinic | C++Builder Gate | Training & Consultancy | Delphi Notes Weblog | Dr.Bob's Webshop |
|
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?