Thread: the null reference

I generally avoid working with pointers whenever possible, but of course it can't be totally avoided. so last night I came up with this idea of a class that would make it possible to eliminate the need for them in many situations. I'm hoping you guys can flesh out any bugs but mostly how you'd feel about using something like this. here's an example usage:

Code:

#include <iostream>
#include "null.hpp"

using namespace std;
using namespace xtd;

class ancestor
{
      public:
      
      ancestor( string const & name, ancestor const & parent = null )
      : name( name ), parent( parent )
      {      }

      string 
            name;
      ancestor const
            & parent;      
};

void
print_lineage( ancestor const & my )
{
      cout << my.name << endl;
      if( my.parent != null )
      {
            cout << my.name << "'s parent: ";
            print_lineage( my.parent );
      }
}

int
main( void )
{
      ancestor
            God( "God" ), 
            Adam( "Adam", God ), 
            Cain( "Cain", Adam );                
      print_lineage( Cain );
}

>> If you have to check a reference for null, you've not eliminated the need for pointers... you made references into pointers, and at the same time confused everyone.

yes - if every reference handled had to be checked for null, but that is not what I am advocating here. even with pointers, we generally know exactly when to check for NULL (eg: malloc) and when not to (eg: within an array processing routine). it's all about context.

>> The point of a reference isn't just to allow different syntactical sugar.

well, they allow us to write code that is clearer and more uniform. if you prefer to call that sugar then so be it.

>> No offense, but this is even less than useless. It's completely deranged.

classic.

perhaps it's not for everyone, but I encourage you to experiment with it some more before you rule out it's usefulness.

I generally avoid working with pointers whenever possible, but of course it can't be totally avoided.

Maybe it "could" be totally avoided, but no sane person would tell you that in every class definition you have to use a reference (making it non-copyable) or an actual instance of a class all to avoid the use of pointers.

I agree, I don't use pointers when I don't have to. But sometimes "I have to." Any time you have to "iterate" a structure, any time you need to decide whether or not to dynamically allocate a new class object, etc., you're going to use pointers (iterators are an example of implicit pointer use).

I agree that references have certain advantages over pointers in certain situations. So that's why they're there... and I'm not exactly sure what you're trying to accomplish then...

If people want to litter their code with the over-use of pointers (over-using the this-> is a pet-peeve of mine), so be it. It might be kinda silly to you or me, but the functionality of references already exists, so what are you trying to do? Maybe you can write your own language where everyone will be forced to do things the way you want, and you can name it Java.

the code I posted was simply a contrived example. a more typical usage might be:

Code:

class database
{
	class table
	{	};

	table &
	retrieve_table_1( string const & name )
	{
	/*
		if found, return a reference to the table.  
		otherwise, return null.
	*/	
	}

	bool
	retrieve_table_2( string const & name, table & result )
	{
	/*
		if found, result is valid and return true. 
		otherwise, return false.
	*/	
	}

	table *
	retrieve_table_3( string const & name )
	{
	/*
		if found, return a pointer to the table. 
		otherwise, return NULL.
	*/	
	}

};

given the choice, I would choose to use the function retrieve_table_1 because it has a more simple interface. moreover, since it's clear that the table may not exist there wouln't be any confusion about the need to check for a null reference.

You've lost me. What good does it do whether or not you can check if a reference is null or not if I'm forced to call the function like this:

Code:

Table m_table;

table = retrieve_table_1( string const & a_name );

In which case, it won't even compile without there being something to be referenced.

There never has been, nor will there ever be such a thing as a null reference in C++. There is no way of creating such a thing and no way for such a thing to ever exist. Any such attempt to create one is an invalid C++ program.
The whole idea is itself a bug. What you're thinking of is impossible - end of story - Kapish?!
In fact I think it would be quite a stretch for one to call themselves a C++ programmer without knowing this.

Section 8.3.2 paragraph 4:
"A reference shall be initialized to refer to a valid object or function.
[Note: in particular, a null reference cannot exist in a well-defined
program, because the only way to create such a reference would be to bind it
to the ``object'' obtained by dereferencing a null pointer, which causes
undefined behavior."

like this:

Code:

table 
      & table = retrieve_table_1( name );
if( table != null )
{
      for( unsigned r = 0; r < table.rows( ); r++ )
      {
      /*
            process a row
      */      
      }      
}

I think Sebastiani wants the kind of pointer-like object references that exist in Java and co.

No, it is just undefined behaviour. ref refers to an object that no longer exists.

Originally Posted by manav

undefined!!!
that's the purpose and intent of the OP (at least it was my purpose)
how do i check that "ref" is a valid or invalid reference?
we have this convention of NULL pointer being invalid (not a bulletproof way though, but that's C++, and programmers know)
how we check for above "ref" being valid or invalid?
i has the same situation in my project, and it is giving me nightmares! >_<

One way to easily detect that some object has been free/deleted is to create your own versions of new & delete, and let the delete version fill in the memory with some known pattern (e.g. 0xCFCFCFCFCF - that's almost guaranteed to crash you if you use it as a pointer).

--
Mats