Re: Pointers vs References: A Question on Style

From: Phlip (phlip_cpp_at_yahoo.com)
Date: 07/27/04 

Date: Tue, 27 Jul 2004 02:32:34 GMT

> > One good style rule is to never return null, and never accept null as
> > parameter.

David Rubin did not know his peril when he uttered:

> This is a naive rule. For example, you want to return a pointer when
> it is possible for a result to be invalid, undefined, or unset:

All rules are naive. Calling that rule naive is naive.

> const my_Object *lookup(const char *name);
>
> my_Object *my_Objet::singleton();

You need to study Barton & Nackman's Fallible<> class template, from their
/Scientific & Engineering in C++ something/ book.

> Obviously, you need to return by address when you return a dynamically
> allocated object, as in a factory method.

That is non-obvious. If the factory throws when it can't allocate, it can't
return NULL, hence the reason for pointing goes away. It could honestly
return a reference.

Rule 1: Prefer references to pointers unless you need pointers' special
abilities.

Rule 2: Avoid the need for pointers' special abilities.

I recently wrote a dialog box, in WTL (on MS Windows) that stores customer
names in a list box, and names and address in edit fields. The edit field
for the State is a combo box. The dialog box stores the name list in XML
(via MSXML via COM), and the list box displays tabs correctly as columns.
The edit fields link to the XML via MVC. The dialog box can localize to
Sanskrit, and can display a cancellable progress bar based on a window
timer.

The only * in the program are for passing constant strings into low-level
functions, and inside one auto_ptr<>. Otherwise, no pointers. (And remember
WTL is a healthier library than MFC!)

> As for *accepting* a null pointer argument, there is really no problem
> with this as long as you *document* the expected behavior so that your
> clients understand how to use your function:
>
> int getValue(int *result, const my_Object& key);
> // Load the value associated with the specified 'key'
> // into the specified 'result'. Return 0 on success,
> // and a non-zero value otherwise. The behavior is
> // undefined unless 'result' is a valid pointer. Note
> // that the value pointed to by 'result' is not altered
> // if the function does not succeed.

Comments suck. int result should be a full-fledged object that enforces
those behaviors, if they are important.

> > void funk(SimCity const & aCity)
> > {
> > aCity.throwParade();
> > }
>
> This may be completly unreasonable when working with third-party or
> legacy code.

It may be the only salvation for such code. Obviously you can't change
someone's opaque function.

When un-f***ing-up legacy code, the ability to slip new polymorphic
behaviors into its tangled code is priceless. Introducing the ability to
polymorph a SimCity carries many more benefits than just introducing
NullObjects.

(Read /working effectively with legacy code/ by Mike Feathers.)

> Also, it makes it impossible to detect a usage violation
> without doing a dynamic_cast on an argument with a polymorphic type.
> For example, if it is not valid to pass a null SimCity object to
> 'funk', you should pass by address and 'assert' that the parameter is
> not null. If it is not *possible* to pass a null SimCity object to
> 'funk', you should pass by reference, and catch errors at compile
> time.

That sounds like an argument for NullObject.

Compile time checking only catches some errors. All a NULL pointer needs to
accidentally become an undefinable reference is a single dereferencing star
* in the wrong spot.

If you are that frantic about them, use wall-to-wall unit tests. BTW my
Sanskrit dialog was written via test-first on every single feature. The test
cases can also record screen shots of the dialog's various locale skins, and
can record animations of the progress bar.

> > C++ supports qualifications before their qualified types, such as "const
> > SimCity &". I try to write expressions with the most important part
first.
> > There are also subtle technical reasons, in rare situations, to write
> > "SimCity const &", with the const after its type.
>
> What technical reasons? Style is not "technical"...

No ***. Style is not technical? Damn, am I ever glad I clicked on this post
today! Woah, you sure set me straight on that one! 

-- 
  Phlip
  http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces
Quantcast