ich möchte nun ein array von beliebigen datentypen erstellen, die aber alle über eine bestimmte funktion beinhalten, diese möchte ich aufrufen OHNE vorher zu wissen um welchen datentyp es sich tatsächlich handelt. Geht das irgendwie?

ich möchte nun ein array von beliebigen datentypen erstellen, die aber alle über eine bestimmte funktion beinhalten

Kannst du das nochmals formulieren?

Was soll diese Funktion genau tun, wenn sie nicht weiss, um was für einen Datentyp es sich handelt? Kann es sein, dass du versuchst, eine Lösung für ein Problem zu finden und dabei auf einen einzelnen Ansatz fixiert bist? In diesem Falle solltest du uns eher mitteilen, was du erreichen möchtest, und nicht wie.

die basisklasse müsste ich ja um slicing zu vermeiden als pointer im vector verwenden std::vector<Basisklasse*>
und das gefällt mir nicht so gut, auch wenn der aufruf push_back(new ABgeleitet) sehr schön funktionieren würde, naja ich bin noch am probieren wie sähe denn eine professionelle lösung aus?

in einem spiel möchte ich alle objekte egal welcher art in einem vector speichern, alle sollen die funktion getObjectID besitzen, ich möchte allerdings aus bequemlichkeit keine virtuelle klasse einführen von der sich die anderen ableiten, sondern sie alle so reinpacken und selbst dafür sorgen dass die funktion vorhanden ist

Das ist ein ziemlich schlechtes Design (wie so oft, wenn der Beweggrund Bequemlichkeit ist). Hast du mal darüber nachgedacht, dass die ganze Logik, die Fälle unterscheiden müsste, auch geschrieben werden muss und in eine regelrechte Frickelei ausarten kann? Und dass die langfristige Wartbarkeit und Übersichtlichkeit enorm darunter leiden könnte?

shisha schrieb:

und das gefällt mir nicht so gut, auch wenn der aufruf push_back(new ABgeleitet) sehr schön funktionieren würde, naja ich bin noch am probieren wie sähe denn eine professionelle lösung aus?

Ich finde bereits "alle Objekte egal welcher Art im gleichen Container" bedenklich. Auch wenn du das mit Polymorphie machst, hast du im Grunde genommen die gleichen Probleme. Du solltest dir ernsthaft überlegen, was dagegen spricht, nur Objekte zusammen zu speichern, die auch etwas gemeinsam haben. Dadurch kannst du diese nämlich leichter und effizienter ansprechen. Zudem schaffst du eine logische Gliederung. Und glaub mir, du wirst später froh sein, wenn dein Design nicht auf Faulheit und Bequemlichkeit basiert. Besonders, wenn das Projekt einmal grösser werden sollte.

Für Objekte, die wirklich etwas gemeinsam haben, gibt es natürlich schon Methoden. Zeiger in STL-Containern sind in der Tat eine potenzielle Fehlerquelle, da man schnell einmal die Freigabe vergisst. Und Container, die einem die Speicherverwaltung nur teilweise abnehmen, sind auch nicht ganz das Wahre. Ein guter Ansatz für Polymorphie wären zum Beispiel Boosts Pointer-Container wie ptr_vector . Da werden Zeiger gespeichert, was Polymorphie erlaubt, und auch automatisch wieder freigegeben. Alternativ könntest du den shared_ptr -Smart-Pointer in STL-Containern einsetzen.

Aber nochmals: Denk dran, Polymorphie sinnvoll einzusetzen (d.h. wenn tatsächlich eine Gemeinsamkeit besteht, die du auch ausnutzen kannst, also über virtuelle Funktionen). Der kleine Mehraufwand wird sich auf jeden Fall auszahlen.

da hab ich die Monster, die Spielfigur, bewegliche Elemente, die Map mit soliden und nicht soliden Stücken

wie könnte ich das sinnvoll aufteilen?

einerseits möchte ich in jeder spielschleife eine art gravitation und kollisionserkennung wirken lassen, hierfür wäre es gut wenn alle objekte in einem container wären
andererseits, falls ich mal ne kleine KI machen will wäre es gut nur die Monster anzusprechen, ich habe starke probleme damit jetzt gut zu abstrahieren

