---

Hi there

Jeg har en klasse som indeholder en vector af sig selv:

#ifndef VertexH
#define VertexH
#include <vector>
class Vertex{
public:
Vertex(); //for vector
Vertex(int number);
Vertex(int number, int weight); //til directed
int getNumber();
int getWeight(); //til directed
bool isVisited();
void addVertex(Vertex vertex);

private:
//naboer
std::vector<Vertex> naboer;

int number;
int weight;
bool visited;
}; #endif

Når jeg skriver dette kommer compileren med en masse operator fejl i vector
klassen :(

Any suggestions ?

--
mvh

Bear

ICQ: 2745075

---

Bear wrote:

> Jeg har en klasse som indeholder en vector af sig selv:

Det er formentlig problemet.


> private:
> //naboer
> std::vector<Vertex> naboer;
~~~~~~
Vertex-kassen er endnu ikke defineret.
En klasse er ikke defineret før slut-klammen er nået. Du kan ikke
deklarere medlemmer af klassen i dens klasse-definition.

> Når jeg skriver dette kommer compileren med en masse operator fejl i vector
> klassen :(
>
> Any suggestions ?

std::vector<Vertex> *naboer;
er en mulighed.

--
Mvh
Lau Sennels

---

* the-merc@usa.net

> Jeg har en klasse som indeholder en vector af sig selv:


Won't work.


> Any suggestions ?


Ja, noen. vector<Vertex> ville ikke ha fungert uansett, selv om
vector<> aksepterte non-complete types (jeg tror det er det de heter).
Grunnen til dette er verdisemantikken til STL containere -- de tar en
_kopi_ av verdier som sendes i push_back, op=(), osv. Og du vil
definitivt ikke ta en kopi av nabonoder.

Det enkleste blir sannsynligvis en vector av pekere til Vertex, altså:

vector< Vertex* > neighbours;

Jeg misliker generelt ideen med STL-containere av dumme pekere, men
det burde gå greit i dette tilfellet.





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"

---

---

* 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"