* Thomas Krog
> > Jeg misliker generelt ideen med STL-containere av dumme pekere,
> > men det burde gå greit i dette tilfellet.
>
> kan du uddybe det (eventuelt med et eksempel)?
Et av de store poengene med STL containere er basic exception safety
og automagisk opprydding. Dvs. jeg kan skrive noe sånt:
void
foo()
{
vector< int > v;
// whatever
fill_n( back_inserter( v ), INT_MAX, 0 );
}
og være sikker på at dersom ting går galt, så vil ting frigjøres
automagisk (vel å merke holder ikke dette dersom dtor'en til typen man
har en vector av oppfører seg rart). Det er blitt en vane å la være å
tenke på ressursfrigjøring og lage kopier av vectorer uten å bekymre
seg om hva som eier hva og hvor ting går ut av skop:
vector< int >
foo()
{
vector< int > tmp;
generate_n( back_inserter( tmp ),
<whatever>,
rand );
return tmp;
}
er en helt grei måte å håndtere "arrays" på.
Problemet med vector<T*> (vector er ikke alene om det, forresten) er
at man risikerer denne situasjonen:
vector1 vector2
+-+ +-+
|*--------><obj1><---------*|
+-+ +-+
|*--------><obj2><---------*|
+-+ +-+
|*--------><obj2><---------*|
+-+ +-+
og da er man tilbake til C sin problemstilling om eierskap av
objektene og ansvar for frigjørelse av minne/ressurser. I tillegg
frigjøres ikke minne tildelt <obj> automatisk:
void
foo()
{
vector< int* > v;
for ( size_t i = 0U; i != 10U; ++i )
v.push_back( new int( i ) );
} // memory leak
Et annet poeng er denne snutten:
void
bar()
{
vector< int > v1;
vector< int* > v2;
// populate
throw "ugh!";
}
I det man kommer til throw, er det ikke noe problem med v1, da den vil
frigjøre ting automagisk. Derimot, v2 vil frigjøre plassen tildelt
pekere, men ikke objektene som pekere peker på. Det er ikke realisisk
å ha en try-catch rundt hver eneste blokk som deklarerer variable av
typen <container of T> og det kan potensielt oppstå et unntak (blir
akkurat som Java).
Derfor finner man på ymse smart_ptrs (<URL:
http://www.boost.org/>) for
å rette på problemet (ok da, det finnes andre grunner til vector<
smart_ptr< T > >).
ivr
--
Besides, meat tends to run away when possible, or fights. Either
response presents behavioral challenges too complex for any existing
robot.
-- Stuart Wilkinson, inventor of the "gastrobot"