the correct way to delete a map

[Nick Keighley]

Hi,

I have a map containing pointers. When I destroy the map I want to
delete
all the pointers.

typedef std::map<std::s tring, const T*Table;

void destroy_map ()
{
for (Table::iterato r i = table_.begin(); i != table_.end(); ++i)
{
delete (*i).second;
table_.erase (i);
}
}
this crashes. Does the erase() invalidate the iterator?

This was the code I found on the net (latout fixed a bit)

for (map::iterator itr = myMap.begin(); itr != myMap.end())
{
if(itr->value == something)
myMap.erase(itr ++);
else
itr++;
}

which it is claimed is from Josuttis. I suppose the fact that it
didn't compile should of made me doubt this...
--
Nick Keighley

[Daniel T.]

Nick Keighley <ni************ ******@hotmail. comwrote:

it seemed not unusual for a container to own an object it pointed
to. If you're newing a lot of similar objects then you need to keep
them somewhere. Why not a container?

There is some confusion here I think. When you say "you're newing" you
don't actually mean the programmer, rather some object is instantiating
some other object. Generally, the instantiating object is the owner.

[Nick Keighley]

On 9 Nov, 11:07, "Daniel T." <danie...@earth link.netwrote:

Nick Keighley <nick_keighley_ nos...@hotmail. comwrote:

it seemed not unusual for a container to own an object it pointed
to. If you're newing a lot of similar objects then you need to keep
them somewhere. Why not a container?

There is some confusion here I think. When you say "you're newing" you
don't actually mean the programmer, rather some object is instantiating
some other object. Generally, the instantiating object is the owner.

yes I meant an instantiating object was newing the Type objects.
Type is actually an abstract base class. The instantiator generates
many objects of various classes derived from Type. I can't see how
the parser *can* hold many Type objects without using a container of
some sort.

Simplifying outrageously:-

void parse_file (Token_stream& toks)
{
while (toks.more)
{
Type* type;
string name = toks.current_to ken;

toks.next();

// this is hidden in a factory
if (toks.current_t oken == "type_a")
type = new Type_a(toks);
else
if (toks.current_t oken == "type_b")
type = new Type_b(toks);
else
...

symbol_table.in ert(name, type);
}
}

In this case the parser which built the symbol table
ceases to exist once the table is built. So it can't
own the Type objects!
this seems such a natural idiom to me and falls naturally out
of the requirement. So I'm either abusing OOP/C++ or I don't
understand
what "ownership" means.

help!
--
Nick Keighley

[Daniel T.]

Nick Keighley <ni************ ******@hotmail. comwrote:

"Daniel T." <danie...@earth link.netwrote:

Nick Keighley <nick_keighley_ nos...@hotmail. comwrote:

it seemed not unusual for a container to own an object it
pointed to. If you're newing a lot of similar objects then you
need to keep them somewhere. Why not a container?

There is some confusion here I think. When you say "you're
newing" you don't actually mean the programmer, rather some
object is instantiating some other object. Generally, the
instantiating object is the owner.

yes I meant an instantiating object was newing the Type objects.
Type is actually an abstract base class. The instantiator generates
many objects of various classes derived from Type. I can't see how
the parser *can* hold many Type objects without using a container
of some sort.

In this case the parser which built the symbol table ceases to
exist once the table is built. So it can't own the Type objects!

So the object that instantiates the parser takes ownership of the Type
objects. The point is though that the container didn't create the
objects, so it doesn't own them. The object that created the parser and
used it as a surrogate, indirectly created the Type objects and therefor
owns them.

[James Kanze]

On Nov 9, 12:07 pm, "Daniel T." <danie...@earth link.netwrote:

Nick Keighley <nick_keighley_ nos...@hotmail. comwrote:

it seemed not unusual for a container to own an object it
pointed to. If you're newing a lot of similar objects then
you need to keep them somewhere. Why not a container?

There is some confusion here I think. When you say "you're
newing" you don't actually mean the programmer, rather some
object is instantiating some other object. Generally, the
instantiating object is the owner.

Generally, in an OO design (which works well in many fields of
endevor), once created, an object is on its own. The object
itself decides when it's no longer needed, and deletes itself.

--
James Kanze (GABI Software) email:ja******* **@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Roland Pibinger]

On Thu, 08 Nov 2007 02:55:35 -0800, Nick Keighley wrote:

>I have a map containing pointers. When I destroy the map I want to
delete all the pointers.

typedef std::map<std::s tring, const T*Table;

Std containers were designed only for values. They don't work with
pointers (to objects), at least not without clumsy and prohibitive
workarounds. This is one of the major reasons for the low acceptance
of STL in the real world (in contrast to the ongoing STL hype among a
small group of C++ gurus and "gurus").
So, better look for a container that works with pointers. You can even
built your own on top of an STL container.
BTW, std::string as key can introduce problems, too. Depending on your
basic_string implementation it may dynamically allocate an internal
buffer for each copy. This may be unacceptable for a real parser.
--
Roland Pibinger
"The best software is simple, elegant, and full of drama" - Grady Booch

[Roland Pibinger]

On Fri, 09 Nov 2007 18:36:32 -0000, James Kanze wrote:

>Generally, in an OO design (which works well in many fields of
endevor), once created, an object is on its own. The object
itself decides when it's no longer needed, and deletes itself.

But not in C++. Actually, a dynamically created object cannot decide
on its own when it's no longer needed.
The classic C++ idiom is to let an 'owner object' manage dynamically
created objects, preferably by deleting them in its destructor, a.k.a.
RAII. The best working idiom in this context is 'Creator As Sole
Owner' http://www.ddj.com/184409895 .
--
Roland Pibinger
"The best software is simple, elegant, and full of drama" - Grady Booch

[Joel Yliluoma]

On Thu, 08 Nov 2007 02:55:35 -0800, Nick Keighley wrote:

for (map::iterator itr = myMap.begin(); itr != myMap.end())
{
if(itr->value == something)
myMap.erase(itr ++);
else
itr++;
}

for(map::iterat or j, i = myMap.begin(); i != myMap.end(); i = j)
{
j = i; ++j;

if(i->value == something)
myMap.erase(i);
}

This is how I do it as I wasn't aware of erase() returning an
iterator (which apparently may be the case in some implementations ).

If you want to avoid the redundant default constructor
call of j, then write it as follows:

for(map::iterat or i = myMap.begin(); i != myMap.end(); )
{
map::iterator j = i; ++j;

if(i->value == something) myMap.erase(i);

i=j;
}

However, this code is more prone for errors: for example,
if you use "continue;" , it will omit "i=j;", causing an
infinite loop at worst.

--
Joel Yliluoma - http://bisqwit.iki.fi/
: comprehension = 1 / (2 ^ precision)

[Joel Yliluoma]

On Thu, 08 Nov 2007 02:55:35 -0800, Nick Keighley wrote:

for (map::iterator itr = myMap.begin(); itr != myMap.end())
{
if(itr->value == something)
myMap.erase(itr ++);
else
itr++;
}

for(map::iterat or j, i = myMap.begin(); i != myMap.end(); i = j)
{
j = i; ++j;

if(i->value == something)
myMap.erase(i);
}

This is how I do it as I wasn't aware of erase() returning an
iterator (which apparently may be the case in some implementations ).

If you want to avoid the redundant default constructor
call of j, then write it as follows:

for(map::iterat or i = myMap.begin(), j = i; i != myMap.end(); i = j)
{
++j;
if(i->value == something) myMap.erase(i);
}

--
Joel Yliluoma - http://bisqwit.iki.fi/
: comprehension = 1 / (2 ^ precision)