From boris at codesynthesis.com Mon Nov 2 05:30:14 2009 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon Nov 2 05:27:14 2009 Subject: [xsde-users] Re: Disable automatic deletion of char arrays. In-Reply-To: <20091030133721.92ac464a@streamteam.de> References: <20091030133721.92ac464a@streamteam.de> Message-ID: Hi Thomas, Thomas Frenzel (TomSun) writes: > Is there a possibility to turn of the automatic deletion of char arrays > and/or other aggregeted pointer based values when the generated class > will be deleted? I mean, mostly this is exactly what i want to do, but > sometimes i just want to pass a const char array to one of the generated > class instances without copying it before. In these cases i have to copy > data even if its not necessary. The problem with adding support for something like this is that it will require an extra flag to indicate that the object should not be freed. For example: class person { ... private: const char* first_; bool delete_first_; const char* last_; bool delete_last_; }; Since this feature will most likely be used only for a few object, adding such a flag for every member will be too wasteful. However, there is a way to achieve this that requires a bit of extra work but does not incur any overhead: You can instruct the XSD/e compiler to generate detach functions by specifying the --generate-detach option. The resulting object model will have a detach function for every variable-length object, for example: class person { void first (char*); char* first_detach (); void last (char*); char* last_detach (); ... }; The idea is to pass static strings to modifier functions that expect the dynamically allocated strings but then detach them before the object model is deleted and the destructors try to free these static strings. This works best if you know exactly which object will be static, for example: void free_object_model (person* p) { p.detach_first (); p.detach_last (); delete p; } person* p = new person; p->first ((char*) "John"); p->last ((char*) "Doe"); free_object_model (p); It doesn't look pretty but if your goal is to avoid extra copying (as opposed to just convenience), then it is possible. Boris From tftomsun at streamteam.de Mon Nov 2 05:34:30 2009 From: tftomsun at streamteam.de (Thomas Frenzel (TomSun)) Date: Mon Nov 2 05:34:41 2009 Subject: [xsde-users] Re: Disable automatic deletion of char arrays. In-Reply-To: boris.20091102121442@codesynthesis.com Message-ID: <20091102103430.b49e890a@streamteam.de> Hi Boris, ah, i didnt know this detach option. I think this is already sufficient. Regards, Tom _____ From: Boris Kolpackov [mailto:boris@codesynthesis.com] To: Thomas Frenzel (TomSun) [mailto:tftomsun@streamteam.de] Cc: xsde-users@codesynthesis.com Sent: Mon, 02 Nov 2009 11:30:14 +0100 Subject: Re: Disable automatic deletion of char arrays. Hi Thomas, Thomas Frenzel (TomSun) writes: > Is there a possibility to turn of the automatic deletion of char arrays > and/or other aggregeted pointer based values when the generated class > will be deleted? I mean, mostly this is exactly what i want to do, but > sometimes i just want to pass a const char array to one of the generated > class instances without copying it before. In these cases i have to copy > data even if its not necessary. The problem with adding support for something like this is that it will require an extra flag to indicate that the object should not be freed. For example: class person { ... private: const char* first_; bool delete_first_; const char* last_; bool delete_last_; }; Since this feature will most likely be used only for a few object, adding such a flag for every member will be too wasteful. However, there is a way to achieve this that requires a bit of extra work but does not incur any overhead: You can instruct the XSD/e compiler to generate detach functions by specifying the --generate-detach option. The resulting object model will have a detach function for every variable-length object, for example: class person { void first (char*); char* first_detach (); void last (char*); char* last_detach (); ... }; The idea is to pass static strings to modifier functions that expect the dynamically allocated strings but then detach them before the object model is deleted and the destructors try to free these static strings. This works best if you know exactly which object will be static, for example: void free_object_model (person* p) { p.detach_first (); p.detach_last (); delete p; } person* p = new person; p->first ((char*) "John"); p->last ((char*) "Doe"); free_object_model (p); It doesn't look pretty but if your goal is to avoid extra copying (as opposed to just convenience), then it is possible. Boris From amnw14545 at googlemail.com Mon Nov 16 08:35:08 2009 From: amnw14545 at googlemail.com (Tony McConnell) Date: Mon Nov 16 11:38:54 2009 Subject: [xsde-users] Unexpected Element Encountered Message-ID: <2e01cfe50911160535w16ba37edg15c67f214e586a01@mail.gmail.com> Hello, I'm having a problem trying to get a test parser and test implementation working with xsde. I'm using xsde 3.1.0, and performing the following steps: xsde cxx-parser --force-overwrite --generate-polymorphic --disable-warning all --generate-print-impl --generate-test-driver --namespace-map http://datex2.eu/schema/1_0/1_0=datex2 DATEXIISchema_1_0_1_0.xsd g++ -O0 -g -c -I /opt/libxsde DATEXIISchema_1_0_1_0-pskel.cxx g++ -O0 -g -c DATEXIISchema_1_0_1_0-pimpl.cxx -I /opt/libxsde g++ -O0 -o pdriver -g -I /opt/libxsde -L /opt/libxsde/xsde DATEXIISchema_1_0_1_0-pdriver.cxx DATEXIISchema_1_0_1_0-pimpl.o DATEXIISchema_1_0_1_0-pskel.o -lxsde The DATEX2 schema is available at: http://www.datex2.eu/sites/www.datex2.eu/files/sites/test.datex2.eu/files/DATEXIISchema_1_0_1_0.zip An example XML file is available at: http://www.datex2.eu/sites/www.datex2.eu/files/sites/test.datex2.eu/files/DATEX_II_Example_messages.zip I'm using the MeasuredDataWeatherData.xml from the example messages. I'm expecting the example implementation to read the entire file and print out the contents, but it aborts with the following message: MeasuredDataWeatherData.xml:16:33: unexpected element encountered. Could somebody please help? The XML file checks OK against the schema using xmllint... Thanks Tony From boris at codesynthesis.com Mon Nov 16 12:27:12 2009 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon Nov 16 12:27:27 2009 Subject: [xsde-users] Unexpected Element Encountered In-Reply-To: <2e01cfe50911160535w16ba37edg15c67f214e586a01@mail.gmail.com> References: <2e01cfe50911160535w16ba37edg15c67f214e586a01@mail.gmail.com> Message-ID: Hi Tony, Tony McConnell writes: > I'm having a problem trying to get a test parser and test > implementation working with xsde. > > I'm using xsde 3.1.0, and performing the following steps: > > xsde cxx-parser --force-overwrite --generate-polymorphic > --disable-warning all --generate-print-impl --generate-test-driver > --namespace-map http://datex2.eu/schema/1_0/1_0=datex2 > DATEXIISchema_1_0_1_0.xsd > > [...] > > I'm using the MeasuredDataWeatherData.xml from the example messages. > > I'm expecting the example implementation to read the entire file and > print out the contents, but it aborts with the following message: > MeasuredDataWeatherData.xml:16:33: unexpected element encountered. This due to the use of polymorphism in this schema. While the generated parsers are polymorphism-aware, the generated sample driver is not. In other words, it does not create the parser maps with all the possible derivations and does not pass true to document_pimpl's c-tor to indicate polymorphic parsing. As a result, the content for the payloadPublication is parsed as the base PayloadPublication type instead of the derived MeasuredDataPublication type which is specified with the xsi:type attribute. You can fix the generated sample driver by creating the necessary maps, for example: datex2::MeasuredDataPublication mdp_p; mdp_p.parsers (....); xml_schema::parser_map_impl payloadPublication_map (7); // 7 hash buckets map.insert (mdp_p); D2LogicalModel_p.payloadPublication_parser (payloadPublication_map); And passing true as the last argument to document_pimpl's c-tor. You may also want to consider using the C++/Hybrid mapping. It is based on C++/Parser and builds the in-memory representation of the XML data. C++/Hybrid will handle polymorphism automatically if you let it know which types are the bases of polymorphic hierarchies (that is, use something like --polymorphic-type PayloadPublication). Also, you could use the parser instantiation and construction code generated by C++/Hybrid in your C++/Parser-based application if you don't feel like doing it manually (for this schema it is quite a bit of code). I tried this and the resulting driver implementation parses the sample document without any problems. You can download it here: http://www.codesynthesis.com/~boris/tmp/DATEXIISchema_1_0_1_0-pdriver.cxx Boris From amnw14545 at googlemail.com Tue Nov 17 06:40:32 2009 From: amnw14545 at googlemail.com (Tony McConnell) Date: Tue Nov 17 06:57:23 2009 Subject: [xsde-users] Unexpected Element Encountered In-Reply-To: References: <2e01cfe50911160535w16ba37edg15c67f214e586a01@mail.gmail.com> Message-ID: <2e01cfe50911170340o2a909259v5ad86d5f447a616c@mail.gmail.com> On Mon, Nov 16, 2009 at 5:27 PM, Boris Kolpackov wrote: > Hi Tony, > *snip* > > http://www.codesynthesis.com/~boris/tmp/DATEXIISchema_1_0_1_0-pdriver.cxx > > Boris Thanks for your help Boris, that works fine! Tony