c++ Klasse wegspeichern und danach auch laden

Daylight · 15. Februar 2018

Ich habe nochmal drübergelesen und ich glaube, ich habs jetzt kapiert.

Er will den im Speicher von einem Objekt seiner Klasse belegten Platz speichern? Byte für Byte?

Da aber gar nichts initialisiert wurde, und strings beliebig groß werden können, weiß er doch gar nicht vorher, wie groß ein solches Objekt dann ist? sizeof() liefert doch nur die Größe des Typs, oder liege ich da falsch?

Hoogo · 16. Februar 2018

Zitat von zrs1

...Wer heute in C# oder Java programmiert ist natürlich verwöhnt von umfangreichen Frameworks, die solche Dinge schon völlig generisch lösen ... Serializer auswählen, vielleicht bisschen konfigurieren, Datenklasse "reinfüttern" und gut.

Ich bin ganz frisch mit C# dabei, Datenaustausch, einmal in die Vollen alles neu: SOAP, WCF-Webservice auf IIS gehostet, Klassen aus einer .wsdl-Datei erzeugt...
"Nur" diese Black Box zu konfigurieren ist das frustrierenste, was mir bisher begegnet ist. Reflection, Attribute und "nur konfigurieren" entziehen sich der Kontrolle durch den Compiler und sind ein sprudelnder Quell erstaunlichster Bugs. Da entfaltet sich schnell eine Komplexität, die der Kernaufgabe einfach nicht mehr angemessen ist.

Von C++ hab ich noch weniger Ahnung als von C#, und was ein heute üblicher Weg wäre weiß ich auch nicht.
Ich würde der Klasse eine Methode "Serialize" geben, die entweder einen String zurück gibt oder einen Stream zum Reinschreiben bekommt.
Und andersrum würde ich einen Methode Deserialize mit gleichen Parametern hinzufügen, oder einen passenden Konstruktor.

Zirias/Excess · 16. Februar 2018

Zitat von Hoogo

Ich bin ganz frisch mit C# dabei, Datenaustausch, einmal in die Vollen alles neu: SOAP, WCF-Webservice auf IIS gehostet, Klassen aus einer .wsdl-Datei erzeugt...
"Nur" diese Black Box zu konfigurieren ist das frustrierenste, was mir bisher begegnet ist. Reflection, Attribute und "nur konfigurieren" entziehen sich der Kontrolle durch den Compiler und sind ein sprudelnder Quell erstaunlichster Bugs. Da entfaltet sich schnell eine Komplexität, die der Kernaufgabe einfach nicht mehr angemessen ist.

Ui -- also da muss ich einfach mal einen kleinen OT Schwenk machen. .NET ist riesig und durchaus auch schon wieder "alt" -- da wurden nicht immer nur die besten Dinge gemacht. WCF ist heutzutage für Neuentwicklungen eigentlich tot, und zwar weil SOAP tot ist, solche Komplexitätsmonster will keiner mehr. IIS ist auch so ein spezielles Monster, ich würde eher abraten -- self-hosted ist schlanker und wartbarer. Attribute werden in der .NET Welt teilweise noch fleißig verwendet, ich persönlich bin kein Freund davon, weil man sich Abhängigkeiten einhandelt. Schon zu WCF Zeiten habe ich nie die generierten "service references" verwendet, sondern einen schlichten WCF-Proxy mit den originalen Interface-Klassen, schön ausgelagert in eine separate DLL. Wenn ich heute als Architekt in einer ".NET Bude" viel generierten Code oder unnötige Verwendung von Attributen sehe krieg ich n dicken Hals Kommt aber selten vor, wir machen nur noch REST, die Service-Seite mit WebAPI, als Client tut's der HttpClient. Serialisieren/Deserialisieren übernimmt hier übrigens Json.NET

Also kurz gesagt, du liegst mit deinem ersten Feeling IMHO ganz richtig, man kann das alles aber auch besser machen. Natürlich leider nicht, wenn man irgendein bestehendes WCF-Monster warten/weiterentwickeln muss :o

Zitat von Hoogo

Ich würde der Klasse eine Methode "Serialize" geben, die entweder einen String zurück gibt oder einen Stream zum Reinschreiben bekommt.
Und andersrum würde ich einen Methode Deserialize mit gleichen Parametern hinzufügen, oder einen passenden Konstruktor.