ich denke schon darüber nach die daten in mehreren containern mehrfach zu specihern, aber das kann doch auch nicht das wahre sein.

Am quelltext von supertux scheitere ich im moment der ist schon viel zu fortgeschritten und vor allem zu viel um ihn auf einmal zu überblicken, ausserdem möchte ich sichergehn dass ich auch ein wenig denke , aber an dem problem komme ich nicht weiter grad

wäre dankbar für jeden tipp [auch wenn das jetzt nicht viel mit c++ an sich zu tun hat]

ich mache mir starke gedanken grad über den aufbau, also es sollte vlt mal ein jump n run werden, falls ich je fertig werde...

da hab ich die Monster, die Spielfigur, bewegliche Elemente, die Map mit soliden und nicht soliden Stücken

wie könnte ich das sinnvoll aufteilen?

So schön Pre-Design auch ist, eine iterative Herangehensweise würde dir IMHO um Längen leichter fallen. Sprich: Einfach anfangen, ohne zu planen.

ich mache mir starke gedanken grad über den aufbau, also es sollte vlt mal ein jump n run werden, falls ich je fertig werde...

Unterschätze ein Jump'n'Run nicht. Ich bin selber seit einiger Zeit an einem, und das gibt nicht gerade wenig zu tun.
Es kommt natürlich drauf an, wie viel du daran machen willst. Aber umso mehr solltest du dein Design von Anfang an gut planen, zumal es plötzlich sein kann, dass du das Spiel erweitern willst. Und es ist sehr motivationsraubend, wenn der ganze bisherige Code ein einziges Chaos ist und man versuchen muss, ein neues Feature einzubauen. Dann ist man nämlich gezwungen, den neuen Code darauf aufzubauen und verfrickelt sich so immer weiter. Ich habe selber nach einiger Zeit feststellen müssen, dass gewisse Dinge nicht durchdacht waren - und eine aufwändige Änderung durchgeführt. Aber ich bin froh, diese gemacht zu haben, ohne diese wäre das Entwickeln im Moment wohl viel mühsamer.

shisha schrieb:

da hab ich die Monster, die Spielfigur, bewegliche Elemente, die Map mit soliden und nicht soliden Stücken

Bei mir sieht es ziemlich ähnlich aus. Ich habe eine Klasse, die diese Spielelemente alle speichert. Da gibt eine Instanz des Spielers, einen Container mit allen Gegnern, einen verschachtelten, tabellen-ähnlichen Container der Tilemap (analog zu deinen soliden/nicht soliden Stücken), einen Container mit allen abgefeuerten Projektilen, einen mit Liften, und so weiter. Alle separat.

Die Objekte habe ich dabei so aufgeteilt, dass ich eine abstrakte Basisklasse für alle beweglichen Objekte habe. Davon erbt eine Klasse für die kollidierbaren Objekte. Davon erben wiederum Klassen für die Spielfigur, Gegner und Projektile. Du musst dir überlegen, wo es sinnvoll ist, Gemeinsamkeiten anzusetzen, und wo Abstraktion notwendig ist. Dabei gibt es nicht eine einzige Lösung, vieles wird sich mit der Zeit und zunehmender Erfahrung zeigen.

shisha schrieb:

einerseits möchte ich in jeder spielschleife eine art gravitation und kollisionserkennung wirken lassen, hierfür wäre es gut wenn alle objekte in einem container wären

Nein, das ist nicht nötig. Du definierst eben Funktionen, die mit allen kollidierbaren Objekten arbeiten können. Damit können sie aufgrund der Vererbung automatisch auch mit Gegnern und Projektilen arbeiten. Was du halt machen musst, sind mehrere Schleifen, um jeden Container durchzugehen. Aber das sollte kein Problem darstellen und ist die Spezialisierung allemal wert.

shisha schrieb:

andererseits, falls ich mal ne kleine KI machen will wäre es gut nur die Monster anzusprechen, ich habe starke probleme damit jetzt gut zu abstrahieren

