|
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