Kann man so machen, wurde selbst in .NET früher so gemacht -- ist auch nicht direkt falsch, aber nicht optimal: Klassen sollten ja immer eine minimale Fachlichkeit kapseln, und Serialisieren/Deserialisieren dürfte so gut wie nie zur fachlichen Funktionalität einer Klasse gehören. Umgekehrt ist es aber in der Regel grundsätzlich zum Persistieren oder Kommunizieren notwendig, also ein klassischer "cross cutting concern". Wenn man das nun in jeder Klasse implementiert ist das streng genommen eine Verletzung des SRP (single responsibility principle). In einer Umgebung wie .NET, in der zur Laufzeit alle dafür nötigen Typinformationen vorhanden sind, ist es daher besser, den Serialisierer komplett isoliert zu bauen; er bekommt lediglich eine Klasse mit public properties (oder eben getter und setter) gefüttert und kann damit "von außen" arbeiten. Typischerweise kann man in so einem Serialisierer eigene Serialisierungsklassen registrieren, falls man das Standardverhalten für bestimmte Klassen verändern will.

Vernunftmensch · 20. Februar 2018

Das war Fleißschreibarbeit...

Code

class metadatablock {
public:
metadatablock() {changed=0; videoastext="";} //Initialisierung
std::string helptext;
std::string videoastext;
std::string whatkind;
int whatkindindex;
std::string longname;
std::string shortname;
std::string copyright;
int bool_diff;
int changed;
std::string dateiverweis;
inline std::ostream& write_stdstring(std::ostream &out, std::string s) const {
int siz = s.length();
out << siz <<",";
out << s;
return out;
}
inline std::istream& read_stdstring (std::istream &in, std::string *s)
{
std::string name;
unsigned int len;
char comma;
in >> len;
in >> comma;
if (len>0)
{
std::vector<char> tmp(len);
in.read(tmp.data() , len);
name.assign(tmp.data(), len);
};
*s=name;
return in;
}
} ;
class projectmetablock {
public:
projectmetablock() {changed=0;}
std::string projectname;
std::string projectstartfile;
std::string projectpath;
std::list<metadatablock*> list;
int changed;
inline std::ostream& write_stdstring(std::ostream &out, std::string s) const {
int siz = s.length();
out << siz <<",";
out << s;
return out;
}
inline std::istream& read_stdstring (std::istream &in, std::string *s)
{
std::string name;
unsigned int len;
char comma;
in >> len;
in >> comma;
if (len>0)
{
std::vector<char> tmp(len);
in.read(tmp.data() , len);
name.assign(tmp.data(), len);
};
*s=name;
return in;
}
};
inline std::ostream & operator << ( std::ostream & os, const projectmetablock & rec ) {
rec.write_stdstring (os, rec.projectname);
rec.write_stdstring (os, rec.projectpath);
rec.write_stdstring (os, rec.projectstartfile);
os << (rec.list.size());
os << ",";
std::list<metadatablock*>::const_iterator it;
for (it = rec.list.begin(); it != rec.list.end(); ++it) {
os << *it;
}
return os;
}
inline std::ostream & operator << ( std::ostream & os, const metadatablock & rec ) {
rec.write_stdstring (os, rec.helptext);
rec.write_stdstring (os, rec.videoastext);
rec.write_stdstring (os, rec.whatkind);
os << rec.whatkindindex;
os << ",";
rec.write_stdstring (os, rec.longname);
rec.write_stdstring (os, rec.shortname);
rec.write_stdstring (os, rec.copyright);
os << rec.bool_diff;
os << ",";
rec.write_stdstring (os, rec.dateiverweis);
return os;
}
inline std::istream & operator >> ( std::istream & is, metadatablock & rec ) {
char comma;
rec.read_stdstring (is, &rec.helptext);
rec.read_stdstring (is, &rec.videoastext);
rec.read_stdstring (is, &rec.whatkind);
is >> rec.whatkindindex;
is >> comma;
rec.read_stdstring (is, &rec.longname);
rec.read_stdstring (is, &rec.shortname);
rec.read_stdstring (is, &rec.copyright);
is >> rec.bool_diff;
is >> comma;
rec.read_stdstring (is, &rec.dateiverweis);
return is;
}
inline std::istream & operator >> ( std::istream & is, projectmetablock & rec ) {
rec.read_stdstring (is, &rec.projectname);
rec.read_stdstring (is, &rec.projectpath);
rec.read_stdstring (is, &rec.projectstartfile);
char comma;
int len;
is >> len;
is >> comma;
rec.list.clear();
if (len>0)
for (int i=0; i<len; i++)
{
metadatablock* mdb=new metadatablock();
is >> (*mdb);
rec.list.push_back(mdb);
}
return is;
}

Alles anzeigen

Zirias/Excess · 21. Februar 2018

Bisschen viel inline Code, wie wär's mit nem Implementierungsfile?

Vernunftmensch · 21. Februar 2018

Da fehlte noch ein zeiter Stern beim Iterator. Keiner gemerkt?

Zirias/Excess · 22. Februar 2018

Zitat von Vernunftmensch

Keiner gemerkt?

Klar nicht, weil keiner so weit gelesen hat -- wozu auch :o