Vererbtes Element überschreiben

Gast #3037404
Lesenswert?

HI zusammen,
ich habe folgendes Problem:

Ich habe eine Klasse "BASETask" die als Element unter anderen ein Zeiger 
auf ein Objekt dieser Basis-Klasse hat. Die Klasse "StandardTask" erbt 
von "BASETask".

Jetzt ist es so, dass Klassen, die von BASETAsk erben, das Element 
"pHeadTask" verwenden und Objekte dieser vererbten Klassen auf 
Funktionen mit dem gerebeten Element Headtask aufrufen. Also 
pHeadTask->getStrComment(). Diese Funktion gibt es aber in des 
Basisklasse nicht, ergo Copile-Fehler. Wie müsste ich dass denn machen. 
Eine Idee wäre, das Element pHeadTask virtuell zu machen und in jeder 
abgeleiteten Klasse zu überschreiben. Schließlich muss pHeadTask immmer 
ein Zeiger auf die Klasse selbst sein.
1
ref class BASETask 
2
{
3
protected:
4
  String^ taskName;
5
  BASETask^ pHeadTask;
6
  int taskID;
7

8
  cliext::vector<BASETask^> subTaskPtrsVektor;
9
  cliext::vector<BASETask^>::iterator subTaskPtrsIterator;
10
}
11

12
ref class StandardTask:public BASETask
13
{
14
  String^ strComment;
15
  int iPrio;
16
    public:
17
        String^ getStrComment(void);
18
  void setStrComment(String^ _strComment);
19

20
}


Ich hoffe ich habe mein Anliegen einigermaßen verständlich ausgedrückt. 
Ich danke für eure Hilfe,
Viele Grüße
Rainer
Gast #3038031
Lesenswert?

Es soll ein Aufgabenplaner werden. Dabei ist jede Aufgabe ein Task. Es 
gibt aber verschiedene Typen von Tasks.

1. Ein einfacher Task, mit dem man nur Aufgabenbäume erstellen kann: 
Also ein Task (Aufgabe) die wiederum ggf. Unteraufgaben hat.

2. Ein etwas erweiterter Task, der sich auch seine Position in einer 
Listbox merken kann. Damit kann man dann sowas wie im angehängten Bild 
bauen (funktionierte auch schon vor der Aufteilung der Funktion in 
verschiedene Klassen mit Vererbung)

3, Ein noch weiter erweiterter Task, der sich eine Priorität merken kann 
und dann nach dieser sortiert in einer Listbox erscheinen kann.

Im Prinzip ist also das Konstrukt so, dass jede Instanzierbare Klasse in 
dieser Vererbungshierarchy Zeiger auf sich selbst haben muss. Wenn der 
Zeiger nämlich vom Typ Basisklasse ist und ich Funktionen einer 
vererbten Klasse damit aufrufen will, kracht es ja, wie beschrieben.

Ich danke für eure Antworten
Angehängte Dateien:
Gast #3038048
Lesenswert?

Rainer Hohn schrieb:
> Im Prinzip ist also das Konstrukt so, dass jede Instanzierbare Klasse in
> dieser Vererbungshierarchy Zeiger auf sich selbst haben muss.
Da ist vermutlich ein Konzeptfehler.
Jede Klasse hat schon einen Zeiger auf sich selbst: Er heißt 'this'.

Ich denke, du willst in der Basisklasse eine virtuelle Methode anlegen, 
die dann in den Ableitungen überschrieben wird. Das spart auch diese 
seltsame Konstruktion mit dem pHeadTask.
Gast #3038146
Lesenswert?

Rainer Hohn schrieb:
> Nein, so seltsam ist mein Konstrukt nicht...ist eine ganz normale
> Verkettete Liste. Der this-Zeiger ist ja ein Zeiger auf das OBJEKT, bei
> verketteten Listen brauche ich aber zwingend einen Zeiger auf den
> gleichen (Klassen)-TYP.
Dann ist es aber kein Zeiger auf sich selbst sondern ein Zeiger auf ein 
anderes Objekt aus derselben Klassenhierarchie.

Aber auch da: Wenn alle Objekte eine Methode anbieten sollen, mach sie 
in deren Basisklasse virtuell und überschreibe sie dann.

Wenn du aber Methoden brauchst, die nicht alle Objekte haben, sondern 
nur einige bestimmte, dann wäre das wohl ein Fall für den dynamic_cast. 
Dabei aber den Fehler abfangen, denn möglicherweise lässt sich nich 
jedes Objekt in das gewünschte Objekt casten.

Verkettete Listen gibt es außerdem schon fertig in der STL. Gibt 
sicherlich auch ein Pendant dazu für den CLI-Blödsinn.
#3038357
Lesenswert?

Rufus Τ. Firefly schrieb:
> Rainer Hohn schrieb:
>> ob es da nicht ein ganz elegantes C++-Konstrukt gibt
>
> Da Du nicht in C++ programmierst, kann Dir da auch kein C++-Konstrukt
> helfen.
>
> "C++/CLI" ist kein C++, sondern eine Microsoft-Perversion für .Net.

Auch durch Wiederholung wird das nicht "wahrer", 
http://www.gotw.ca/publications/C++CLIRationale.pdf
"C++/CLI’s mission is to provide direct access for C++ programmers to 
use existing CLI libraries and create new ones, with little or no 
performance overhead, with the minimum amount of extra notation, and 
with full ISO C++ compatibility."
Man könnte sich höchstens streiten, ob das nun mathematisch eine 
Obermenge ist oder nich.

Einsetzen würde ich es für die Aufgabe hier allerdings definitiv nicht, 
sondern nur da wo es sinnvoll ist (performance/native code/C++ interop)
#3040616
Lesenswert?

Arc Net schrieb:
> C++/CLI’s mission is to provide direct access for C++ programmers to
> use existing CLI libraries and create new ones

Warum muss man eine Sprache abändern, um Zugriff auf gewisse 
Bibliotheken zu erhalten? Leuchtet mir irgendwie nicht ein. Wer C++ 
will, soll halt auch C++ verwenden.

Wer hingegen .NET haben will, der kann doch auch gleich C# verwenden. 
Die Sprache ist ja nicht mal schlecht designed. Da war ja der Anders 
Hejlsberg am Werk, den man mit viel Geld abgeworben hat, weil man in den 
eigenen Reihen offenbar keine fähigen Leute für sowas hatte :)

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren