Boost logo

Boost :

From: Darin Adler (darin_at_[hidden])
Date: 1999-12-29 12:56:33


> I guess what I'm saying is that code like A and C should be the norm, unless
> you have a really good reason to take a nonmodifiable reference to an
> internal data member (no reason comes to mind). But if you _do_ want the
> reference, then it's your job to make sure that that member doesn't die
> [have its lifetime end].

Perhaps I should demonstrate with a more realistic example. Note that the
coding style is a bit yucky:

    class CatalogEntry
    {
    public:
        // ...
        const string& name() const;
        // ...
    }

    class Catalog
    {
    public:
        // ...
        void remove_by_name(const string& name);
        // ...
    }

    void Catalog::remove_by_name(const string& name)
    {
        // ... code to destroy entry stored in the catalog ...
        std::cout << "entry " << name << " was removed\n";
    }

    void remove_entry(Catalog* catalog, CatalogEntry* entry)
    {
        catalog->remove_by_name(entry->name());
    }

In this example, no one is "taking a nonmodifiable reference to an internal
data member". But the problem happens nonetheless. Once the entry has been
destroyed in Catalog::remove_by_name, the name parameter contains a dangling
reference to the name stored inside the catalog entry.

To avoid this problem, I'd suggest a change to the name() function to return
a string instead of a const string &. What are alternative disciplines that
avoid problems like this one?

    -- Darin


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk