aus XSD/XML C++ Entität erzeugen
-
Das ist ja das Problem. Ich kenne keine passende Komponente dafür.
Ich kann nur auf: Borland C++ Builder 2006 Prof. zurückgreifen.Xerces kenne ich aus dem Java Umfeld, jedoch schien die Nutzung im C++ Builder recht schwierig (keine passenden binaries / sourcen für den BCB2006).
-
smp schrieb:
ist es möglich, aus einer XSD bzw. XML Datei eine C++ Entität/Objekt zu erstellen?
Ja, das macht der XML-Importer. Datei|Neu|C++Builder-Dateien|XML-Datenbindung, dann die XML- bzw. XSD-Datei auswählen.
-
Hey super thx.
Gibt es irgendeine Art von Hilfe/Tutorial, wie ich dann solch eine Entität benutzen kann? (die Borland Hilfe taugt da nichts).Wenn ich bspw. versuche ein Objekt zu erzeugen:
TXMLbookstoreType *bookStore = new TXMLbookstoreType();
-> [C++ Fehler] Unit16.cpp(44): E2125 Compiler konnte Standardkonstruktor nicht für die Klasse 'TXMLbookstoreType' generieren
Leider finde ich absolut 0 Infos zu den Stichworten: Borland C++ Builder XML Datenbindung / data binding ...
-
Hallo
Die Fehlermeldung ist klar : Deine Klasse hat eben keinen Konstruktor ohne Parameter. Das passiert zum Beispiel wenn deine Klasse TXMLbookstoreType von einer Klasse abgeleitet ist, die keinen parameterlosen Konstruktor hat, und selber auch gar keinen eigenen Konstruktor definiert
Den Fehler kannst du auf drei Wegen umgehen :
- Du definierst für deine Klasse einen sinnvollen Konstruktor der keine Parameter braucht
- Du bearbeitest manuell deinen generierten Code nach
- Du bringst den XML-Import dazu, das du auch sinnvolle Konstruktor-Parameter vorgeben kannstbis bald
akari
-
Das mein generierter Code eben diesen Standard-Konstruktor nicht definiert ist mir ja klar, aber ich möchte eigtl. ungern im generierten Code editieren (einen Konstruktor erstellen), da es sich um ein paar mehr Daten handelt.
Aber wenn BCB schon dieses Feature "XML data binding" anbietet, müsste doch eine "funktionsfähige" Klasse erstellt werden, jene ich instanzieren kann (ohne selber drin rumfuschen zu müssen).
-
Hallo
Offenbar ist der XML-Import nicht flexibel genug um passende Konstruktoren zu basteln. Verdenken kann man es ihm nicht, denn auch der Compiler streikt da. Scheint für den Computer doch eine zu schwere Entscheidung sein, ob, wo und welcher Konstruktor eingesetzt werden muß, abgesehen davon was der C++ Standard vorgibt. Vor allem wenn dann die folgenden Konsequenzen wie Initialisierungsliste, Copy-Konstruktor oder Destruktor auch noch beachten werden müßen, damit es wirklich immer automatisch alle Sonderfälle bearbeiten kann. Da haben die Compiler/Import-Designer eben entschieden auf jede Automatik zu verzichten.
bis bald
akari
-
akari schrieb:
Scheint für den Computer doch eine zu schwere Entscheidung sein, ob, wo und welcher Konstruktor eingesetzt werden muß, abgesehen davon was der C++ Standard vorgibt. Vor allem wenn dann die folgenden Konsequenzen wie Initialisierungsliste, Copy-Konstruktor oder Destruktor auch noch beachten werden müßen, damit es wirklich immer automatisch alle Sonderfälle bearbeiten kann. Da haben die Compiler/Import-Designer eben entschieden auf jede Automatik zu verzichten.
Das ist leider durchweg unzutreffend
smp schrieb:
Gibt es irgendeine Art von Hilfe/Tutorial, wie ich dann solch eine Entität benutzen kann? (die Borland Hilfe taugt da nichts).
Du könntest einfach mal einen Blick in die Headerdatei werfen. Ich habe den Importer beispielsweise gerade mal über die (mitgelieferte) codetemplates.xsd laufen lassen, und da enthält die Headerdatei unter anderem folgendes:
// Globale Funktionen _di_IXMLcodetemplateType __fastcall Getcodetemplate(_di_IXMLDocument Doc); _di_IXMLcodetemplateType __fastcall Getcodetemplate(TXMLDocument *Doc); _di_IXMLcodetemplateType __fastcall Loadcodetemplate(const WideString FileName); _di_IXMLcodetemplateType __fastcall Newcodetemplate();
smp schrieb:
Leider finde ich absolut 0 Infos zu den Stichworten: Borland C++ Builder XML Datenbindung / data binding ...
"delphi xml data binding" ist etwas ergiebiger.
-
Hallo
audacia schrieb:
akari schrieb:
Scheint für den Computer doch eine zu schwere Entscheidung sein, ob, wo und welcher Konstruktor eingesetzt werden muß, abgesehen davon was der C++ Standard vorgibt. Vor allem wenn dann die folgenden Konsequenzen wie Initialisierungsliste, Copy-Konstruktor oder Destruktor auch noch beachten werden müßen, damit es wirklich immer automatisch alle Sonderfälle bearbeiten kann. Da haben die Compiler/Import-Designer eben entschieden auf jede Automatik zu verzichten.
Das ist leider durchweg unzutreffend
Der Compiler kann nicht einen Standard-Konstruktor automatisch generieren, wenn die Basisklasse keinen Standard-Konstruktor hat. Deshalb ja auch die Fehlermeldung, die smp gepostet hat. Was ist da nun unzutreffend?
bis bald
akari
-
akari schrieb:
Was ist da nun unzutreffend?
Da nichts. Ich habe ja auch eine andere Passage zitiert.
Vielleicht habe ich die zitierten Sätze mißverstanden, aber mir schien, als wolltest du sagen, der Importer sei nicht in der Lage, vernünftig Konstruktoren zu generieren, weil er die Konsequenzen nicht absehen könne, und verzichte deshalb "auf jede Automatik", so daß man alles von Hand nachbessern müsse.
-
Hallo
Gut, wenn ich den Importer unterschätzt habe, dann wirst du wohl recht haben. Dachte der würde auch nur die üblichen C++ Standards behandeln.
bis bald
akari