Gibt es in C++ eine Möglichkeit Objekte zu speichern.
Ich komma aus der Java-Programmierung und da kann ich ja einfach Object angeben, wenn ich etwas allgemein schreiben möchte.

Gibt es diese Möglichkeit auch bei C++?.
Ich möchte eine Liste als Speichermanager schreiben und dafür brauche ich natürlich eine allgemeine Ablage für die zu speichernden Objeckte.

Danke für eure Hilfe.

cu
rizor

Gibt es in C++ eine Möglichkeit Objekte zu speichern.
Ich komma aus der Java-Programmierung und da kann ich ja einfach Object angeben, wenn ich etwas allgemein schreiben möchte.
Gibt es diese Möglichkeit auch bei C++?.

in Java haben alle klassen 'object' als root. das ist bei cpp nicht so, d.h. du musst dir sowas selber bauen, mit 'ner abstrakten klasse, von der alle erben. sowas wie serialierung gibts auch nicht per default, aber bestimmt findet man irgendwo libraries, die das machen.

Was fricky geschrieben hat, finde ich zwar richtig - aber inwieweit es etwas mit der Frage zu tun hat, weiß ich nicht.

Ich schmeisse zum Thema "Serialisierung" mal "streams" und "operator<<()" und "operator>>()" in die Runde und wünsche eine gute Nacht,

Simon2.

Was fricky geschrieben hat, finde ich zwar richtig - aber inwieweit es etwas mit der Frage zu tun hat, weiß ich nicht.

du musst jetz wirklich schnell ins bettchen.

Ich möchte eine Liste als Speichermanager schreiben und dafür brauche ich natürlich eine allgemeine Ablage für die zu speichernden Objeckte.

Also wenn ich dich richtig verstanden hab, willst du einfach nur alle deine Objekte von einer Liste verwalten lassen. richtig?

Dann antworte ich darauf nur: "Ein echter Programmierer kann in jeder Sprache Fortran schreiben".

Sowas macht man in C++ normalerweise nicht. Warum willst du das denn machen?

aber normalerweise muss man eh (auch unter Java) extra Overhead betreiben, wenn man alles wild in einem Container mischt, denn mit nem "Object" kann man nix anfangen und man muss wissen, in was man es casten soll, wenn man es wieder rausholt.

der aufwand ist aber minimal.

Kreppel schrieb:

Es ist insgesamt also meistens keine so tolle Idee.

in bezug auf C++ hast du recht. CStoll hat sich immer furchtbar aufgeregt, wenn einer sowas gemacht hat. in Java ist das alles aber kein problem. sind beides halt zwei unterschiedliche systeme mit unterschiedlichen möglichkeiten usw. das kann man so direkt nicht vergleichen.

Ich möchte eine Liste als Speichermanager schreiben und dafür brauche ich natürlich eine allgemeine Ablage für die zu speichernden Objeckte.

Wenn ein Speichermanager im Sinn von Arbeitsspeicher gemeint ist, dann void*.

...in Java ist das alles aber kein problem....

Das würde ich nicht so sagen. IMHO (und nach meiner bescheidenen Java-Erfahrung) ist das "Java-Konzept"

• die Typinformation erstmal zu "vergessen" (beim Eintragen in den Container) und
• dann den "Empfänger" raten zu lassen,

durchaus Auslöser für unschönen Code und eine Menge Probleme.

imho macht C++ es da besser und ich finde es ein wenig seltsam, wenn Leute unglaublich viel Energie und "Frickelei" (nicht persönlich gemeint ) dareinstecken, diese Designsicherheit zu umgehen....

Aber es ist vermutlich der Versuch FORTRAN .... ähhh Java in C++ zu programmieren.

Gruß,

Simon2.

P.S.: Aber es stimmt natürlich, wir haben es hier mit unterschiedlichen Philosophien zu tun ... aber gerade deswegen rate ich dazu, in C++ auch die C++-Philosophie zu verwenden - so wie ich auch beim Javaprogrammieren die Javaphilosophie "überstreife" ... nicht, weil ich sie für die bessere hielte, sondern in dem Fall die "passendere".

thordk schrieb:

...bevor es die c++ templates gab, existierten auch nur entweder handgeschnitzte container oder gruseliger code, der mit void* pointern rumhantiert hat.

Definitv.
Allerdings gibt's bei C++ ja templates und die Container schon quasi "von Anfang an".
(Deswegen bekomme ich auch immer die Krise, dass bei uns in der Firma bei bestimmten Bereichen nur C (und kein C++) eingesetzt werden kann/darf/soll/.... was müssen wir uns da mit häßlichem und unsicheren selbstgeschriebenen Zeug rumschlagen, wo ein C++er einfach ein std::<xyz> hingeschrieben hätte )

