[C++] Vector van abstracte classes vullen

[LauPro]

In een applicatie wordt er vanuit verschillende modules informatie verzameld. Deze informatie bestaat uit een klasse. Elke module kan 0 of meerdere classes met informatie naar de 'core' aanleveren. Deze core slaat deze gegevens op in een 'module-wrapped' klasse - althans dat is de bedoeling.

Het modulaire gedeelte werkt allemaal prima, echter loop ik nu even vast op de volgende code:

C++:

// abstracte klassen
class ModuleBase {
public:
virtual vector<DeviceBase> detect() = 0;
}

class DeviceBase {
public:
virtual void update() = 0;
}

[..]

// implementatie
vector<DeviceBase> SampleModule::detect() {
  vector<DeviceBase> devices;
  SampleDevice *dev;
  
  dev = new SampleDevice(1);  

  if (dev > 0) { devices.push_back(*dev); } // <-- error
  return devices;
}

class SampleDevice : public DeviceBase {
public:
SampleDevice(int);
void update(); // etc
}

De error die ontstaat is als volgt: cannot allocate an object of type `DeviceBase' because the following virtual functions are abstract: virtual void DeviceBase::update()

Een mogelijkheid is om vector<DeviceBase*> devices; te gebruiken met alle memory-management gevolgen van dien. Is er nog een andere optie om een vector te onderhouden met abstracte klassen welke vervolgens gevuld wordt door implementaties?

[ Voor 1% gewijzigd door LauPro op 17-09-2006 11:36 . Reden: Wat foutjes in de code. ]

[farlane]

Sowieso gaat dat niet werken want op het moment dat je je object in die vector stopt wordt ie gesliced ( als er geen abstracte functie was ). Je zult echt (smart)pointers moeten gebruiken om op te slaan in de vector.

[ Voor 9% gewijzigd door farlane op 17-09-2006 10:50 ]

[martennis]

als je dit rechtsreeks gekopieerd hebt, mis ik nog een haakje bij

code:

vector( SampleModule::detect() {

anders heb ik niets gezegd

[Verwijderd]

Je maakt 2 fouten:

1. Een SampleDevice object is geen DeviceBase object. Je kunt dus ook niet een SampleDevice object in een vector<DeviceBase> stoppen. Als je polymorfisme wilt gebruiken, dan zul je toch echt met pointers moeten gaan werken.

2. DeviceBase is abstract. Dat betekent dat je geen vector<DeviceBase> kunt maken, want je kunt geen vector vullen met DeviceBase objecten omdat je die niet kunt instantieren.

Je zult dus inderdaad met pointers moeten gaan werken die wijzen naar instanties van classes die afgeleid zijn van DeviceBase.

[LauPro]

Dat vector<DeviceBase> niet gaat werken was ik al achter, ik heb het nu wel werkend met vector<DeviceBase*>. Alleen ik vind het een beetje ranzige constructie persoonlijk voor zover ik nu kan beoordelen. Daarnaast is er naar mijn idee geen sprake van 'smart pointer' nog maar eerder een 'stupid pointer'.

Dus ik ben even op zoek gegaan naar zo'n 'smart pointer' class en kwam de volgende site tegen: http://ootips.org/yonat/4dev

Volgens mij komt daar de pointainer het dichtste in de buurt?

[.oisyn]

vector<boost::shared_ptr<DeviceBase> >?

[LauPro]

Het idee was een beetje dat het ook nog wel embedded kon draaien deze app, dus het linken naar boost lijkt me niet echt handig?

Overigens gaat dit memory management in dit geval eigenlijk alleen maar om het weer verwijderen van items?

[JeromeB]

LauPro schreef op zondag 17 september 2006 @ 14:44:
Het idee was een beetje dat het ook nog wel embedded kon draaien deze app, dus het linken naar boost lijkt me niet echt handig?

Die smart-pointers van boost lijken me anders ook goed toepasbaar binnen Embedded Environments.

LauPro schreef op zondag 17 september 2006 @ 14:44:
Overigens gaat dit memory management int dit geval eigenlijk alleen maar om het weer verwijderen van items?

zoiets moet dan toch voldoende zijn:

C++:

for(vector<DeviceBase*>::iterator iter=v.begin(); iter!=v.end(); ++v) delete *iter;
v.clear();

[Zoijar]

Waarschijnlijk niet exception safe. Riskant in ieder geval, en je moet het overal checken dan.

[farlane]

LauPro schreef op zondag 17 september 2006 @ 14:44:
Het idee was een beetje dat het ook nog wel embedded kon draaien deze app, dus het linken naar boost lijkt me niet echt handig?

Wat bedoel je precies met embedded? Is dat als op een PDA oid of meer in een uP ala ATmega oid? In het eerste geval lijkt het me niet echt een probleem nl maar in het tweede geval zou ik ueberhaupt geen C++ gebruiken.

Wat je bv zou kunnen doen is een dedicated object gebruiken voor het instantieren en deleten van je ObjectBase objecten. Op die manier kun je de administratie centraal bijhouden en bv in een debugbuild het een en ander aan logging doen als een object niet opgeruimd wordt. ok, het vergt nog wel het een en ander aan consistentie van jou maar als je daar niet geschikt voor was had je wel een andere taal gekozen toch?

[ Voor 31% gewijzigd door farlane op 17-09-2006 16:05 ]

[LauPro]

Op dit moment is er een object genaamd modulecontroller welke de modules beheert. Dus zowel het toevoegen van nieuwe modules als het weghalen. Hierin kan dus ook prima het extra management worden gestopt voor de pointer-vector.

Alleen er is vanuit STL dus geen systeem om hetgene dat ik in de SP beschreef te regelen?

Met embedded bedoel ik een systeem met ong. 32 MB/ram. Tijdens het installeren van boost zag ik dat de hele package 12 MB was, natuurlijk wordt niet alles gebruikt voor 1 simpel template klasje maar ik moet opletten dat er niet teveel gelinkt gaat worden.

[MSalters]

Het voordeel van al die smart pointers is dat het templates zijn. Ongebruikte functies worden niet eens geïnstantieerd, laat staan gecompileerd. Er is een (gratis) TR over C++ performance, met anme gericht op embedded systems. Al gelezen?

[Olaf van der Spek]

.oisyn schreef op zondag 17 september 2006 @ 13:55:
vector<boost::shared_ptr<DeviceBase> >?

Waarom geen pointer_container?

http://boost.org/libs/ptr_container/doc/ptr_container.html

[farlane]

MSalters schreef op zondag 17 september 2006 @ 21:52:
Er is een (gratis) TR over C++ performance, met anme gericht op embedded systems. Al gelezen?

Nee interessant heb je een link?

[Olaf van der Spek]

farlane schreef op maandag 18 september 2006 @ 01:26:
[...]


Nee interessant heb je een link?

http://www.google.nl/sear...%20embedded%20performance

[ Voor 1% gewijzigd door RobIII op 18-09-2006 10:39 ]

[farlane]

OlafvdSpek schreef op maandag 18 september 2006 @ 10:38:
[...]

http://www.google.nl/sear...%20embedded%20performance

Bedankt ( Schaam )