Using References as member variables

Hi,

I am just in the process of changing some classes in my program to have references instead of pointers as member variables. One idea behind it is that it should not be able to initialize any member of the class with a null pointer.

However I came at some point to realize that references can be as dangerous as pointers. Below is some code which dumps core on the last line, for obvious reasons.

Code:

---

#include <string>
#include <iostream>

class T
{
public:
        T( std::string& s )
          : _s( s ) {};
        void print() { std::cout << _s << std::endl; }
private:
        std::string& _s;
};

int main()
{
        T * myobj = 0;
        try {
          // Creating a string on the stack
          std::string stackstring( "Hello World!" );
          myobj = new T( stackstring );
          myobj->print();
          // Checking if myobj really contains a reference
          stackstring = "Hello Mom!";
          myobj->print();
        }
        catch ( ... ) {
          delete myobj;
          throw;
        }
        if ( myobj ) {
          // myobj still exists but stackstring not
          myobj->print();
        }
}

---

Now does anybody know of some magic tricks to avoid these kind of problems? I can only think of making _s a pointer again and checking if it is 0 each time before accessing it.

Thanks for any thoughts on this subject.

You want to avoid leaks in the event of exceptions right? Why not have a look at class auto_ptr of the standard library.

seems like your using your refference like a variable. Why not just make it a variable and not a pointer or a refference.

As for checking a pointer to make sure it's not zero every time you use it, that's why you should use access methods. Then you only check it once and you've got protection throughout....

If you've got your heart set on a refference you could of course define a member variable and pass a refference in your access method....

As far as I know, it is not common to store a reference or pointer in a general-purpose class. I think it more common to store a copy of an object. If you want to store a reference, you could add code to validate the object before using it. So in the print member function, you could somehow validate _s.

I don't know what function that would be; it would, however, be implentation-dependent, right? It would help if the standard had a funtion we could call that would determine if an address is a valid address.

There's a simple rule to follow. Never reference from an outer scope a variable in an inner scope. This covers your problem as well as the dreaded "return reference to local" newbie error.

The scope of your T object is the main function (because you delete it at the end, you could emphasize this by using std::auto_ptr or boost::scoped_ptr instead of a raw pointer). The scope of stackstring is the try block. By assigning this object to the reference in the T object, which is in a "more outer" scope, you're set up for disaster.

I actually like using references as members instead of pointers when a null value is not allowed. Your example does not show a problem specific reference member variables, the same problem would occur if you used pointers:

Code:

---

#include <string>
#include <iostream>

class T
{
public:
        T( std::string* s )
          : _s( s ) {};
        void print() { if (_s) std::cout << *_s << std::endl; }
private:
        std::string* _s;
};

int main()
{
        T * myobj = 0;
        try {
          // Creating a string on the stack
          std::string stackstring( "Hello World!" );
          myobj = new T( &stackstring );
          myobj->print();
          // Checking if myobj really contains a reference
          stackstring = "Hello Mom!";
          myobj->print();
        }
        catch ( ... ) {
          delete myobj;
          throw;
        }
        if ( myobj ) {
          // myobj still exists but stackstring not
          myobj->print();
        }
}

---

As others have said, the problem is assigning a reference or pointer to variable in an inner scope and then using it in an outer scope. Using a pointer member and checking for null would not fix it.

Thanks everybody for your ideas. Sometimes it really makes me wonder how different worlds of IT can be. If you look at relational databases, referential integrity is a very important and a very easy to implement thing. You have a master table (which in my example would hold objects of type std::string) and you have a slave table (holding objects of type T). Now if an object of type T references an object in the first table either:
- it is impossible to delete the referenced object
- deleting the referenced object will also delete all objects referencing it (on delete cascade)

The first option is imho impossible to implement in C++, the second one requires a lot of manual work (even if one uses smart pointers I assume it will take a lot of work).

To jlou: thanks for pointing out that the problem exists with pointers as well. However, passing the address of an object created on the stack to a constructor (myobj = new T( &stackstring )) is something that an advanced programmer would most likely not do without checking exactly what's going on in the constructor. Passing a reference to a temp object to a constructor (myobj = new T( stackstring )) is a lot less suspicious, so the effect that it does not work will come as a nasty surprise. Which raises again the original question, if it is a good idea to use references as members...

Relational databases are a lot more specialized than a general-purpose programming language...

Quote:

---

Originally posted by treuss
The first option is imho impossible to implement in C++, the second one requires a lot of manual work (even if one uses smart pointers I assume it will take a lot of work).

---

Probably they are easy if you want them to be.

It wouldn't be all that hard. You'd just have to do the work that the DB developers do. :)

The real problem is the lack of backreferencing. What happens in your DB example if there are three tables, A, B and C? A and B both have foreign key fields that reference C. If something from A is deleted, it should delete the referenced value in C, but what about values in B that reference the same value in C? Do they get deleted too? And if the relationship is complex enough, wouldn't that lead to the possibility of emptying the entire database?

Quote:

---

Originally posted by CornedBee
It wouldn't be all that hard. You'd just have to do the work that the DB developers do. :)

---

However not all that they do.

Quote:

---

Originally posted by CornedBee
The real problem is the lack of backreferencing.

---

In C and C++ there are things such as double-linked lists that make "backreferencing" easy.

That's not what I mean.

Then what do you mean?

I mean that an object doesn't know about a reference to it.

And how is that different from a database? How does the database equivalent of an object know about the database equivalent of a reference? I think the answer is that the database knows about objects and references, but database "objects" don't know about "references" to them.

The database though has strictly defined areas where it can search for referenced or referencing objects. C++ cannot, you can't search the whole memory or even stack for pointers. It would require every pointer to register in some global datastructure.

Quote:

---

Originally posted by CornedBee
Relational databases are a lot more specialized than a general-purpose programming language...

---

But referential integrity is imho a very general purpose thing. I dare to say that a lot of program crashes are caused by broken referential integrity (e.g. accessing a null-pointer where the program expects a pointer to an object). So shouldn't a programming language support this principle (open question to the void)?

Quote:

---

Originally posted by CornedBee
The real problem is the lack of backreferencing.

---

Keeping a list of referencing objects in the object that is referenced is what I had in mind. But it is work I am not willing to put into my program, because in the end the program logic should ensure the referential integrity as well (i.e. the program at the beginning of this post has errors breaking it). So I would write a lot of code to protect my program from coding errors...

Quote:

---

Originally posted by Sam Hobbs
Probably they are easy if you want them to be.

---

Is there actually a way to prevent an object from being deleted? (Option 1). I could of course provide a static function that would first check and then delete the object, but could I enforce that this function was used? Any ideas on that appreciated.

Quote:

---

Originally posted by CornedBee
If something from A is deleted, it should delete the referenced value in C...

---

No. If something from C is deleted, it should delete all values from A referencing it.

Quote:

---

And if the relationship is complex enough, wouldn't that lead to the possibility of emptying the entire database?

---

Depending on your database design, possibly. If you delete a customer from your database, you will automatically also delete all his phone numbers, all orders that he has made, all items that were part of these orders, all discounts that related to an item that was part of the order of that customer, ... Simple as that.

Keeping track of references is something that is done for instance in Java. There you simply cannot explicitly delete objects, the garbage collector takes care of this. I don't think it makes sense to both allow explicit deletion and then prevent it if there are still references to the object.
Use reference counting instead, like boost::shared_ptr. Of course this only works with objects on the heap.

Those that say it can't be done provide opportunity for those of us that can.