Gruß,

Simon2.

im gegensatz zu c++ sind casts in java völlig ungefährlich.

dynamic_cast verhaelt sich aehnlich wie java casts.

und btw, es gibt einen grund warum java generics eingefuehrt hat: weil sie eben viel sicherer sind als lauter void* aeh, ich meine Object referenzen hin und her zu schieben.

klar fliegt "nur" eine exception - aber eine exception im falschen moment bedeutet dennoch, dass man sich davon nicht so leicht erholen kann (vorallem wenn man damit nicht gerechnet hat).

fricky schrieb:

...in Java ist das alles aber kein problem....

Das würde ich nicht so sagen. IMHO (und nach meiner bescheidenen Java-Erfahrung) ist das "Java-Konzept"

• die Typinformation erstmal zu "vergessen" (beim Eintragen in den Container) und
• dann den "Empfänger" raten zu lassen,

durchaus Auslöser für unschönen Code und eine Menge Probleme.

ne, Java vergisst nicht, welches object das ist. in Java gibts 'instanceof' um zur laufzeit zu testen, wohin man upcasten darf. für compilerchecks diesbezüglich gibts 'generics'. C++ hat ja sowas ähnliches, RTTI und 'typeid', aber das mag irgendwie keiner verwenden. C++-coder machen lieber alles statisch (mit templates) und hassen laufzeit-polymorphismus.

class DATA{

int a,b,c;
float d,e,f;

DATA(){}
~DATA(){}
void funk(..){}
.
.
.
};

DATA obj;

