From r.britten at auckland.ac.nz Mon Dec 1 18:39:28 2014 From: r.britten at auckland.ac.nz (Randall Britten) Date: Tue Dec 2 03:30:15 2014 Subject: [xsd-users] Request for Mac OS X 64-bit binaries Message-ID: Hi I?m trying out XSD, and I?ve managed to generate code and compile code for the schema document of interest (http://www.fieldml.org/resources/xml/0.5/FieldML_0.5.xsd). I used homebrew to install xerces-c, and so I think its libraries are 64-bit, so I haven?t managed to link yet. Would it be possible for you to please make 64-bit Mac OS X binaries available? Also, I had to make a minor modification to the above document so that it only referred to local schemas, I kept on getting ?FieldML_0.5.xsd: error: 'http://www.cellml.org/tools/cellml_1_1_schema/common/xlink-href.xsd': unable to open in read mode?. Note: The FieldML XSD is just being used by me as to evaluate whether or not to use it for a different project. Both projects are open source. Regards, Randall From boris at codesynthesis.com Tue Dec 2 03:35:13 2014 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue Dec 2 03:43:31 2014 Subject: [xsd-users] Request for Mac OS X 64-bit binaries In-Reply-To: References: Message-ID: Hi Randall, Randall Britten writes: > I?m trying out XSD, and I?ve managed to generate code and compile > code for the schema document of interest (http://www.fieldml.org/ > resources/xml/0.5/FieldML_0.5.xsd). I used homebrew to install > xerces-c, and so I think its libraries are 64-bit, so I haven?t > managed to link yet. Would it be possible for you to please > make 64-bit Mac OS X binaries available? I don't see how a 64-bit binary of the XSD compiler will help you here. If you are able to run the existing MacOS XSD binary (and you are), then you don't need a 64-bit one. The 64-bit one would generate identical C++ source code. If you are having problems linking your application to Xerces-C++, then this could be due to several reasons: 1. Different width (32/64). You can try to pass -m64 or -m32 when building your application and see if that makes a difference. 2. Different C++ compilers and/or C++ runtimes used. This is actually a big mess at the moment in MacOS since there are two C++ runtimes (Clang's libc++ and GCC's libstdc++). So what very well could have happened is that Brew used GCC to build Xerces-C++ and linked it to libstdc++ while you are using Clang to build your application and linking to libc++. As you can probably guess, nothing good is going to come out of it. As a result, what I would strongly recommend is that you scrap Brew (i.e., uninstall Xerces-C++) and build everything yourself using exactly the same compiler for everything (I would suggest the default clang from the command line tools). Building Xerces-C++ should be a simple matter of running: ./configure CC=clang CXX=clang++ make sudo make install > Also, I had to make a minor modification to the above document so > that it only referred to local schemas, I kept on getting > ?FieldML_0.5.xsd: error: 'http://www.cellml.org/tools/cellml_1_1_ > schema/common/xlink-href.xsd': unable to open in read mode?. See the --location-map option in the XSD command line manual. Boris From r.britten at auckland.ac.nz Tue Dec 2 22:45:38 2014 From: r.britten at auckland.ac.nz (Randall Britten) Date: Wed Dec 3 07:15:41 2014 Subject: [xsd-users] Request for Mac OS X 64-bit binaries In-Reply-To: References: Message-ID: Hi Thanks for your help, I?ve managed to get my example compiled, linked and running on Mac OS X :-) I managed to build xerces-c++ by just doing: ./configure make sudo make install When I added the options you suggested to ./configure, it complained that the compiler could not create executable files. I?m encouraged by the results, and will evaluate it further, and hopefully make it part of my project. I see that cmake 3.1 ships with a ?FindXerces? module, which might make things easier in future, but I haven?t tried it yet. Regards, Randall On 2/12/14 9:35 pm, "Boris Kolpackov" wrote: >Hi Randall, > >Randall Britten writes: > >> I?m trying out XSD, and I?ve managed to generate code and compile >> code for the schema document of interest (http://www.fieldml.org/ >> resources/xml/0.5/FieldML_0.5.xsd). I used homebrew to install >> xerces-c, and so I think its libraries are 64-bit, so I haven?t >> managed to link yet. Would it be possible for you to please >> make 64-bit Mac OS X binaries available? > >I don't see how a 64-bit binary of the XSD compiler will help you >here. If you are able to run the existing MacOS XSD binary (and you >are), then you don't need a 64-bit one. The 64-bit one would generate >identical C++ source code. > >If you are having problems linking your application to Xerces-C++, >then this could be due to several reasons: > >1. Different width (32/64). You can try to pass -m64 or -m32 when > building your application and see if that makes a difference. > >2. Different C++ compilers and/or C++ runtimes used. This is actually > a big mess at the moment in MacOS since there are two C++ runtimes > (Clang's libc++ and GCC's libstdc++). So what very well could have > happened is that Brew used GCC to build Xerces-C++ and linked it > to libstdc++ while you are using Clang to build your application > and linking to libc++. As you can probably guess, nothing good is > going to come out of it. > >As a result, what I would strongly recommend is that you scrap Brew >(i.e., uninstall Xerces-C++) and build everything yourself using >exactly the same compiler for everything (I would suggest the default >clang from the command line tools). Building Xerces-C++ should be a >simple matter of running: > >./configure CC=clang CXX=clang++ >make >sudo make install > > >> Also, I had to make a minor modification to the above document so >> that it only referred to local schemas, I kept on getting >> ?FieldML_0.5.xsd: error: 'http://www.cellml.org/tools/cellml_1_1_ >> schema/common/xlink-href.xsd': unable to open in read mode?. > >See the --location-map option in the XSD command line manual. > >Boris From mlang at delysid.org Mon Dec 8 09:12:16 2014 From: mlang at delysid.org (Mario Lang) Date: Wed Dec 10 07:38:06 2014 Subject: [xsd-users] xsdcxx-musicxml Message-ID: <87zjaynscf.fsf@fx.delysid.org> Hi. content_order was really what was (mostly) missing for xsdcxx to be useful to generate a complete MusicXML binding for C++. Parsing from, and serializing to a DOM was the other thing that finally helped me to solve the root element issue[1]. Thanks for these hints! I have now pushed a project that uses xsdcxx to generate MusicXML bindings to GitHub: https://github.com/mlang/xsdcxx-musicxml I have two outstanding issues to solve which I haven't quite figured out yet: * How do I add a DOCTYPE to a serialized document? Valid MusicXML documents sort of require a DTD to be stated. Is there some way to tell the xsdcxx serializer (a bit like the properties class) that I want a !DOCTYPE to be generated as well? Or do I serialize to a DOM document and somehow add the DOCTYPE later (oh how I hate the Xerces-C API! fgThisBarelyFitsOnASingleLineEvenThoughItIsJustOneConstant!). * More importantly, via schema validation, I have found another element in the MusicXML grammar that would require content_order for correct serialization. However, contrary to the two elements which already use content_order, this one is not composed of interleaved containers. Actually, every element is an optional. It is just that xsdcxx somehow gets the serialiszation order wrong on output. Now, to fix this, I have to enable content_order for this element, which vastly complicates client code for absolutely no reason. I basically have to find a way to re-implement accessors such that content_order is handled. 1. Do you think we might be able to work on getting xsdcxx to DTRT for this particular element type? (The relevant XSD snippet is below.) 2. If no, I will have to manually fix this up. Either by writing all the content_order handling code required for this class (quite tedious), or, by manually implementing the part of the serialization code that is broken. Second option is easier to do. Is there actually a mechanism in xsdcxx to allow for manual override of particular implementations of the .cxx file? I.e., lets say I think I am smarter then the XSD compiler, can I selectively provide my own implementations? I know I can edit the generated source, but that leads to all sorts of problems, since it is, generated :-). Here is the evil complexType. Note that it begins with a choice of sequences, which is what I think gives xsdcxx a headache. While there is at least one subelement which can be a sequence as well (dot), all others are just optionals. It should be possible to get the serialization order right, since there is no interleaving of containers possible at all. I.e., I can have "" but not "" or somesuch. content_order *shouldn't* be necessary for correct serialization. The only other special thing about this complexType is that some of its elements are mutually exclusive. As the documentation states, "Thus grace notes do not have a duration element. Cue notes have a duration element, as do forward elements, but no tie elements." i.e., if a note element contains a cue element, it is not allowed to contain a tie element. And if it contains a grace element, it is not allowed to contain a duration element. But these constraints, implied by the complexType, are more a thing of valid internal state. If the input document is valid, and/or the object model has been created in a valid state in regards to these constraints, serialization code should just work, and generate a valid document. Am I missing something (which is very likely) or have I hit a corner case with xsdcxx here? Can we get this fixed? To see how the manual fix looks, have a look at 743b7056adc0d25cf3a28980e30f58300239d410 in the xsdcxx-musicxml master branch. Notes are the most common type of MusicXML data. The MusicXML format keeps the MuseData distinction between elements used for sound information and elements used for notation information (e.g., tie is used for sound, tied for notation). Thus grace notes do not have a duration element. Cue notes have a duration element, as do forward elements, but no tie elements. Having these two types of information available can make interchange considerably easier, as some programs handle one type of information much more readily than the other. The dynamics and end-dynamics attributes correspond to MIDI 1.0's Note On and Note Off velocities, respectively. They are expressed in terms of percentages of the default forte value (90 for MIDI 1.0). The attack and release attributes are used to alter the starting and stopping time of the note from when it would otherwise occur based on the flow of durations - information that is specific to a performance. They are expressed in terms of divisions, either positive or negative. A note that starts a tie should not have a release attribute, and a note that stops a tie should not have an attack attribute. If a note is played only particular times through a repeat, the time-only attribute shows which times to play the note. The pizzicato attribute is used when just this note is sounded pizzicato, vs. the pizzicato element which changes overall playback between pizzicato and arco. The cue element indicates the presence of a cue note. One dot element is used for each dot of prolongation. The placement element is used to specify whether the dot should appear above or below the staff line. It is ignored for notes that appear on a staff space. [1] MusicXML has two possible root elements, "score-partwise" and "score-timewise". Without going too much into detail, a partwise document has parts at the top level, and measures inside, with all the musical content inside of these measure elements. A timewise document has measure elements at the top level, part elements inside, and all the music inside of part elements. Aside from this difference, the actual content elements are completely identical. partwise documents can automatically be converted to timewise documents, and vice versa. There are XSL Transformations (quite simple) for doing that. So my final approach to handling polymorphic root elements with MusicXML is quite different from all the examples I have seen: Since the transformation can be automated, I plan to just do that on the DOM directly. All I have to do is add yet another parsing helper function which specifies *which* root element the user wants. If the DOM already has that root element, we just pass it on to the xsdcxx parsing code, and if it is the wrong top level element, we apply the DOM transformation and then pass it on to xsdcxx. This way, I do not have to use *any* of the polymorphism features of xsdcxx to handle the fact that there are two possible root elements. -- CYa, ????? From boris at codesynthesis.com Wed Dec 10 08:03:50 2014 From: boris at codesynthesis.com (Boris Kolpackov) Date: Wed Dec 10 08:12:23 2014 Subject: [xsd-users] xsdcxx-musicxml In-Reply-To: <87zjaynscf.fsf@fx.delysid.org> References: <87zjaynscf.fsf@fx.delysid.org> Message-ID: Hi Mario, Mario Lang writes: > * How do I add a DOCTYPE to a serialized document? Valid MusicXML documents > sort of require a DTD to be stated. Is there some way to tell the > xsdcxx serializer (a bit like the properties class) that I want a !DOCTYPE to be > generated as well? Or do I serialize to a DOM document and somehow > add the DOCTYPE later The way to do this is to create the DOM document with DOCTYPE yourself, then serialize the object model into it, and, finally, serialize the DOM document to XML. The Wiki has some sample code in the FAQ for how to to this. For the DOCTYPE part, look into the DOMImplementation class: https://xerces.apache.org/xerces-c/apiDocs-3/classDOMImplementation.html > While there is at least one subelement which can be a sequence as well > (dot), all others are just optionals. I took a look at the schema and the generated code. The first element in the generated code that I see that is a sequence is 'tie'. Looking at the schema: The next is 'dot': Then 'beam': Then 'notation': I stopped here. > Now, to fix this, I have to > enable content_order for this element, which vastly complicates > client code for absolutely no reason. I basically have to find a way > to re-implement accessors such that content_order is handled. > > 1. Do you think we might be able to work on getting xsdcxx to DTRT > for this particular element type? (The relevant XSD snippet is > below.) I am not sure what DTRT is in this case. To me it seems XSD correctly detects optional/sequence cardinalities (for the flattaned model that it implements). > > 2. If no, I will have to manually fix this up. Either by writing all > the content_order handling code required for this class (quite > tedious), or, by manually implementing the part of the > serialization code that is broken. Second option is > easier to do. Is there actually a mechanism in xsdcxx to > allow for manual override of particular implementations of > the .cxx file? See the C++/Tree Mapping Customization Guide: http://wiki.codesynthesis.com/Tree/Customization_guide As well as the examples in the examples/cxx/tree/custom/ directory. Boris From mlang at delysid.org Wed Dec 10 10:47:38 2014 From: mlang at delysid.org (Mario Lang) Date: Wed Dec 10 10:47:43 2014 Subject: [xsd-users] xsdcxx-musicxml In-Reply-To: (Boris Kolpackov's message of "Wed, 10 Dec 2014 15:03:50 +0200") References: <87zjaynscf.fsf@fx.delysid.org> Message-ID: <87a92vh5gl.fsf@fx.delysid.org> Boris Kolpackov writes: > Mario Lang writes: > >> * How do I add a DOCTYPE to a serialized document? Valid MusicXML documents >> sort of require a DTD to be stated. Is there some way to tell the >> xsdcxx serializer (a bit like the properties class) that I want a !DOCTYPE to be >> generated as well? Or do I serialize to a DOM document and somehow >> add the DOCTYPE later > > The way to do this is to create the DOM document with DOCTYPE yourself, > then serialize the object model into it, and, finally, serialize the > DOM document to XML. > > The Wiki has some sample code in the FAQ for how to to this. For the > DOCTYPE part, look into the DOMImplementation class: > > https://xerces.apache.org/xerces-c/apiDocs-3/classDOMImplementation.html Thanks! >> While there is at least one subelement which can be a sequence as well >> (dot), all others are just optionals. > > I took a look at the schema and the generated code. The first element > in the generated code that I see that is a sequence is 'tie'. Looking > at the schema: > > > > The next is 'dot': > > > > Then 'beam': > > > > Then 'notation': > > > > I stopped here. Sorry, I either was not clear enough, or my understanding of XML Schemas is lacking. Let me try to explain again why I *think* xsdcxx could do a better job here: In MusicXML, the two elements that definitely require content_order are and . Both elements reference the same xs:group, which has the following structure: ... IOW, every element of or is a choice, therefore, order is clearly important. However, the element we are currently discussing has the following basic structure: ... Even though some of the elements have maxOccurs="unbounded", the final serialization order is (IMO) unambigious. If we added theoretical santiy checks, the serialization code would probably look something like: if (i->a()) { // serialize a } else if (i->b()) { // serialize b } if (i->c()) { // serialize c } if (!i->b() && i->d()) { // serialize d } if (!i->a() && i->e()) { // serialize e } if (i->fghij...()) { // serialize rest... } >> Now, to fix this, I have to >> enable content_order for this element, which vastly complicates >> client code for absolutely no reason. I basically have to find a way >> to re-implement accessors such that content_order is handled. >> >> 1. Do you think we might be able to work on getting xsdcxx to DTRT >> for this particular element type? (The relevant XSD snippet is >> below.) > > I am not sure what DTRT is in this case. To me it seems XSD correctly > detects optional/sequence cardinalities (for the flattaned model that > it implements). I have a feeling that all that is missing, is to fix the "sorting" order of the flattened structure. Or, maybe, to detect identical elements in a choice of sequences. Because, in the above, is *always* required to be present, and are mutually exclusive, and and are only allowed if one of or is present. Again, to me, it looks like the serialization order is rather unambigious from the grammar given. Whaat xsdcxx seems to do, is to flatten the sequences of the coice one after another. What I am likely looking for is a mechanism to merge elements of a sequence inside of a choice during flattening. Something like this must already happen, since elements inside of a choice of seuquences which are common to (some) sequences of that choice are not serialized twice, as would be expected. What is missing to correctly serialize MusicXML, is to get the order right. >> 2. If no, I will have to manually fix this up. Either by writing all >> the content_order handling code required for this class (quite >> tedious), or, by manually implementing the part of the >> serialization code that is broken. Second option is >> easier to do. Is there actually a mechanism in xsdcxx to >> allow for manual override of particular implementations of >> the .cxx file? > > See the C++/Tree Mapping Customization Guide: > > http://wiki.codesynthesis.com/Tree/Customization_guide > > As well as the examples in the examples/cxx/tree/custom/ directory. Oh, how could I have missed this. Thanks again for guidance. -- CYa, ????? From boris at codesynthesis.com Thu Dec 11 07:18:28 2014 From: boris at codesynthesis.com (Boris Kolpackov) Date: Thu Dec 11 07:27:02 2014 Subject: [xsd-users] xsdcxx-musicxml In-Reply-To: <87a92vh5gl.fsf@fx.delysid.org> References: <87zjaynscf.fsf@fx.delysid.org> <87a92vh5gl.fsf@fx.delysid.org> Message-ID: Hi Mario, Mario Lang writes: > > > > > > > > > > > > > > > > > > > ... > To serialize, e.g., 'c' in the correct order, XSD would need to know which arm of the choice it is. Since XSD "flattens" choices, this is not possible in the current architecture. In this particular case you can kind of infer which arm it is based on which elements are present/absent. But that would be impossible to extend to the general case. > I have a feeling that all that is missing, is to fix the "sorting" order > of the flattened structure. Or, maybe, to detect identical elements in > a choice of sequences. Because, in the above, is *always* > required to be present, and are mutually exclusive, and and > are only allowed if one of or is present. Again, to me, it > looks like the serialization order is rather unambigious from the > grammar given. I would suggest that you customize the serializer operator for this type. Implementing this in XSD will be non-trivial, to put it mildly. Boris From mlang at delysid.org Thu Dec 11 09:55:26 2014 From: mlang at delysid.org (Mario Lang) Date: Thu Dec 11 09:55:30 2014 Subject: [xsd-users] xsdcxx-musicxml In-Reply-To: (Boris Kolpackov's message of "Thu, 11 Dec 2014 14:18:28 +0200") References: <87zjaynscf.fsf@fx.delysid.org> <87a92vh5gl.fsf@fx.delysid.org> Message-ID: <87mw6uw80x.fsf@fx.delysid.org> Boris Kolpackov writes: > Mario Lang writes: > >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> ... >> > > To serialize, e.g., 'c' in the correct order, XSD would need to know > which arm of the choice it is. > Since XSD "flattens" choices, this is not possible in the current > architecture. In this particular case you can kind of infer which arm > it is based on which elements are present/absent. But that would be > impossible to extend to the general case. OK, thnaks, I trust your analysis on this one. Just wanted to make sure we are not accidentally misunderatnding eachotehr. >> I have a feeling that all that is missing, is to fix the "sorting" order >> of the flattened structure. Or, maybe, to detect identical elements in >> a choice of sequences. Because, in the above, is *always* >> required to be present, and are mutually exclusive, and and >> are only allowed if one of or is present. Again, to me, it >> looks like the serialization order is rather unambigious from the >> grammar given. > > I would suggest that you customize the serializer operator for this > type. Implementing this in XSD will be non-trivial, to put it mildly. OK. A customization works as well for me. http://github.com/mlang/xsdcxx-musicxml/ -- CYa, ????? | Debian Developer .''`. | Get my public key via finger mlang/key@db.debian.org : :' : | 1024D/7FC1A0854909BCCDBE6C102DDFFC022A6B113E44 `. `' `- From erik.sjolund at gmail.com Sun Dec 14 03:24:17 2014 From: erik.sjolund at gmail.com (=?UTF-8?Q?Erik_Sj=C3=B6lund?=) Date: Sun Dec 14 03:24:26 2014 Subject: [xsd-users] Feature request: c++11 support for examples/cxx/tree/streaming/parser.hxx Message-ID: I have successfully been using these files examples/cxx/tree/streaming/serializer.cxx examples/cxx/tree/streaming/serializer.hxx examples/cxx/tree/streaming/parser.cxx examples/cxx/tree/streaming/parser.hxx when writing some software project. They can be really useful. For the rest of the project I am defining the XSD_CXX11 macro, so I thought it would be a good idea to adjust the files above to start using std::unique_ptr. It would be nice if the attached patch (or something similar) could be merged into CodeSynthesis XSD. The patch is in public domain, so use it in whatever way you like. cheers, Erik Sj?lund -------------- next part -------------- diff -ur old/xsd-4.0.0-x86_64-linux-gnu/examples/cxx/tree/streaming/parser.cxx new/xsd-4.0.0-x86_64-linux-gnu/examples/cxx/tree/streaming/parser.cxx --- old/xsd-4.0.0-x86_64-linux-gnu/examples/cxx/tree/streaming/parser.cxx 2014-07-04 08:39:29.000000000 +0200 +++ new/xsd-4.0.0-x86_64-linux-gnu/examples/cxx/tree/streaming/parser.cxx 2014-12-14 08:52:58.882259596 +0100 @@ -14,8 +14,6 @@ #include // xercesc::Grammar #include -#include - #include #include @@ -189,9 +187,9 @@ } if (!r) - return document_ptr (0); + return document_ptr (nullptr); - return doc_; + return std::move(doc_); } document_ptr parser_impl:: @@ -207,14 +205,14 @@ { // Copy doc to outer_doc. // - doc_ = outer_doc; + doc_ = std::move(outer_doc); cur_ = static_cast ( doc_->importNode (doc->getDocumentElement (), true)); doc_->getDocumentElement ()->appendChild (cur_); } else { - doc_ = doc; + doc_ = std::move(doc); cur_ = doc_->getDocumentElement (); } @@ -225,7 +223,7 @@ if (depth_ != next_depth_) { peek_ = false; - return doc_; + return std::move(doc_); } } @@ -250,7 +248,7 @@ } if (!r) - return document_ptr (0); + return document_ptr (nullptr); // If we are not at our start depth, keep calling parseNext() until we // get there again. @@ -262,9 +260,9 @@ } if (!r) - return document_ptr (0); + return document_ptr (nullptr); - return doc_; + return std::move(doc_); } // DOM builder. @@ -368,5 +366,5 @@ document_ptr parser:: next (document_ptr doc, document_ptr outer_doc) { - return impl_->next (doc, outer_doc); + return impl_->next (std::move(doc), std::move(outer_doc)); } diff -ur old/xsd-4.0.0-x86_64-linux-gnu/examples/cxx/tree/streaming/parser.hxx new/xsd-4.0.0-x86_64-linux-gnu/examples/cxx/tree/streaming/parser.hxx --- old/xsd-4.0.0-x86_64-linux-gnu/examples/cxx/tree/streaming/parser.hxx 2014-07-04 07:20:37.000000000 +0200 +++ new/xsd-4.0.0-x86_64-linux-gnu/examples/cxx/tree/streaming/parser.hxx 2014-08-09 16:11:45.528305058 +0200 @@ -26,7 +26,7 @@ void start (std::istream& is, const std::string& id, bool validate); - typedef xsd::cxx::xml::dom::auto_ptr document_ptr; + typedef XSD_DOM_AUTO_PTR document_ptr; // The peek function parses just the next element (ignoring any // preceding content assuming it is whitespace) without parsing @@ -61,7 +61,7 @@ operator= (const parser&); private: - std::auto_ptr impl_; + std::unique_ptr impl_; }; #endif // PARSER_HXX diff -ur old/xsd-4.0.0-x86_64-linux-gnu/examples/cxx/tree/streaming/serializer.cxx new/xsd-4.0.0-x86_64-linux-gnu/examples/cxx/tree/streaming/serializer.cxx --- old/xsd-4.0.0-x86_64-linux-gnu/examples/cxx/tree/streaming/serializer.cxx 2014-07-04 11:00:46.000000000 +0200 +++ new/xsd-4.0.0-x86_64-linux-gnu/examples/cxx/tree/streaming/serializer.cxx 2014-08-08 22:30:04.074777408 +0200 @@ -352,10 +352,10 @@ create (const string& ns, const string& qname, const namespace_infomap&); void - serialize (xml::dom::auto_ptr); + serialize (XSD_DOM_AUTO_PTR); void - serialize_open (xml::dom::auto_ptr); + serialize_open (XSD_DOM_AUTO_PTR); void serialize_close (const string&); @@ -369,8 +369,8 @@ // Serializer. // - xml::dom::auto_ptr out_; - xml::dom::auto_ptr serializer_; + XSD_DOM_AUTO_PTR out_; + XSD_DOM_AUTO_PTR serializer_; auto_ptr oft_; @@ -380,7 +380,7 @@ // DOM document that we use to create the elements. // DOMImplementation& dom_impl_; - xml::dom::auto_ptr doc_; + XSD_DOM_AUTO_PTR doc_; vector element_stack_; size_t element_count_; // Number of elements serialized using current doc. @@ -460,7 +460,7 @@ } void serializer_impl:: -serialize (xml::dom::auto_ptr p) +serialize (XSD_DOM_AUTO_PTR p) { DOMElement* e (p.get ()); @@ -486,7 +486,7 @@ } void serializer_impl:: -serialize_open (xml::dom::auto_ptr p) +serialize_open (XSD_DOM_AUTO_PTR p) { DOMElement* e (p.get ()); @@ -534,7 +534,7 @@ // internal heap. While Xerces-C++ DOM tries to re-use memory, // it still accumulates no longer used memory blocks. // - xml::dom::auto_ptr doc (dom_impl_.createDocument ()); + XSD_DOM_AUTO_PTR doc (dom_impl_.createDocument ()); if (!element_stack_.empty ()) { @@ -551,7 +551,7 @@ } } - doc_ = doc; + doc_ = std::move(doc); element_count_ = 0; } @@ -589,15 +589,15 @@ } void serializer:: -serialize (xml::dom::auto_ptr e) +serialize (XSD_DOM_AUTO_PTR e) { - impl_->serialize (e); + impl_->serialize (std::move(e)); } void serializer:: -serialize_open (xml::dom::auto_ptr e) +serialize_open (XSD_DOM_AUTO_PTR e) { - impl_->serialize_open (e); + impl_->serialize_open (std::move(e)); } void serializer:: diff -ur old/xsd-4.0.0-x86_64-linux-gnu/examples/cxx/tree/streaming/serializer.hxx new/xsd-4.0.0-x86_64-linux-gnu/examples/cxx/tree/streaming/serializer.hxx --- old/xsd-4.0.0-x86_64-linux-gnu/examples/cxx/tree/streaming/serializer.hxx 2014-01-23 07:05:55.000000000 +0100 +++ new/xsd-4.0.0-x86_64-linux-gnu/examples/cxx/tree/streaming/serializer.hxx 2014-08-09 13:07:15.860039592 +0200 @@ -102,45 +102,45 @@ const namespace_infomap&); void - serialize (xsd::cxx::xml::dom::auto_ptr); + serialize (XSD_DOM_AUTO_PTR); void - serialize_open (xsd::cxx::xml::dom::auto_ptr); + serialize_open (XSD_DOM_AUTO_PTR); void serialize_close (const std::string& name); private: - std::auto_ptr impl_; + std::unique_ptr impl_; }; template inline void serializer:: next (const std::string& name, const T& x) { - xsd::cxx::xml::dom::auto_ptr e ( + XSD_DOM_AUTO_PTR e ( create (name, namespace_infomap ())); *e << x; - serialize (e); + serialize (std::move(e)); } template inline void serializer:: next (const std::string& name, const namespace_infomap& map, const T& x) { - xsd::cxx::xml::dom::auto_ptr e (create (name, map)); + XSD_DOM_AUTO_PTR e (create (name, map)); *e << x; - serialize (e); + serialize (std::move(e)); } template inline void serializer:: next (const std::string& ns, const std::string& name, const T& x) { - xsd::cxx::xml::dom::auto_ptr e ( + XSD_DOM_AUTO_PTR e ( create (ns, name, namespace_infomap ())); *e << x; - serialize (e); + serialize (std::move(e)); } template @@ -150,38 +150,38 @@ const namespace_infomap& map, const T& x) { - xsd::cxx::xml::dom::auto_ptr e (create (ns, name, map)); + XSD_DOM_AUTO_PTR e (create (ns, name, map)); *e << x; - serialize (e); + serialize (std::move(e)); } template inline void serializer:: next_open (const std::string& name, const T& x) { - xsd::cxx::xml::dom::auto_ptr e ( + XSD_DOM_AUTO_PTR e ( create (name, namespace_infomap ())); *e << x; - serialize_open (e); + serialize_open (std::move(e)); } template inline void serializer:: next_open (const std::string& name, const namespace_infomap& map, const T& x) { - xsd::cxx::xml::dom::auto_ptr e (create (name, map)); + XSD_DOM_AUTO_PTR e (create (name, map)); *e << x; - serialize_open (e); + serialize_open (std::move(e)); } template inline void serializer:: next_open (const std::string& ns, const std::string& name, const T& x) { - xsd::cxx::xml::dom::auto_ptr e ( + XSD_DOM_AUTO_PTR e ( create (ns, name, namespace_infomap ())); *e << x; - serialize_open (e); + serialize_open (std::move(e)); } template @@ -191,9 +191,9 @@ const namespace_infomap& map, const T& x) { - xsd::cxx::xml::dom::auto_ptr e (create (ns, name, map)); + XSD_DOM_AUTO_PTR e (create (ns, name, map)); *e << x; - serialize_open (e); + serialize_open (std::move(e)); } inline void serializer:: From boris at codesynthesis.com Tue Dec 16 07:50:50 2014 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue Dec 16 07:59:21 2014 Subject: [xsd-users] Re: cxx-tree --variant-type= ? In-Reply-To: <87sigkoq16.fsf@fx.delysid.org> References: <87sigkoq16.fsf@fx.delysid.org> Message-ID: Hi Mario, [CC'ed xsd-users]. Mario Lang writes: > For my MusicXML library, I now rewrote my two --ordered-type(s) with > boost::variant as a --custom-type. I find this much more convenient to > use on the client side, especially since container manipulation (insert, > push_back, push_front, etc.) functions do not have to be manually implemented. As > an added benefit, I get a compile-time checked visitor interface. The > transformation was quite mechanical though: > > 1. Remove all direct sequence accessors. > 2. Redefine content_oder_ and its accessors as variant_sequence, a > std::vector>. > 3. Write a serialization_visitor to handle serialization from a > container of variants. Something like this: > > class serialization_visitor : public boost::static_visitor { > ::xercesc::DOMElement &e; > > public: > serialization_visitor(::xercesc::DOMElement &e) : e(e) {} > > void operator()(const ::musicxml::note &x) const { > ::xsd::cxx::xml::dom::create_element("note", e) << x; > } > void operator()(const ::musicxml::backup &x) const { > ::xsd::cxx::xml::dom::create_element("backup", e) << x; > } > void operator()(const ::musicxml::forward &x) const { > ::xsd::cxx::xml::dom::create_element("forward", e) << x; > } > //... > }; > > 4. Rewrite the parsing code to *not* use element_traits::create, > instead, push_back directly to variant_. > > This works WONDERFUL. I really love it. I wonder, have you ever > considered to implement this as an alternative for --ordered-type? > Maybe --variant-type= ? --variant-type=class[/accessor] maybe? > So the user could override the name of the variant() accessor. No, I haven't considered it. To do that would require quite a bit more thinking because while you only needed to handle this particular case, if we were to implement this in XSD, it would have to work with all reasonable use-cases (wildcards, mixed content, polymorphic types are the ones that came to mind; there are most likely others). At the same time it should be very easy to implement a class template (using variadic template arguments, if using C++11) that would allow you to achieve pretty much what you want: --custom-type=foo=ordered_as_variant/foo_base The only minor inconvenience is that you have to specify the possible element types (bar, baz, and fox in this case) explicitly. But I think this is a small price to pay. Boris From boris at codesynthesis.com Tue Dec 16 07:54:05 2014 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue Dec 16 08:02:36 2014 Subject: [xsd-users] Feature request: c++11 support for examples/cxx/tree/streaming/parser.hxx In-Reply-To: References: Message-ID: Hi Erik, Erik Sj?lund writes: > For the rest of the project I am defining the XSD_CXX11 macro, so I > thought it would be a good idea to adjust the files above to start > using std::unique_ptr. > > It would be nice if the attached patch (or something similar) could be > merged into CodeSynthesis XSD. The patch is in public domain, so use > it in whatever way you like. Thanks for the patch. Unfortunately, I can only make this change once we drop support for C++98. While I am very tempted to do this, I think we will still have to wait for some time. Boris From mlang at delysid.org Tue Dec 16 16:15:00 2014 From: mlang at delysid.org (Mario Lang) Date: Tue Dec 16 16:15:05 2014 Subject: [xsd-users] Re: cxx-tree --variant-type= ? In-Reply-To: (Boris Kolpackov's message of "Tue, 16 Dec 2014 14:50:50 +0200") References: <87sigkoq16.fsf@fx.delysid.org> Message-ID: <87fvcfi9ez.fsf@fx.delysid.org> Boris Kolpackov writes: > Mario Lang writes: > >> For my MusicXML library, I now rewrote my two --ordered-type(s) with >> boost::variant as a --custom-type. I find this much more convenient to >> use on the client side, especially since container manipulation (insert, >> push_back, push_front, etc.) functions do not have to be manually implemented. As >> an added benefit, I get a compile-time checked visitor interface. The >> transformation was quite mechanical though: >> >> 1. Remove all direct sequence accessors. >> 2. Redefine content_oder_ and its accessors as variant_sequence, a >> std::vector>. >> 3. Write a serialization_visitor to handle serialization from a >> container of variants. Something like this: >> >> class serialization_visitor : public boost::static_visitor { >> ::xercesc::DOMElement &e; >> >> public: >> serialization_visitor(::xercesc::DOMElement &e) : e(e) {} >> >> void operator()(const ::musicxml::note &x) const { >> ::xsd::cxx::xml::dom::create_element("note", e) << x; >> } >> void operator()(const ::musicxml::backup &x) const { >> ::xsd::cxx::xml::dom::create_element("backup", e) << x; >> } >> void operator()(const ::musicxml::forward &x) const { >> ::xsd::cxx::xml::dom::create_element("forward", e) << x; >> } >> //... >> }; >> >> 4. Rewrite the parsing code to *not* use element_traits::create, >> instead, push_back directly to variant_. >> >> This works WONDERFUL. I really love it. I wonder, have you ever >> considered to implement this as an alternative for --ordered-type? >> Maybe --variant-type= ? --variant-type=class[/accessor] maybe? >> So the user could override the name of the variant() accessor. > > No, I haven't considered it. To do that would require quite a bit > more thinking because while you only needed to handle this particular > case, if we were to implement this in XSD, it would have to work with > all reasonable use-cases (wildcards, mixed content, polymorphic > types are the ones that came to mind; there are most likely others). True. I haven't played with wildcards and mixed content at all, but I can immediately see how polymorphic types would be a problem for this. OTOH, a variant is sort of a different approach to polymorphism. In this particular case, it solves exactly the problem at hand, namely, that the types inside of the container do not have a common base. > At the same time it should be very easy to implement a class > template (using variadic template arguments, if using C++11) that > would allow you to achieve pretty much what you want: > > --custom-type=foo=ordered_as_variant/foo_base That, is a very neat idea! Thanks. I will certainly use that if I end up having to customize more types in this way. -- CYa, ????? From erik.sjolund at gmail.com Wed Dec 17 02:51:17 2014 From: erik.sjolund at gmail.com (=?UTF-8?Q?Erik_Sj=C3=B6lund?=) Date: Wed Dec 17 02:51:24 2014 Subject: [xsd-users] Feature request: c++11 support for examples/cxx/tree/streaming/parser.hxx In-Reply-To: References: Message-ID: Ok! cheers, Erik On Tue, Dec 16, 2014 at 1:54 PM, Boris Kolpackov wrote: > Hi Erik, > > Erik Sj?lund writes: > >> For the rest of the project I am defining the XSD_CXX11 macro, so I >> thought it would be a good idea to adjust the files above to start >> using std::unique_ptr. >> >> It would be nice if the attached patch (or something similar) could be >> merged into CodeSynthesis XSD. The patch is in public domain, so use >> it in whatever way you like. > > Thanks for the patch. Unfortunately, I can only make this change > once we drop support for C++98. While I am very tempted to do > this, I think we will still have to wait for some time. > > Boris From rogerps at tecgraf.puc-rio.br Tue Dec 23 11:41:43 2014 From: rogerps at tecgraf.puc-rio.br (rogerps) Date: Tue Dec 30 08:15:16 2014 Subject: [xsd-users] Fwd: Error using Xerces type with C++11 Message-ID: <92a2b3c47f61def2247a8085683a033b@tecgraf.puc-rio.br> Hi People, I'm using CS in my project with another lib called Reflex to generate a dictionary for CS code. But I'm having problems to use it with VS2013 (C++11). The Reflex generate a use of xsd::cxx::tree::sequence_common::ptr (declared in containers.hxx) with std::_Vector_const_iterator. std::_Vector_const_iterator ask for some declarations in sequence_common::ptr type as value_type, difference_type, etc. Can someone help me on how to change sequence_common::ptr type to this code compile? []s, Rog?rio Pinheiro This is a sample of error list shown by the VS2013: 2>C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include\vector(24): error C2039: 'value_type' : is not a member of 'xsd::cxx::tree::sequence_common::ptr' 2> D:\projects\galileu\gxml\gxml_cmake\src\core\cs\xsd/cxx/tree/containers.hxx(538) : see declaration of 'xsd::cxx::tree::sequence_common::ptr' 2> C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include\xutility(371) : see reference to class template instantiation 'std::_Vector_const_iterator' being compiled 2> d:\SDK\gxml_depends\CodeSynthesis XSD 4.0\include\xsd/cxx/tree/iterator-adapter.hxx(28) : see reference to class template instantiation 'std::iterator_traits' being compiled 2> with 2> [ 2> I=std::_Vector_const_iterator 2> ] 2> d:\SDK\gxml_depends\CodeSynthesis XSD 4.0\include\xsd/cxx/tree/iterator-adapter.hxx(75) : see reference to class template instantiation 'xsd::cxx::tree::iterator_traits' being compiled 2> with 2> [ 2> I=std::_Vector_const_iterator 2> ] 2> GXML-AnalysisParameters_rflx.cpp(31876) : see reference to class template instantiation 'xsd::cxx::tree::iterator_adapter,const GALILEU::tSituaGlobalAnalysisParameter>' being compiled 2>C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include\vector(24): error C2146: syntax error : missing ',' before identifier 'value_type' 2>C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include\vector(24): error C2065: 'value_type' : undeclared identifier 2>C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include\vector(25): error C2039: 'difference_type' : is not a member of 'xsd::cxx::tree::sequence_common::ptr' 2> D:\projects\galileu\gxml\gxml_cmake\src\core\cs\xsd/cxx/tree/containers.hxx(538) : see declaration of 'xsd::cxx::tree::sequence_common::ptr' 2>C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include\vector(25): error C2146: syntax error : missing ',' before identifier 'difference_type' 2>C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include\vector(25): error C2065: 'difference_type' : undeclared identifier 2>C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include\vector(26): error C2039: 'const_pointer' : is not a member of 'xsd::cxx::tree::sequence_common::ptr' 2> D:\projects\galileu\gxml\gxml_cmake\src\core\cs\xsd/cxx/tree/containers.hxx(538) : see declaration of 'xsd::cxx::tree::sequence_common::ptr' 2>C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include\vector(26): error C2146: syntax error : missing ',' before identifier 'const_pointer' 2>C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include\vector(26): error C2065: 'const_pointer' : undeclared identifier 2>C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include\vector(27): error C2039: 'const_reference' : is not a member of 'xsd::cxx::tree::sequence_common::ptr' 2> D:\projects\galileu\gxml\gxml_cmake\src\core\cs\xsd/cxx/tree/containers.hxx(538) : see declaration of 'xsd::cxx::tree::sequence_common::ptr' 2>C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include\vector(27): error C2146: syntax error : missing ',' before identifier 'const_reference' 2>C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include\vector(27): error C2065: 'const_reference' : undeclared identifier 2>C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\include\vector(28): error C2977: 'std::_Iterator012' : too many template arguments From boris at codesynthesis.com Tue Dec 30 09:35:23 2014 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue Dec 30 09:31:52 2014 Subject: [xsd-users] Fwd: Error using Xerces type with C++11 In-Reply-To: <92a2b3c47f61def2247a8085683a033b@tecgraf.puc-rio.br> References: <92a2b3c47f61def2247a8085683a033b@tecgraf.puc-rio.br> Message-ID: Hi, rogerps writes: > I'm using CS in my project with another lib called Reflex to > generate a dictionary for CS code. But I'm having problems to use it > with VS2013 (C++11). > > The Reflex generate a use of xsd::cxx::tree::sequence_common::ptr > (declared in containers.hxx) with std::_Vector_const_iterator. > std::_Vector_const_iterator ask for some declarations in > sequence_common::ptr type as value_type, difference_type, etc. I don't understand why would Reflex expect these typedefs in xsd::cxx::tree::sequence_common::ptr, which is an internal type and is not a container. So you will either need to explain in much more detail what exactly Reflex does with sequence_common::ptr and why it expects these typedefs or, better yet, ask the Reflex's folks; to me it seems like this is their problem, not XSD's. Boris