Eben, für solche Fälle ist es von Vorteil, du definierst zum Beispiel Gegner-spezifische Algorithmen. Dann gehst du alle Gegner im Gegner-Container durch und wendest diese an - ohne Fallunterscheidung, da in diesem Container zwangsläufig nur Gegner sind.

shisha schrieb:

ich denke schon darüber nach die daten in mehreren containern mehrfach zu specihern, aber das kann doch auch nicht das wahre sein.

Wieso nicht? Was ist denn für dich nicht "das Wahre" daran? Wäre "das Wahre" wirklich ein einziger Massencontainer mit allem Möglichen drin? Hier kommt nämlich auch ein weiterer Aspekt hinzu: Die Performance. Nicht nur die dadurch notwendigen Fallunterscheidungen, sondern auch die Operationen im Container sind viel verheerender, da sich darin viel mehr Elemente befinden.

shisha schrieb:

wäre dankbar für jeden tipp [auch wenn das jetzt nicht viel mit c++ an sich zu tun hat]

So, ich habe dir nun ein paar Tipps gegeben. Wenn du welche davon nicht verstehst oder weitere Fragen hast, stell sie einfach.

So schön Pre-Design auch ist, eine iterative Herangehensweise würde dir IMHO um Längen leichter fallen. Sprich: Einfach anfangen, ohne zu planen.

Davon rate ich sehr stark ab.

Genau dieses "Leichter Fallen" ist das Problem, weil sich dahinter eine kurzfristige Sichtweise verbirgt. Ja, am Anfang ist es natürlich leichter. Umso mehr wachsen die Probleme mit zunehmendem Fortschritt, wenn keine stabile Basis vorhanden ist.

Ein geplantes Durchdesignen nimmt zwar etwas Zeit in Anspruch, jedoch holt man diese sehr schnell wieder ein. Entweder, weil man nachträglich wieder was umdesignen muss, oder - was viel schlimmer ist - wegen des Mehraufwands und der fehlenden Coderansparenz, die aufgrund einer schlechten Voraussetzung entstehen. Und wie gesagt, sind Momente alles andere als lustig, in denen einem bewusst wird, dass der gesamte bisherige Code (unter Umständen die Arbeit langer Zeit) einfach nur Schrott ist, und man jetzt die Wahl zwischen Neuanfang und dem Versuch hat, darauf basierend etwas halbwegs Vernünftiges zu Stande zu bringen.

Klar sollte man nicht monatelang am Design feilen, bevor man zum praktischen Teil kommt. Aber ein wenig überlegen schadet nie. Sehr viele Aspekte kristallisieren sich während des Programmierens heraus: Man sieht plötzlich, dass XY eine gute Herangehensweise an ein Problem ist und dass YZ durch jenen Ansatz viel effizienter gelöst werden könnte. Ohne praktische Erfahrung ist es auch relativ schwierig, abzuschätzen, worin gutes Design besteht. Trotzdem kann man sich einiges ersparen, wenn man ein wenig plant.

Trotzdem kann man sich einiges ersparen, wenn man ein wenig plant.

Das sicherlich, ich bin ein großer Fan der Planung. Nur denke ich, dass man ein bestimmtes "Level" erreicht haben muss, bevor man eine komplette Anwendung durchplanen kann. Und bei der Fragestellung gehe ich von diesem "Level" nicht aus.

Nur denke ich, dass man ein bestimmtes "Level" erreicht haben muss, bevor man eine komplette Anwendung durchplanen kann. Und bei der Fragestellung gehe ich von diesem "Level" nicht aus.

Da hast du natürlich Recht, das meinte ich auch mit meinem zweitletzten Satz vorhin. Naja, ein wenig kann man dennoch planen. Oder sich wie hier Tipps geben lassen, das ist zumindest schon besser, als voll ins Messer zu laufen und danach komplett frustriert zu sein.
(Auch wenn es so oder so zu Fehlschlägen kommt, aus denen man aber einiges lernt.)

Und man muss auch nicht die ganze Anwendung vollständig durchplanen, das ist sowieso kaum möglich. Es reicht, wenn man eine ungefähre Ahnung davon hat, wie man die ganz zentralen Dinge strukturiert. Es ist zumindest schon ein grosser Schritt, von einem boost::any -Massencontainer wegzukommen.