ofstream out("test", ios::out | ios::binary); 
out.write((char*)&obj, sizeof(DATA);

glaube nich das das geHT!?!?!?!

...
ne, Java vergisst nicht, welches object das ist....

Das habe ich auch nicht behauptet.
Es ist nur so, dass der "Empfänger" raten muss, was für ein Objekt denn da nun so als nächstes in der Hand hat und dann entscheiden (da gibt's auch kein Standardvorgehen), ob er unpassende Objekte einfach ignorieren, mit einem Fehler abbrechen oder versuchen soll, auf irgendetwas anderes zu casten.
Blöderweise hat man keine Möglichkeit mehr, die Fehlerursache selbst (falsches Objekt übergeben) noch zu korrigieren.
Ergo: Der Programmierer vergisst, welchen Typ das Objekt hat.
(wenn "Java" das vergessen würde, hätte der Programmierer ja nicht einmal mehr die Chance, halbwegs sicher zu raten)
... und das Vorgehen finde ich nach wie vor für Quatsch. Aber es ist eben zu Zeiten der Javaentstehung nicht anders möglich gewesen.
Im Prinzip ist das nicht anders als zu void*-Listen zu C-Zeiten (allerdings garniert mit einer Runtime, die einem die "Typflag"-Verwaltung abnimmt).

fricky schrieb:

...RTTI und 'typeid', aber das mag irgendwie keiner verwenden. C++-coder machen lieber alles statisch (mit templates) ...

zurecht, weil C++-Programmierer Programmierfehler halt lieber zur Compile- als zur Laufzeit bekommen ... weil sie seltsamerweise davon ausgehen, dass der Programmierer damit mehr anfangen kann als der Anwender.

fricky schrieb:

...hassen laufzeit-polymorphismus.
:)...

Im Gegenteil. Sie lieben Laufzeitpolymorphie (schau Dich nur mal hier im Forum an, wie oft unter dem Schlagwort "virtual" genau dazu geraten wird) ...
was sie nicht lieben, ist Problempropagation vom Entwickler zum Anwender.

Gruß,

Simon2.

würde man den ein objekt serialisieren? ...

Auch hier nochmal: Da es in C++ kein einheitliches (compiler-/plattformübergreifendes) Objektlayout gibt, rate ich dringend von einem "Binärspeichern" ab. Das mag immer erstmal die erste Idee sein, sie ist aber bestimmt nicht die Beste.

Mein Vorschlag: operator<<() und operator>>() überladen und das Teil so Wegschreiben und Einlesen, wie man es auch über die Konsole tut.
(Damit sind zwar die Files auch noch nicht Codepage-unabhängig, aber ansonsten schon weitestgehend compiler-/plattformunabhängig und für Codepage-Konvertierung (die sehr viel seltener sind) gibt es einfach und allgemeine Tools)

Hier übrigens mal eine (wie ich finde) recht gute Auseinandersetzung mit dem Thema...

Gruß,

Simon2.

fricky schrieb:

...
ne, Java vergisst nicht, welches object das ist....

Das habe ich auch nicht behauptet.
Es ist nur so, dass der "Empfänger" raten muss, was für ein Objekt denn da nun so als nächstes in der Hand hat und dann entscheiden

er muss nix raten. er kann das objekt fragen: "wer bist du?"

Simon2 schrieb:

fricky schrieb:

...RTTI und 'typeid', aber das mag irgendwie keiner verwenden. C++-coder machen lieber alles statisch (mit templates) ...

zurecht, weil C++-Programmierer Programmierfehler halt lieber zur Compile- als zur Laufzeit bekommen ... weil sie seltsamerweise davon ausgehen, dass der Programmierer damit mehr anfangen kann als der Anwender.

das ist aber eine sehr seltsame erklärung. die anderen sagen immer, RTTI u.ä. soll man nicht nehmen, weil es das programm ausbremsen würde.

...
er muss nix raten. er kann das objekt fragen: "wer bist du?"...

Und dann ?
Was macht denn ein Programm, das Autoteile verwaltet, wenn das Objekt sich als "Windelwechsler-Objekt" zurückmeldet ?
Erstmal per Reflection die Methoden abfragen und dann mit Windel wechseln weitermachen ?

Simon2 schrieb:

...das ist aber eine sehr seltsame erklärung. die anderen sagen immer, RTTI u.ä. soll man nicht nehmen, weil es das programm ausbremsen würde.

Das stimmt natürlich auch ... eine Technik kann ja mehr als einen Nachteil haben. Wie man das gewichtet, bleibt jedem selbst überlassen.

P.S.: Ich glaub übrigens nicht, dass RTTI in Java weniger performancefressend ist ... aber da hat man eben nichts Anderes.

Gruß,

Simon2.

er muss nix raten. er kann das objekt fragen: "wer bist du?"

Das kann man ja, wie du schon angedeutet hast, mit C++ auch machen.

std::vector<boost::any> myObjects;
//...
for (size_t i = 0; i < myObjects.size(); ++i)
{
    const std::type_info &info = myObjects[i].type();//Wer bist du?
    //...
}

Aber wie Simon2 auch schon sagte, man kann ja erstmal die Stream-Operatoren überladen und von Hand was basteln. Wenn man nur wenige Klassen hat, die serialisiert werden können sollen, ist das ja schnell gemacht.

...
Aber wie Simon2 auch schon sagte, man kann ja erstmal die Stream-Operatoren überladen und von Hand was basteln. Wenn man nur wenige Klassen hat, die serialisiert werden können sollen, ist das ja schnell gemacht.

Hmmm, muss ich das in Java nicht auch machen ? (also: serialize() implementieren)

Gruß,

Simon2.

Hmmm, muss ich das in Java nicht auch machen ? (also: serialize() implementieren)

Nicht wirklich. Serializables haben immer ne default implementierung die alles nicht transienten variablen rausschreibt.

Man kann Serialisierung in Java aber auch mit Reflection einmal für alle Objekte die es jemals geben wird machen, siehe Hibernate.

fricky schrieb:

...
er muss nix raten. er kann das objekt fragen: "wer bist du?"...

Und dann ?
Was macht denn ein Programm, das Autoteile verwaltet, wenn das Objekt sich als "Windelwechsler-Objekt" zurückmeldet ?
Erstmal per Reflection die Methoden abfragen und dann mit Windel wechseln weitermachen ?

sei doch nicht albern. was hat der windelwechsler zwischen den autoteilen verloren?

Simon2 schrieb:

P.S.: Ich glaub übrigens nicht, dass RTTI in Java weniger performancefressend ist ... aber da hat man eben nichts Anderes.

jedenfalls ist es nicht so schlimm, dass einem davon abgeraten wird. Javaprogramme sind sehr vieles dynamischer als C++-codes, benutzen oft on-the-fly class loaders, beans, etc. das ist da alles ganz normal.

...sei doch nicht albern. was hat der windelwechsler zwischen den autoteilen verloren?...

Ja, genau das ist ja die Frage, die man den Java-Container-Designern stellen muss.
Da Du aber als "Rausnehmer" alles erwarten musst (außer primitive Typen, aber eben auch "WindelwechselObject"), muss Dein Programm auch damit klarkommen (und zwar jedes wieder neu). In C++ sichert mir mein vector<Autoteil*> in meiner Schnittstelle schon zu, dass ich auf jeden Fall eine Autoteil-Schnittstelle vorfinde....

fricky schrieb:

...jedenfalls ist es nicht so schlimm, dass einem davon abgeraten wird. ...

Naja, man hat halt keine Alternative. :p

Aber prinzipiell entspricht das eben der oben schon angesprochenen "Java-Philosophie", alles zur Laufzeit zu machen/entscheiden (wird dann "dynamisch" genannt) - hat seine Vor- und seine Nachteile.

Gruß,

Simon2.