From bill.npo.wheeler at intel.com Wed Nov 3 23:07:43 2010 From: bill.npo.wheeler at intel.com (Wheeler, Bill NPO) Date: Wed Nov 3 23:07:54 2010 Subject: [xsd-users] namespace mapping Message-ID: <7A447CD3CC413B4D9258027141E7AD0414F54AA581@azsmsx502.amr.corp.intel.com> I'm trying to use the -namespace-regex switch to fix up namespaces of the form: http://some_url_name.com/ns1/ns2/2006/ns3 so that the C++ namespace mapping will be: ns1::ns2::YR06::ns3 (since a C++ namespace can't start with a number) I've read the documentation on this switch several times, but I honestly don't understand how it's specifying the text substitutions (from the help, I suspect I need to know Perl to understand this better). I've tried several different attempts all of which have failed miserably. It seems to me that I should be able to make this transformation, but the exact syntax continues to elude me. Can anyone help me out? Thanks From boris at codesynthesis.com Thu Nov 4 10:57:14 2010 From: boris at codesynthesis.com (Boris Kolpackov) Date: Thu Nov 4 10:49:52 2010 Subject: [xsd-users] namespace mapping In-Reply-To: <7A447CD3CC413B4D9258027141E7AD0414F54AA581@azsmsx502.amr.corp.intel.com> References: <7A447CD3CC413B4D9258027141E7AD0414F54AA581@azsmsx502.amr.corp.intel.com> Message-ID: Hi Bill, Wheeler, Bill NPO writes: > http://some_url_name.com/ns1/ns2/2006/ns3 so that the C++ namespace > mapping will be: ns1::ns2::YR06::ns3 For Linux/UNIX: --namespace-regex '#.* .*/([^/]+)/([^/]+)/\d\d(\d\d)/([^/]+)#$1::$2::YR$3::$4#' For Windows (the same regex, just quoted with " instead of '): --namespace-regex "#.* .*/([^/]+)/([^/]+)/\d\d(\d\d)/([^/]+)#$1::$2::YR$3::$4#" The --*-regex-trace options can be useful when debugging regex in XSD. Boris From sixmoney at gmail.com Fri Nov 5 07:31:41 2010 From: sixmoney at gmail.com (Lorenzo Seidenari) Date: Fri Nov 5 07:41:18 2010 Subject: [xsd-users] compiling schemas with imports Message-ID: I'm trying to compile the following schema http://www.onvif.org/onvif/ver10/schema/onvif.xsd which contains three imports. I receive the following error: >xsdcxx cxx-tree onvif.xsd onvif.xsd: error: 'http://www.w3.org/2005/05/xmlmime': unable to open in read mode I also tried with --file-per-type. The only way to suppress the errors seems to download the imported files locally. Is there a way to directly compile a schema with import without compiling the imports separately? Lorenzo Seidenari, PhD Student Media Integration and Communication Center http://www.micc.unifi.it/seidenari From sir.costy at gmail.com Fri Nov 5 10:09:26 2010 From: sir.costy at gmail.com (Constantin Iacobescu) Date: Fri Nov 5 10:09:30 2010 Subject: [xsd-users] Serialization of a XML to a UNICODE file name Message-ID: Hello everyone, I am try to use a XSD binding of LandXML to read and write thous files. But I have just get in trouble on trying to serialize the xml into a unicode named file, because the generated code is expecting a ostream and I need a wostream... What can be done? Have I miss some on the command line parameters? The command line is this: xsd cxx-tree --generate-serialization --generate-polymorphic --generate-doxygen --generate-wildcard --generate-ostream --root-element-all --char-type wchar_t --type-naming java --function-naming java --namespace-map http://www.landxml.org/schema/LandXML-1.2=LandXML_12LandXML-1.2.xsd So I added the --char-type wchar_t for unicode support, but this is other thing I think. A bit of help will be appreciated. Best Regards, Constantin Iacobescu From boris at codesynthesis.com Fri Nov 5 10:48:09 2010 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri Nov 5 10:40:43 2010 Subject: [xsd-users] compiling schemas with imports In-Reply-To: References: Message-ID: Hi Lorenzo, Lorenzo Seidenari writes: > >xsdcxx cxx-tree onvif.xsd > onvif.xsd: error: 'http://www.w3.org/2005/05/xmlmime': unable to open in > read mode > > [...] > > Is there a way to directly compile a schema with import without compiling > the imports separately? There are two separate questions here. The first is whether it is possible to compile a schema that is a remote resource (HTTP). The answer is no. The XSD compiler does not support network access for various reasons. So you will need to download each imported schema to the disk. Then you can either modify the importing schema to reference the local files or you can use the --location-map option to re-map schema locations without modifying the schema, for example: --location-map http://www.w3.org/2005/05/xmlmime=xmlmime.xsd The second question is whether it is possible to compile just the root schema without having to also compile all the included/imported schemas. The answer is yes. You can use the file-per-type mode to achieve this. Note, however, that it is more manageable to compile schemas using the default file-per-schema mode since the number of files generated in the file-per-type mode can be quite large. Plus, if all your schemas are in the same directory, you can compile them all in one go: xsdcxx cxx-tree *.xsd Boris From boris at codesynthesis.com Fri Nov 5 11:09:08 2010 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri Nov 5 11:01:57 2010 Subject: [xsd-users] Serialization of a XML to a UNICODE file name In-Reply-To: References: Message-ID: Hi Constantin, Constantin Iacobescu writes: > But I have just get in trouble on trying to serialize the xml into a unicode > named file, because the generated code is expecting a ostream and I need a > wostream... The generated code uses std::o/istream for XML input and output because, in the general case, the stream is binary, not text and the underlying i/o unit is one byte, not one character. The only way to overcome this with std streams would be to convert the wide character file name to the multi-byte char string and use that with std::o/istream. However, depending on the locale, there can be loss of data. A better way to handle this would be to use Xerces-C++ file streams which always use UTF-16 file names. Here is some sample code (based on the library example): #include #include #include using namespace xercesc; int main () { XMLPlatformUtils::Initialize (); // Parse. // LocalFileInputSource is (L"input.xml"); std::auto_ptr c (catalog_ (is)); ... // Serialize. // LocalFileFormatTarget os (L"output.xml"); catalog_ (os, *c, map); XMLPlatformUtils::Teminate (); } Boris From darren.garvey at gmail.com Fri Nov 5 11:57:07 2010 From: darren.garvey at gmail.com (Darren Garvey) Date: Fri Nov 5 12:12:47 2010 Subject: [xsd-users] Outputting hxx and cxx files to different directories Message-ID: Hi, I would like to be able to get XSD to generate my source files and put them in the correct directories - ie. headers and source files don't live in the same place. I could use custom forwarding headers but would rather not have to. Essentially I'm looking for a special version of --output-dir. Is something like this available? Thanks, Darren From boris at codesynthesis.com Fri Nov 5 14:46:56 2010 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri Nov 5 14:39:30 2010 Subject: [xsd-users] Outputting hxx and cxx files to different directories In-Reply-To: References: Message-ID: Hi Darren, Darren Garvey writes: > I would like to be able to get XSD to generate my source files and put them > in the correct directories - ie. headers and source files don't live in the > same place. I could use custom forwarding headers but would rather not have > to. > > Essentially I'm looking for a special version of --output-dir. Is something > like this available? No, there is no such option. It shouldn't be difficult to place the generated files into different sub-directories using shell commands (e.g., mv). What can be less obvious is how to make sure the generate source file can still include the generated header. This is usually not an issue if you compile with the -I option that points to the directory with the headers. But often the headers are supposed to be included with a leading directory prefix, for example: #include To help with this issue, the XSD compiler provides a set of --include-* options that allow you to transform include paths and style. The most commonly used ones are --include-with-brackets and --include-prefix. The former changes the include style from quotes ("") to brackets (<>). The latter allows you to specify a directory prefix that should be added to include paths (there is also --include-regex which provides greater flexibility). So to change the include from "bar.hxx" to , one can use the following two options: --include-prefix foo --include-with-brackets Another option that is usually used together with --include-prefix is --guard-prefix. It allows you to add a prefix to the include header guards which should help prevent conflicts. For example: --include-prefix FOO Boris From bill.npo.wheeler at intel.com Sun Nov 7 18:49:40 2010 From: bill.npo.wheeler at intel.com (Wheeler, Bill NPO) Date: Sun Nov 7 18:49:50 2010 Subject: [xsd-users] how to make arbitrary element insertions in a "mixed" sequence of elements where the CodeSynthesis data model does not adequately describe the ordering of elements Message-ID: <7A447CD3CC413B4D9258027141E7AD0414F5501ADF@azsmsx502.amr.corp.intel.com> I have a schema (which I cannot modify) that has the property where 2 types of elements can be inter-mingled arbitrarily. To be more specific, the following stripped down schema describes the situation I have: I think this falls under the category of a "mixed content" model whereby the CodeSynthesis data model does not reflect the actual ordering of elements. That is, the X_root object will have an A list and B list of elements, but not a list that reflects the inter-mingled list of A/B elements. I've read the CodeSyntheis doc describing "DOM Association" which indicates how I can find the underlying DOM objects so that I can infer the sequential order of the "A" and "B" elements. However, this section goes on to say that you can't modify and then serialize the structure back out to an xml file using this technique, and that you should use the custom parsing constructs and serialization operators to do this, as demo'd in your mixed-xerces2-8 example project...but this project does not really demonstrate how to insert an element in an arbitrary position. I'm wondering if the following idea might work instead of using the custom parsing constructs and serialization operators. Let's say my original XML looks like: 1 2 0 3 Say I want to insert a new elem just before the elem (and just after the 2nd elem). Could I simply create a new B elem and do a "push_back" onto the B elem list of the X_root object. Then find the underlying DOM node for that new B elem, remove it from its parent node and then re-insert it as a child node of the same parent node in the correct position. Would this work? Do I care about the ordering of the and elements on their respective lists in the X_root object? If this idea, is totally off base, what approach should I be considering to make arbitrary element insertions in mixed data lists? Thanks, Bill From boris at codesynthesis.com Mon Nov 8 10:00:11 2010 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon Nov 8 09:52:40 2010 Subject: [xsd-users] how to make arbitrary element insertions in a "mixed" sequence of elements where the CodeSynthesis data model does not adequately describe the ordering of elements In-Reply-To: <7A447CD3CC413B4D9258027141E7AD0414F5501ADF@azsmsx502.amr.corp.intel.com> References: <7A447CD3CC413B4D9258027141E7AD0414F5501ADF@azsmsx502.amr.corp.intel.com> Message-ID: Wheeler, Bill NPO writes: > I have a schema (which I cannot modify) that has the property where 2 types of elements can be inter-mingled arbitrarily. To be more specific, the following stripped down schema describes the situation I have: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I think this falls under the category of a "mixed content" model whereby > the CodeSynthesis data model does not reflect the actual ordering of > elements. That is, the X_root object will have an A list and B list > of elements, but not a list that reflects the inter-mingled list of > A/B elements. This is not really a mixed content model. The issue here is with the way C++/Tree represents the content model. To keep the API simple, C++/Tree "flattens" the content which, in some cases, can lead to loss of the order information. The following thread discusses this problem in detail and lists all the available solutions: http://www.codesynthesis.com/pipermail/xsd-users/2010-March/002741.html > Say I want to insert a new elem just before the elem (and just > after the 2nd elem). Could I simply create a new B elem and do a > "push_back" onto the B elem list of the X_root object. Then find the > underlying DOM node for that new B elem, remove it from its parent node > and then re-insert it as a child node of the same parent node in the > correct position. Would this work? Unfortunately, this won't work. When you programmatically create a node in the object model, the underlying DOM nodes are not created. For this to work you would need to manually create the DOM node (which can be done using the serialization operator), then associate it with the object model node, and, finally, insert it in the right position in the DOM document. This can be done. It is just a lot of work. Type customization will be a simpler solution. Boris From bill.npo.wheeler at intel.com Mon Nov 8 11:50:33 2010 From: bill.npo.wheeler at intel.com (Wheeler, Bill NPO) Date: Mon Nov 8 11:50:44 2010 Subject: [xsd-users] how to make arbitrary element insertions in a "mixed" sequence of elements where the CodeSynthesis data model does not adequately describe the ordering of elements In-Reply-To: References: <7A447CD3CC413B4D9258027141E7AD0414F5501ADF@azsmsx502.amr.corp.intel.com> Message-ID: <7A447CD3CC413B4D9258027141E7AD0414F5501D54@azsmsx502.amr.corp.intel.com> Boris, Thanks for your response. After reading thru the material, I can appreciate how type customization acts as a low-level tool for me to override parsing and serialization functions to handle my arbitrary insertion of different element types into a list such that the order of these elements is important and maintainable. However, I wanted to validate with you what the overall implementation approach would be as the cited examples stop short of describing this and I don't fully understand the underlying implementation of your design. Here's my idea of what this might look like: 1) After reading/parsing an XML file, traverse across the A_elem and B_elem datamodel lists. For each element, find the underlying DOM node and infer its node position on the child list of the parent DOM node. Then place the A_elem (or B_elem) element on a "common order list" to reflect the overall ordering. 2) When I choose to insert new A or B elements at arbitrary positions in the order, insert them onto this common order list, to describe their relative position. 3) At serialization time, using my own overridden "operator<<" function, wait until the last serialization call has been made for all the A and B elems. When that final serialization call is made, all the DOM nodes are now known and can then be re-ordered based on the common order list. Is this approach valid, or is there a better way? Thanks, Bill -----Original Message----- From: Boris Kolpackov [mailto:boris@codesynthesis.com] Sent: Monday, November 08, 2010 10:00 AM To: Wheeler, Bill NPO Cc: xsd-users@codesynthesis.com Subject: Re: [xsd-users] how to make arbitrary element insertions in a "mixed" sequence of elements where the CodeSynthesis data model does not adequately describe the ordering of elements Wheeler, Bill NPO writes: > I have a schema (which I cannot modify) that has the property where 2 types of elements can be inter-mingled arbitrarily. To be more specific, the following stripped down schema describes the situation I have: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I think this falls under the category of a "mixed content" model whereby > the CodeSynthesis data model does not reflect the actual ordering of > elements. That is, the X_root object will have an A list and B list > of elements, but not a list that reflects the inter-mingled list of > A/B elements. This is not really a mixed content model. The issue here is with the way C++/Tree represents the content model. To keep the API simple, C++/Tree "flattens" the content which, in some cases, can lead to loss of the order information. The following thread discusses this problem in detail and lists all the available solutions: http://www.codesynthesis.com/pipermail/xsd-users/2010-March/002741.html > Say I want to insert a new elem just before the elem (and just > after the 2nd elem). Could I simply create a new B elem and do a > "push_back" onto the B elem list of the X_root object. Then find the > underlying DOM node for that new B elem, remove it from its parent node > and then re-insert it as a child node of the same parent node in the > correct position. Would this work? Unfortunately, this won't work. When you programmatically create a node in the object model, the underlying DOM nodes are not created. For this to work you would need to manually create the DOM node (which can be done using the serialization operator), then associate it with the object model node, and, finally, insert it in the right position in the DOM document. This can be done. It is just a lot of work. Type customization will be a simpler solution. Boris From bill.npo.wheeler at intel.com Mon Nov 8 16:07:30 2010 From: bill.npo.wheeler at intel.com (Wheeler, Bill NPO) Date: Mon Nov 8 16:07:45 2010 Subject: [xsd-users] how to make arbitrary element insertions in a "mixed" sequence of elements where the CodeSynthesis data model does not adequately describe the ordering of elements References: <7A447CD3CC413B4D9258027141E7AD0414F5501ADF@azsmsx502.amr.corp.intel.com> Message-ID: <7A447CD3CC413B4D9258027141E7AD0414F5502071@azsmsx502.amr.corp.intel.com> Boris, Never mind my last question as I think I understand the better approach now...the trick is to override the "parse" and "operator<<" in the class *containing* the order-dependent elements. Things get much cleaner and straight forward then. I now have a much simpler question. If I have a derived class, C_container (with auto-generated base class C_container_base) with the following constructor: C_container::C_container (const xercesc::DOMElement& e, ::xml_schema::flags f, ::xml_schema::container* c) : C_container_base( e, f, c ) { if ((f & ::xml_schema::flags::base) == 0) { ::xsd::cxx::xml::dom::parser< char > p (e, true, false); this->parse (p, f); } } When this calls into the C_container_base version of the constructor, I want the value of "f" to be such that it does not invoke the base class version of the parse method, because I will customize the parse function in the C_container class. From the definition of ::xml_schema::flags, it is not clear to me what value of "f" I should use to inhibit the base class parse method. What value would you suggest? Thanks -----Original Message----- From: Wheeler, Bill NPO Sent: Monday, November 08, 2010 11:51 AM To: 'Boris Kolpackov' Cc: xsd-users@codesynthesis.com Subject: RE: [xsd-users] how to make arbitrary element insertions in a "mixed" sequence of elements where the CodeSynthesis data model does not adequately describe the ordering of elements Boris, Thanks for your response. After reading thru the material, I can appreciate how type customization acts as a low-level tool for me to override parsing and serialization functions to handle my arbitrary insertion of different element types into a list such that the order of these elements is important and maintainable. However, I wanted to validate with you what the overall implementation approach would be as the cited examples stop short of describing this and I don't fully understand the underlying implementation of your design. Here's my idea of what this might look like: 1) After reading/parsing an XML file, traverse across the A_elem and B_elem datamodel lists. For each element, find the underlying DOM node and infer its node position on the child list of the parent DOM node. Then place the A_elem (or B_elem) element on a "common order list" to reflect the overall ordering. 2) When I choose to insert new A or B elements at arbitrary positions in the order, insert them onto this common order list, to describe their relative position. 3) At serialization time, using my own overridden "operator<<" function, wait until the last serialization call has been made for all the A and B elems. When that final serialization call is made, all the DOM nodes are now known and can then be re-ordered based on the common order list. Is this approach valid, or is there a better way? Thanks, Bill -----Original Message----- From: Boris Kolpackov [mailto:boris@codesynthesis.com] Sent: Monday, November 08, 2010 10:00 AM To: Wheeler, Bill NPO Cc: xsd-users@codesynthesis.com Subject: Re: [xsd-users] how to make arbitrary element insertions in a "mixed" sequence of elements where the CodeSynthesis data model does not adequately describe the ordering of elements Wheeler, Bill NPO writes: > I have a schema (which I cannot modify) that has the property where 2 types of elements can be inter-mingled arbitrarily. To be more specific, the following stripped down schema describes the situation I have: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I think this falls under the category of a "mixed content" model whereby > the CodeSynthesis data model does not reflect the actual ordering of > elements. That is, the X_root object will have an A list and B list > of elements, but not a list that reflects the inter-mingled list of > A/B elements. This is not really a mixed content model. The issue here is with the way C++/Tree represents the content model. To keep the API simple, C++/Tree "flattens" the content which, in some cases, can lead to loss of the order information. The following thread discusses this problem in detail and lists all the available solutions: http://www.codesynthesis.com/pipermail/xsd-users/2010-March/002741.html > Say I want to insert a new elem just before the elem (and just > after the 2nd elem). Could I simply create a new B elem and do a > "push_back" onto the B elem list of the X_root object. Then find the > underlying DOM node for that new B elem, remove it from its parent node > and then re-insert it as a child node of the same parent node in the > correct position. Would this work? Unfortunately, this won't work. When you programmatically create a node in the object model, the underlying DOM nodes are not created. For this to work you would need to manually create the DOM node (which can be done using the serialization operator), then associate it with the object model node, and, finally, insert it in the right position in the DOM document. This can be done. It is just a lot of work. Type customization will be a simpler solution. Boris From boris at codesynthesis.com Tue Nov 9 08:51:28 2010 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue Nov 9 08:43:58 2010 Subject: [xsd-users] how to make arbitrary element insertions in a "mixed" sequence of elements where the CodeSynthesis data model does not adequately describe the ordering of elements In-Reply-To: <7A447CD3CC413B4D9258027141E7AD0414F5502071@azsmsx502.amr.corp.intel.com> References: <7A447CD3CC413B4D9258027141E7AD0414F5501ADF@azsmsx502.amr.corp.intel.com> <7A447CD3CC413B4D9258027141E7AD0414F5502071@azsmsx502.amr.corp.intel.com> Message-ID: Hi Bill, Wheeler, Bill NPO writes: > When this calls into the C_container_base version of the constructor, > I want the value of "f" to be such that it does not invoke the base > class version of the parse method, because I will customize the parse > function in the C_container class. If you pass (f | xml_schema::flags::base) to the base c-tor in which case it will not perform any parsing. But I think the better way to achieve this is not to generate the base class at all. You don't need the generated parsing/serialization code and it will be easier to come up with a custom interface for accessing elements rather than trying to complete the generated interface with some kind of order lists, etc. Here is how I would handle this: 1. Completely customize the X_root type (i.e., don't generate the base type). The custom X_root interface would look along these lines: class X_root: public ::xml_schema::type { public: struct choice_element { enum arm_tag { A_tag, B_tag }; arm_tag arm () const { return arm_; } A_elem& a (); B_elem& b (); // Constructors // choice_element (A_elem* a) : arm_ (A_tag) { element_.a = a; } choice_element (B_elem* b); // Same as above. // Copy c-tor, copy assignment operators, and d-tor // implementations are straightforward. // private: arm_tag arm_; union { A_elem* a; B_elem* b; } element_; }; typedef std::vector choice_sequence; typedef choice_sequence::iterator choice_iterator; typedef choice_sequence::const_iterator const_choice_iterator; choice_sequence& choice (); X_root (); X_root (const xercesc::DOMElement& e, xml_schema::flags f = 0, xml_schema::container* c = 0); // The rest of the c-tors as in the generated code. // private: choice_sequence choice_; }; void operator<< (xercesc::DOMElement&, const X_root&); 2. In the parsing constructor iterate over DOM elements and parse each either as A or B depending on the name (you can copy most of the code from the generated version). 3. In the serialiation operator iterate over the choice sequence and serialize each element as either A or B depending on the arm tag. Again, you can copy most of the code from the generated version. Boris From bill.npo.wheeler at intel.com Tue Nov 9 11:02:02 2010 From: bill.npo.wheeler at intel.com (Wheeler, Bill NPO) Date: Tue Nov 9 11:02:20 2010 Subject: [xsd-users] how to make arbitrary element insertions in a "mixed" sequence of elements where the CodeSynthesis data model does not adequately describe the ordering of elements In-Reply-To: References: <7A447CD3CC413B4D9258027141E7AD0414F5501ADF@azsmsx502.amr.corp.intel.com> <7A447CD3CC413B4D9258027141E7AD0414F5502071@azsmsx502.amr.corp.intel.com> Message-ID: <7A447CD3CC413B4D9258027141E7AD0414F55024CD@azsmsx502.amr.corp.intel.com> Boris, Thanks for your response. The reason I want to generate the base class version is because my actual X_root class is way more complex than the simplified example we've been discussing. Thus I'd like CodeSynthesis to do all the heavy lifting for me by generating most of the code in the base class. So that's why I ask the question about the flag setting to disable base class parsing being invoked from the base class constructor. More specifically, the reason I asked the flag setting question is I wasn't sure if there would be other unintended functional artifacts by passing "(f | xml_schema::flags::base)" in to the base class. From your response, I presume this is not a problem. Thanks again for your thorough response...I very much appreciate it. Bill -----Original Message----- From: Boris Kolpackov [mailto:boris@codesynthesis.com] Sent: Tuesday, November 09, 2010 8:51 AM To: Wheeler, Bill NPO Cc: xsd-users@codesynthesis.com Subject: Re: [xsd-users] how to make arbitrary element insertions in a "mixed" sequence of elements where the CodeSynthesis data model does not adequately describe the ordering of elements Hi Bill, Wheeler, Bill NPO writes: > When this calls into the C_container_base version of the constructor, > I want the value of "f" to be such that it does not invoke the base > class version of the parse method, because I will customize the parse > function in the C_container class. If you pass (f | xml_schema::flags::base) to the base c-tor in which case it will not perform any parsing. But I think the better way to achieve this is not to generate the base class at all. You don't need the generated parsing/serialization code and it will be easier to come up with a custom interface for accessing elements rather than trying to complete the generated interface with some kind of order lists, etc. Here is how I would handle this: 1. Completely customize the X_root type (i.e., don't generate the base type). The custom X_root interface would look along these lines: class X_root: public ::xml_schema::type { public: struct choice_element { enum arm_tag { A_tag, B_tag }; arm_tag arm () const { return arm_; } A_elem& a (); B_elem& b (); // Constructors // choice_element (A_elem* a) : arm_ (A_tag) { element_.a = a; } choice_element (B_elem* b); // Same as above. // Copy c-tor, copy assignment operators, and d-tor // implementations are straightforward. // private: arm_tag arm_; union { A_elem* a; B_elem* b; } element_; }; typedef std::vector choice_sequence; typedef choice_sequence::iterator choice_iterator; typedef choice_sequence::const_iterator const_choice_iterator; choice_sequence& choice (); X_root (); X_root (const xercesc::DOMElement& e, xml_schema::flags f = 0, xml_schema::container* c = 0); // The rest of the c-tors as in the generated code. // private: choice_sequence choice_; }; void operator<< (xercesc::DOMElement&, const X_root&); 2. In the parsing constructor iterate over DOM elements and parse each either as A or B depending on the name (you can copy most of the code from the generated version). 3. In the serialiation operator iterate over the choice sequence and serialize each element as either A or B depending on the arm tag. Again, you can copy most of the code from the generated version. Boris From bschindler at inf.ethz.ch Thu Nov 18 04:26:10 2010 From: bschindler at inf.ethz.ch (Benjamin Schindler) Date: Thu Nov 18 04:28:48 2010 Subject: [xsd-users] Feature request: Explicit constructors Message-ID: <4CE4F132.9090607@inf.ethz.ch> Hi I just stumbled across a problem with explicit conversions. I have a class with 2 constructors: MyClass(FrameKind, double) MyClass(const std::string&, double) Now, FrameKind is a class generated from xml, and it looks like this: When calling the constructor with MyClass("someText", 1.0), the compiler refuses as the string someText can be implicitly converted to a FrameKind. Would it be possible to make this constructor explicit preventing the implicit conversion? Thank You Benjamin Schindler From boris at codesynthesis.com Thu Nov 18 08:36:55 2010 From: boris at codesynthesis.com (Boris Kolpackov) Date: Thu Nov 18 08:29:34 2010 Subject: [xsd-users] Feature request: Explicit constructors In-Reply-To: <4CE4F132.9090607@inf.ethz.ch> References: <4CE4F132.9090607@inf.ethz.ch> Message-ID: Hi Benjamin, Benjamin Schindler writes: > I just stumbled across a problem with explicit conversions. I have a > class with 2 constructors: > > MyClass(FrameKind, double) > MyClass(const std::string&, double) Can you show the schema definition for MyClass? Boris From bschindler at inf.ethz.ch Thu Nov 18 08:35:46 2010 From: bschindler at inf.ethz.ch (Benjamin Schindler) Date: Thu Nov 18 08:38:16 2010 Subject: [xsd-users] Feature request: Explicit constructors In-Reply-To: References: <4CE4F132.9090607@inf.ethz.ch> Message-ID: <4CE52BB2.6090401@inf.ethz.ch> Hi Boris MyClass is not from a schema, but my own class (hence the name). Because of the way the class works, having these two constructors makes a lot of sense, but I'm unable to provide them due to the missing explicit keyword in the constructor of FrameKind(const std::string& str) Cheers Benjamin On 11/18/2010 02:36 PM, Boris Kolpackov wrote: > Hi Benjamin, > > Benjamin Schindler writes: > >> I just stumbled across a problem with explicit conversions. I have a >> class with 2 constructors: >> >> MyClass(FrameKind, double) >> MyClass(const std::string&, double) > > Can you show the schema definition for MyClass? > > Boris From rlischner at proteuseng.com Thu Nov 18 09:52:14 2010 From: rlischner at proteuseng.com (Ray Lischner) Date: Thu Nov 18 15:06:37 2010 Subject: [xsd-users] Feature request: Explicit constructors In-Reply-To: <4CE4F132.9090607@inf.ethz.ch> References: <4CE4F132.9090607@inf.ethz.ch> Message-ID: Benjamin Schindler writes: > I just stumbled across a problem with explicit conversions. I have a > class with 2 constructors: > > MyClass(FrameKind, double) > MyClass(const std::string&, double) > ... The implicit string constructors are extremely useful. I would resolve the ambiguity by adding a constructor to MyClass: MyClass(char const*, double) Ray Lischner, Senior Member of Technical Staff 133 National Business Pkwy, Ste 150 t. 443.539.3448 Annapolis Junction, MD 20701 c. 410.854.5170 rlischner@proteuseng.com f. 443.539.3370 This electronic message and any files transmitted with it contain information which may be privileged and/or proprietary. The information is intended for use solely by the intended recipient(s). If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of this information is prohibited. If you have received this electronic message in error, please advise the sender by reply email or by telephone (443.539.3400) and delete the message. From bschindler at inf.ethz.ch Thu Nov 18 17:03:12 2010 From: bschindler at inf.ethz.ch (Benjamin Schindler) Date: Thu Nov 18 17:03:23 2010 Subject: [xsd-users] Feature request: Explicit constructors In-Reply-To: References: <4CE4F132.9090607@inf.ethz.ch> Message-ID: <4CE5A2A0.1000802@inf.ethz.ch> In C++, implicit type conversions are usually not recommended due to the difficult predictability of performance. Using explicit as much as possible is recommended, see i.e. http://www.doc.ic.ac.uk/lab/cplus/c++.rules/chap13.html I know they are useful - but they are only useful until you get hit by a type conversion you didn't expect causing weird bugs, at which point you usually stop using them for 99% percent of the code. For a generic library such as xsd doubly so Cheers Benjamin On 18.11.2010 14:52, Ray Lischner wrote: > Benjamin Schindler writes: > >> I just stumbled across a problem with explicit conversions. I have a >> class with 2 constructors: >> >> MyClass(FrameKind, double) >> MyClass(const std::string&, double) >> ... > > The implicit string constructors are extremely useful. I would resolve the ambiguity by adding a constructor to MyClass: > > MyClass(char const*, double) > > Ray Lischner, > Senior Member of Technical Staff > 133 National Business Pkwy, Ste 150 t. 443.539.3448 > Annapolis Junction, MD 20701 c. 410.854.5170 > rlischner@proteuseng.com f. 443.539.3370 > > This electronic message and any files transmitted with it contain information > which may be privileged and/or proprietary. The information is intended for use > solely by the intended recipient(s). If you are not the intended recipient, be > aware that any disclosure, copying, distribution or use of this information is > prohibited. If you have received this electronic message in error, please advise > the sender by reply email or by telephone (443.539.3400) and delete the message. > From sir.costy at gmail.com Fri Nov 19 04:52:44 2010 From: sir.costy at gmail.com (Constantin Iacobescu) Date: Fri Nov 19 04:52:47 2010 Subject: [xsd-users] xml_schema::Date and xml_schema::Time are wrong serialized on UNICODE files Message-ID: Hello everyone, I am try to use a XSD binding of LandXML to read and write thous files. But I have just get in trouble on trying to serialize the xml, because the date and time it is written wrong in file. The command line is this: xsd cxx-tree --generate-serialization --generate-polymorphic --generate-doxygen --generate-wildcard --generate-ostream --root-element-all --char-type wchar_t --type-naming java --function-naming java --namespace-map http://www.landxml.org/schema/LandXML-1.2=LandXML_12LandXML-1.2.xsd So I added the --char-type wchar_t for unicode support. The code I use is this: XMLPlatformUtils::Initialize (); LocalFileFormatTarget formatTarget (fileName.c_str()); xml_schema::Date _date(2010, 12, 24); xml_schema::Time _time( 14, 35, 42); std::auto_ptr objLandXML ( new LandXML(_date, _time, L"1.2")); xml_schema::NamespaceInfomap infoMap; infoMap[L""].name = L"http://www.landxml.org/schema/LandXML-1.2"; infoMap[L""].schema = L" http://www.landxml.org/schema/LandXML-1.2/LandXML-1.2.xsd"; serializeLandXML(formatTarget, *objLandXML, infoMap, L"UTF-8", xml_schema::Flags::dont_initialize); XMLPlatformUtils::Terminate (); I use LocalFileFormatTarget xercesc function because te name of the file may be unicode too. But think this is other thing. And what I get in to the file it is this: And all the places I want to use the xml_schema::Date or xml_schema::Time gaves me the same problem. A bit of help will be appreciated. Best Regards, Constantin Iacobescu -- Constantin Iacobescu From bschindler at inf.ethz.ch Fri Nov 19 08:09:49 2010 From: bschindler at inf.ethz.ch (Benjamin Schindler) Date: Fri Nov 19 08:12:27 2010 Subject: [xsd-users] Feature request: Explicit constructors In-Reply-To: References: <4CE4F132.9090607@inf.ethz.ch> , <4CE5A2A0.1000802@inf.ethz.ch> Message-ID: <4CE6771D.6050507@inf.ethz.ch> Hi On 11/19/2010 01:59 PM, Ray Lischner wrote: > Benjamin Schindler writes: >> In C++, implicit type conversions are usually not recommended due to the >> difficult predictability of performance. Using explicit as much as >> possible is recommended, see i.e. >> http://www.doc.ic.ac.uk/lab/cplus/c++.rules/chap13.html > >> I know they are useful - but they are only useful until you get hit by a >> type conversion you didn't expect causing weird bugs, at which point you >> usually stop using them for 99% percent of the code. For a generic >> library such as xsd doubly so > > The MyClass constructors that are already defined rely on implicit construction of std::string from char const*. > My recommendation is to add a constructor to bypass that implicit construction and to be explicit about the construction of MyClass from char const*. There are a few problems here: - the implicit conversion from const char* to std::string is required by the standard (I thought) and natural because you're basically converting a string to a string - Converting a string to an enum by implicit conversion is a very suspicious operation at best (Is the value defined? If not, exception? Error?). If you really want it, make it explicit by calling FrameKind("myString") - I'm not trying to disable that. This also makes you aware that this constructor might throw etc. I consider this a lot more clean tells the developer clearly what's happening. - The bypass doesn't really work, see the example below: void someFunction(const char* arg); std::string myString = "someValue"; someFunction(myString); // does not compile, but I require that I know, there is c_str(), but now we're really working around a problem. Cheers Benjamin > > Ray Lischner, > Senior Member of Technical Staff > 133 National Business Pkwy, Ste 150 t. 443.539.3448 > Annapolis Junction, MD 20701 c. 410.854.5170 > rlischner@proteuseng.com f. 443.539.3370 > > This electronic message and any files transmitted with it contain information > which may be privileged and/or proprietary. The information is intended for use > solely by the intended recipient(s). If you are not the intended recipient, be > aware that any disclosure, copying, distribution or use of this information is > prohibited. If you have received this electronic message in error, please advise > the sender by reply email or by telephone (443.539.3400) and delete the message. From rlischner at proteuseng.com Fri Nov 19 07:59:35 2010 From: rlischner at proteuseng.com (Ray Lischner) Date: Fri Nov 19 09:33:07 2010 Subject: [xsd-users] Feature request: Explicit constructors In-Reply-To: <4CE5A2A0.1000802@inf.ethz.ch> References: <4CE4F132.9090607@inf.ethz.ch> , <4CE5A2A0.1000802@inf.ethz.ch> Message-ID: Benjamin Schindler writes: > In C++, implicit type conversions are usually not recommended due to the > difficult predictability of performance. Using explicit as much as > possible is recommended, see i.e. > http://www.doc.ic.ac.uk/lab/cplus/c++.rules/chap13.html > I know they are useful - but they are only useful until you get hit by a > type conversion you didn't expect causing weird bugs, at which point you > usually stop using them for 99% percent of the code. For a generic > library such as xsd doubly so The MyClass constructors that are already defined rely on implicit construction of std::string from char const*. My recommendation is to add a constructor to bypass that implicit construction and to be explicit about the construction of MyClass from char const*. Ray Lischner, Senior Member of Technical Staff 133 National Business Pkwy, Ste 150 t. 443.539.3448 Annapolis Junction, MD 20701 c. 410.854.5170 rlischner@proteuseng.com f. 443.539.3370 This electronic message and any files transmitted with it contain information which may be privileged and/or proprietary. The information is intended for use solely by the intended recipient(s). If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of this information is prohibited. If you have received this electronic message in error, please advise the sender by reply email or by telephone (443.539.3400) and delete the message. From boris at codesynthesis.com Fri Nov 19 09:44:14 2010 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri Nov 19 09:36:52 2010 Subject: [xsd-users] xml_schema::Date and xml_schema::Time are wrong serialized on UNICODE files In-Reply-To: References: Message-ID: Hi Constantin, Constantin Iacobescu writes: > And what I get in to the file it is this: > [...] > date="2010-0 -0" > time="0:0#:42" Hm, this is strange. The symbols that you get are probably different from what I see in the email because of the mail client conversions. Can you create a small but complete test case (schema, driver, and makefile/project file) that reproduces this problem (you can use one of the examples as a base). Also, which compiler/platform are you using? Boris From boris at codesynthesis.com Fri Nov 19 09:53:03 2010 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri Nov 19 09:45:41 2010 Subject: [xsd-users] Feature request: Explicit constructors In-Reply-To: <4CE6771D.6050507@inf.ethz.ch> References: <4CE4F132.9090607@inf.ethz.ch> <4CE5A2A0.1000802@inf.ethz.ch> <4CE6771D.6050507@inf.ethz.ch> Message-ID: Hi Benjamin, Benjamin Schindler writes: > There are a few problems here: > - the implicit conversion from const char* to std::string is required by > the standard (I thought) and natural because you're basically converting > a string to a string Correct. > - Converting a string to an enum by implicit conversion is a very > suspicious operation at best (Is the value defined? If not, exception? > Error?). If you really want it, make it explicit by calling > FrameKind("myString") - I'm not trying to disable that. This also makes > you aware that this constructor might throw etc. I consider this a lot > more clean tells the developer clearly what's happening. You can argue it either way. In your schema you define the enum by deriving from xsd:string. So this type also "is a" string, just like std::string (and, in fact, derives from). In C++/Tree string- based enums have dual interface: you can work with them as with strings or as C++ enums. Most users find it convenient to be able to implicitly initialize a enum with a string literal. If you really, absolutely, have to disable this functionality, then you can customize the type in question and provide your won c-tors. > - The bypass doesn't really work, see the example below: > > void someFunction(const char* arg); > > std::string myString = "someValue"; > someFunction(myString); // does not compile, but I require that This will never work, regardless of what we do in XSD. In fact, the above example doesn't involve any XSD-genearted or your own types so I don't quite see how this demonstrates that adding the third c-tor overload to MyClass does not work. Can you elaborate a bit here? Boris From sir.costy at gmail.com Fri Nov 19 10:02:37 2010 From: sir.costy at gmail.com (Constantin Iacobescu) Date: Fri Nov 19 10:02:40 2010 Subject: [xsd-users] xml_schema::Date and xml_schema::Time are wrong serialized on UNICODE files In-Reply-To: References: Message-ID: Yes, it's really weird.. actually if I look on debugger I can see that the strange characters look the same. Let say what you see in the file is the integer or short interpreted like a char value. Here is attached a basic xml exported from a test app. I use the latest XSD binary and m working on windows and VS2008 The real code I used before discover the error was some like this: signed short year = 2010; signed char month = 12; signed char day = 12; signed char month = 12; signed char hour = 14; signed char min = 35; signed char sec = 42; std::auto_ptr objLandXML ( new LandXML(xml_schema::Date(year, (unsigned short)month, (unsigned short)day), xml_schema::Time((unsigned short)hour, (unsigned short)min, (unsigned short)sec), L"1.2")); And in this way I could see in debugger that the reinterpreted value of month, day, hour, etc to a char is looking the same like in xml file. On Fri, Nov 19, 2010 at 3:44 PM, Boris Kolpackov wrote: > Hi Constantin, > > Constantin Iacobescu writes: > > > And what I get in to the file it is this: > > [...] > > date="2010-0 -0 " > > time="0 :0#:42" > > Hm, this is strange. The symbols that you get are probably different > from what I see in the email because of the mail client conversions. > Can you create a small but complete test case (schema, driver, and > makefile/project file) that reproduces this problem (you can use > one of the examples as a base). Also, which compiler/platform are > you using? > > Boris > -- Constantin Iacobescu -------------- next part -------------- A non-text attachment was scrubbed... Name: TestLandXML.xml Type: text/xml Size: 339 bytes Desc: not available Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20101119/d3cf93d5/TestLandXML.bin From bschindler at inf.ethz.ch Fri Nov 19 10:05:08 2010 From: bschindler at inf.ethz.ch (Benjamin Schindler) Date: Fri Nov 19 10:07:46 2010 Subject: [xsd-users] Feature request: Explicit constructors In-Reply-To: References: <4CE4F132.9090607@inf.ethz.ch> <4CE5A2A0.1000802@inf.ethz.ch> <4CE6771D.6050507@inf.ethz.ch> Message-ID: <4CE69224.8030806@inf.ethz.ch> On 11/19/2010 03:53 PM, Boris Kolpackov wrote: > Hi Benjamin, > > Benjamin Schindler writes: > >> There are a few problems here: >> - the implicit conversion from const char* to std::string is required by >> the standard (I thought) and natural because you're basically converting >> a string to a string > > Correct. > > > This will never work, regardless of what we do in XSD. In fact, > the above example doesn't involve any XSD-genearted or your own > types so I don't quite see how this demonstrates that adding the > third c-tor overload to MyClass does not work. Can you elaborate > a bit here? Ray proposed to change my constructor to const char*: "I would resolve the ambiguity by adding a constructor to MyClass: MyClass(char const*, double)" And I showed that this introduces new problems as I cannot pass std::string's anymore to the constructor Cheers Benjamin > > Boris From sir.costy at gmail.com Fri Nov 19 10:46:01 2010 From: sir.costy at gmail.com (Constantin Iacobescu) Date: Fri Nov 19 10:46:05 2010 Subject: [xsd-users] xml_schema::Date and xml_schema::Time are wrong serialized on UNICODE files In-Reply-To: References: Message-ID: Hello Boris, I think I found which is the error, but dont know how to solve it... If you look in the xml file I have sent to you and look at it in a hex editor you will see that if you are converting that strange values from hex to dec you will get the good value of them Ex: month in file have the value 0x0c and converted to decimal is 12 hour... in file have the value 0E and converted to decimal is 14 min... in file have the value 23 and converted to decimal is 35 and so on... On Fri, Nov 19, 2010 at 4:02 PM, Constantin Iacobescu wrote: > Yes, it's really weird.. actually if I look on debugger I can see that the > strange characters look the same. > Let say what you see in the file is the integer or short interpreted like a > char value. > > Here is attached a basic xml exported from a test app. > I use the latest XSD binary and m working on windows and VS2008 > > The real code I used before discover the error was some like this: > > signed short year = 2010; > signed char month = 12; > signed char day = 12; > signed char month = 12; > > signed char hour = 14; > signed char min = 35; > signed char sec = 42; > > std::auto_ptr objLandXML ( new LandXML(xml_schema::Date(year, > (unsigned short)month, (unsigned short)day), > > > xml_schema::Time((unsigned short)hour, (unsigned short)min, (unsigned > short)sec), > > L"1.2")); > > > And in this way I could see in debugger that the reinterpreted value of > month, day, hour, etc to a char is looking the same like in xml file. > > > > > > > > On Fri, Nov 19, 2010 at 3:44 PM, Boris Kolpackov wrote: > >> Hi Constantin, >> >> Constantin Iacobescu writes: >> >> > And what I get in to the file it is this: >> > [...] >> > date="2010-0 -0 " >> > time="0 :0#:42" >> >> Hm, this is strange. The symbols that you get are probably different >> from what I see in the email because of the mail client conversions. >> Can you create a small but complete test case (schema, driver, and >> makefile/project file) that reproduces this problem (you can use >> one of the examples as a base). Also, which compiler/platform are >> you using? >> >> Boris >> > > > > -- > Constantin Iacobescu > -- Constantin Iacobescu From bschindler at inf.ethz.ch Fri Nov 19 10:58:48 2010 From: bschindler at inf.ethz.ch (Benjamin Schindler) Date: Fri Nov 19 11:01:26 2010 Subject: [xsd-users] Feature request: Explicit constructors In-Reply-To: References: <4CE4F132.9090607@inf.ethz.ch> <4CE5A2A0.1000802@inf.ethz.ch> <4CE6771D.6050507@inf.ethz.ch> Message-ID: <4CE69EB8.9050706@inf.ethz.ch> On 11/19/2010 03:53 PM, Boris Kolpackov wrote: > Hi Benjamin, > > Benjamin Schindler writes: > >> There are a few problems here: >> - the implicit conversion from const char* to std::string is required by >> the standard (I thought) and natural because you're basically converting >> a string to a string > > Correct. > > >> - Converting a string to an enum by implicit conversion is a very >> suspicious operation at best (Is the value defined? If not, exception? >> Error?). If you really want it, make it explicit by calling >> FrameKind("myString") - I'm not trying to disable that. This also makes >> you aware that this constructor might throw etc. I consider this a lot >> more clean tells the developer clearly what's happening. > > You can argue it either way. In your schema you define the enum by > deriving from xsd:string. So this type also "is a" string, just > like std::string (and, in fact, derives from). In C++/Tree string- > based enums have dual interface: you can work with them as with > strings or as C++ enums. Most users find it convenient to be able > to implicitly initialize a enum with a string literal. > I agree that this is convenient. But how many people expect that this could throw? void someFunc(FrameKind kind); someFunc("SomeInvalidEnumerator"); ? I mean seriously, just a function call itself should not throw. And if you only want to allow string constants, I'd suggest removing the std::string constructor. I thought that it is common knowledge that implicit conversions should be discouraged as much as possible - but if you disagree then I'll have to live with that. From boris at codesynthesis.com Mon Nov 22 08:33:41 2010 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon Nov 22 08:26:25 2010 Subject: [xsd-users] xml_schema::Date and xml_schema::Time are wrong serialized on UNICODE files In-Reply-To: References: Message-ID: Hi Constantin, Constantin Iacobescu writes: > If you look in the xml file I have sent to you and look at it in a hex > editor you will see that if you are converting that strange values from > hex to dec you will get the good value of them I have an idea about what might be going on. Some of the values in the xml_schema::date type are of the unsigned short type. If wchar_t is defined as a typedef, then it will most likely be to this type as well. As a result, when you insert unsigned short to std::wostream, it is treated as a character rather than as an integer value. Can you make sure that in your project's properties "C/C++" / "Language" tab the "Treat wchar_t as Built-in Type" property is set to "Yes"? If this doesn't help, then I will still need the minimal test case that reproduces this problem. Right now all I do is guess what might be the problem. Boris From boris at codesynthesis.com Mon Nov 22 08:50:11 2010 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon Nov 22 08:42:55 2010 Subject: [xsd-users] Feature request: Explicit constructors In-Reply-To: <4CE69EB8.9050706@inf.ethz.ch> References: <4CE4F132.9090607@inf.ethz.ch> <4CE5A2A0.1000802@inf.ethz.ch> <4CE6771D.6050507@inf.ethz.ch> <4CE69EB8.9050706@inf.ethz.ch> Message-ID: Hi Benjamin, Benjamin Schindler writes: > Ray proposed to change my constructor to const char*: > > "I would resolve the ambiguity by adding a constructor to MyClass: > MyClass(char const*, double)" He actually didn't propose to change it, he proposed to add another overloaded version (MyClass(char const*, double)) which resolves the ambiguity. In this constructor you can decide what should be initialized with a C-string in MyClass. > I agree that this is convenient. But how many people expect that this > could throw? > > void someFunc(FrameKind kind); > someFunc("SomeInvalidEnumerator"); ? > > I mean seriously, just a function call itself should not throw. And if > you only want to allow string constants, I'd suggest removing the > std::string constructor. > > I thought that it is common knowledge that implicit conversions should > be discouraged as much as possible - but if you disagree then I'll have > to live with that. I think implicit conversion has its uses. In this case, the object, conceptually, "is a" string and initializing it implicitly with another kind of a string seems natural. Yes, it can throw. If you don't want it to throw, then use the C++ enum interface: void someFunc(FrameKind::value kind); someFunc(FrameKind::SomeInvalidEnumerator); // Compile-time error. Boris From sir.costy at gmail.com Mon Nov 22 09:55:22 2010 From: sir.costy at gmail.com (Constantin Iacobescu) Date: Mon Nov 22 09:55:26 2010 Subject: [xsd-users] xml_schema::Date and xml_schema::Time are wrong serialized on UNICODE files In-Reply-To: References: Message-ID: Hello Boris, About this.... Can you make sure that in your project's properties "C/C++" / "Language" > tab the "Treat wchar_t as Built-in Type" property is set to "Yes"? > You have right that this option it is setted to "No" Not sure why but my mates told me that it is like this because of som conflict with other library. So do you think that is no other way to make it work without haveing to change that setting? I am also haveing a custom XercesC compiled, so maybe can be made some on this library, because I think the problem is come from here... ?or not? Thanks, Constantin On Mon, Nov 22, 2010 at 2:33 PM, Boris Kolpackov wrote: > Hi Constantin, > > Constantin Iacobescu writes: > > > If you look in the xml file I have sent to you and look at it in a hex > > editor you will see that if you are converting that strange values from > > hex to dec you will get the good value of them > > I have an idea about what might be going on. Some of the values in > the xml_schema::date type are of the unsigned short type. If wchar_t > is defined as a typedef, then it will most likely be to this type as > well. As a result, when you insert unsigned short to std::wostream, > it is treated as a character rather than as an integer value. > > Can you make sure that in your project's properties "C/C++" / "Language" > tab the "Treat wchar_t as Built-in Type" property is set to "Yes"? > > If this doesn't help, then I will still need the minimal test case > that reproduces this problem. Right now all I do is guess what might > be the problem. > > Boris > -- Constantin Iacobescu From sir.costy at gmail.com Mon Nov 22 10:48:44 2010 From: sir.costy at gmail.com (Constantin Iacobescu) Date: Mon Nov 22 10:48:48 2010 Subject: [xsd-users] xml_schema::Date and xml_schema::Time are wrong serialized on UNICODE files In-Reply-To: References: Message-ID: Hi Boris, About the test project ... > Can you make sure that in your project's properties "C/C++" / "Language" > tab the "Treat wchar_t as Built-in Type" property is set to "Yes"? > > If this doesn't help, then I will still need the minimal test case > that reproduces this problem. Right now all I do is guess what might > be the problem. > Just have finish the test and look to give me the same error on file write. And this only when the "Treat wchar_t as Built-in Type" property is set to "No" I also use a statically compiled lib of XercesC, and this is compiled the same. So there is any way to can work in this case too? If you want I can send you the ptroject but it is a bit bigger for the staticaly xercesc (~22M) Best Regards, Constantin On Mon, Nov 22, 2010 at 2:33 PM, Boris Kolpackov wrote: > Hi Constantin, > > Constantin Iacobescu writes: > > > If you look in the xml file I have sent to you and look at it in a hex > > editor you will see that if you are converting that strange values from > > hex to dec you will get the good value of them > > I have an idea about what might be going on. Some of the values in > the xml_schema::date type are of the unsigned short type. If wchar_t > is defined as a typedef, then it will most likely be to this type as > well. As a result, when you insert unsigned short to std::wostream, > it is treated as a character rather than as an integer value. > > Can you make sure that in your project's properties "C/C++" / "Language" > tab the "Treat wchar_t as Built-in Type" property is set to "Yes"? > > If this doesn't help, then I will still need the minimal test case > that reproduces this problem. Right now all I do is guess what might > be the problem. > > Boris > -- Constantin Iacobescu From boris at codesynthesis.com Mon Nov 22 11:11:54 2010 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon Nov 22 11:04:41 2010 Subject: [xsd-users] xml_schema::Date and xml_schema::Time are wrong serialized on UNICODE files In-Reply-To: References: Message-ID: Hi Constantin, Constantin Iacobescu writes: > Just have finish the test and look to give me the same error on file write. > And this only when the "Treat wchar_t as Built-in Type" property is set to > "No" Ok, so this confirms it. > So there is any way to can work in this case too? The best way is to change wchar_t to be the built-in type. It is what the standard says it should be, it is what Microsoft sets it by default, it is what most other projects use. Perhaps you can rebuild/upgrade/change the library that forced you to set it to "No" in the first place. Or you can try to wrap this library and only compile the wrapper with the "No" setting (you can change it on the file-by-file basis). Other than that, you can go through the libxsd runtime source code and change all short types to int. > If you want I can send you the project No, no need for the test project. I managed to guess what was going on and you confirmed it ;-). Boris From erik.sjolund at gmail.com Tue Nov 23 12:14:28 2010 From: erik.sjolund at gmail.com (=?ISO-8859-1?Q?Erik_Sj=F6lund?=) Date: Tue Nov 23 14:33:32 2010 Subject: [xsd-users] autogenerate graphical user interface (GUI in QT) Message-ID: Hi, Is there any way to autogenerate a graphical user interface (for instance in QT) with CodeSynthesis XSD? By this I mean generating a dialog window where configuration values corresponding to the XML schema.could be filled in. Maybe someone has an idea? cheers, Erik Sj?lund From mjklaim at gmail.com Tue Nov 23 11:53:00 2010 From: mjklaim at gmail.com (Klaim) Date: Tue Nov 23 14:37:52 2010 Subject: [xsd-users] XSD : How to set attributes values in children element type? Message-ID: Hi, I already posted the question some days ago there : http://stackoverflow.com/questions/4199180/xsd-how-to-set-attributes-values-in-children-element-type But I only have one answer and it don't work in the end. :/ Here is a copy-paste of the question : ------------------------------------------------------------------------------------------------- In an xsd file I have this element base type : And I want to define the value of the type attribute in the children types, so I tried this : Visual Studio don't seem to bother but CodeSynthesis C++ code generator don't seem to agree : error: attribute 'type' is already defined in base How should I write this? I just want the value of the type attribute to be specific to each different child type. edit ---- To make the question more clear, I'll write the same thing I want to do but in C++. Here is the base class : class Event { public: std::string name() const { return m_name; } protected: // we need the child class to set the name Event( const std::string& name ) : m_name( name ) {} // it's a base class virtual ~Event(){} private: std::string m_name; }; Now, one of the children could be implemented like this : class Signal : public Event { public: Signal() : Event( "signal" ){} }; As you can see, the child class define the values of attributes that are defined by the base class. Is it even possible to express in xsd? ------------------------------ Now, I think I'm not aware of some things in xsd and that might make me think that this should be possible. If there are xsd experts around, I'd like to know how to achieve something similar? I can't think of any solution and for the moment I'm using a test project to try to make codesynthesis do what I want (to have a common interface with a specific value by child type). I've been stuck on this for a lot of time and can't release my xml-based language without fixing this (or I'll have to totally refactor the way I'm using xsd types). Any idea? Thanks for your time. Klaim aka J. Lamotte From boris at codesynthesis.com Tue Nov 23 14:51:47 2010 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue Nov 23 14:44:34 2010 Subject: [xsd-users] XSD : How to set attributes values in children element type? In-Reply-To: References: Message-ID: Hi Klaim, Klaim writes: > In an xsd file I have this element base type : > > > > > > > And I want to define the value of the type attribute in the children types, > so I tried this : > > > > > > > > > > > Visual Studio don't seem to bother but CodeSynthesis C++ code > generatordon't seem to agree : > > error: attribute 'type' is already defined in base I am pretty sure CodeSynthesis XSD is correct here -- you cannot "extend" a type to have the same attribute as is already defined in the base. > How should I write this? I just want the value of the type attribute to be > specific to each different child type. What you will need is a restriction step: Boris From boris at codesynthesis.com Tue Nov 23 14:56:34 2010 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue Nov 23 14:49:18 2010 Subject: [xsd-users] autogenerate graphical user interface (GUI in QT) In-Reply-To: References: Message-ID: Hi Erik, Erik Sj?lund writes: > Is there any way to autogenerate a graphical user interface (for > instance in QT) with CodeSynthesis XSD? > By this I mean generating a dialog window where configuration values > corresponding to the XML schema.could be filled in. No, there is no way. In the general case this is not a well defined problem (how do you represent nested elements that themselves have elements/attributes? as nested dialogs? how do you capture sequences of such elements? etc). However, for some simple case it should be quite easy to customize the XSD compiler to generate something like this from the schema and maybe even populate the C++/Tree object model with the values provided by the user. Boris From erik.sjolund at gmail.com Tue Nov 23 16:17:55 2010 From: erik.sjolund at gmail.com (=?ISO-8859-1?Q?Erik_Sj=F6lund?=) Date: Tue Nov 23 16:18:04 2010 Subject: [xsd-users] autogenerate graphical user interface (GUI in QT) In-Reply-To: References: Message-ID: On Tue, Nov 23, 2010 at 8:56 PM, Boris Kolpackov wrote: > Hi Erik, > > Erik Sj?lund writes: > >> Is there any way to autogenerate a graphical user interface (for >> instance in QT) with CodeSynthesis XSD? >> By this I mean generating a dialog window where configuration values >> corresponding to the XML schema.could be filled in. > > No, there is no way. In the general case this is not a well defined > problem (how do you represent nested elements that themselves have > elements/attributes? as nested dialogs? how do you capture sequences > of such elements? etc). However, for some simple case it should be > quite easy to customize the XSD compiler to generate something like > this from the schema and maybe even populate the C++/Tree object model > with the values provided by the user. > > Boris > Ok, I see. I was also thinking of the simpler cases, for instance a configuration for some program. One way could possibly be to provide some extensions to the current data object classes. The extensions would not contain any GUI widget knowledge but instead more things like element names as strings, pointers to set- and get-functions. The GUI widget mappings could later be written by using those extensions. cheers, Erik From mjklaim at gmail.com Tue Nov 23 16:34:47 2010 From: mjklaim at gmail.com (Klaim) Date: Tue Nov 23 16:34:56 2010 Subject: [xsd-users] XSD : How to set attributes values in children element type? In-Reply-To: References: Message-ID: Hi, and thanks for your reply! The solution you suggest is the same than the unique answer I got there ? http://stackoverflow.com/questions/4199180/xsd-how-to-set-attributes-values-in-children-element-type If it's that one, then the problem is that both VS and CodeSynthesis agree that the type attribute isn't available in the final type (the one that inherit from the restriction) when you do a restriction step before an extension. Worse : some experiments show be that CodeSynthesis will not generate (in C++) the assignation of the value of the attribute that is defined for exemple in your example in the restriction. Do you know any other way to achieve a similar code than the C++ example I provided to explain what I'm trying to get? The problem I have - to give more context - is that I want to work with an interface in C++ for several subtypes that are defined in the xsd. The xsd inheritance mechanism seems to generate the correct code in C++ but I can't find any way to assign values in xsd code to force properties values depending on the type and still have those values exposed in the base type. If I can't find a solution for this, generating the code will not be as helpful as the generated code don't seem to assign values in properties, only provide accessors. Only the default value in attribute seems to work, but not in the case of restriction. Or maybe I'm doing something wrong? On Tue, Nov 23, 2010 at 20:51, Boris Kolpackov wrote: > Hi Klaim, > > Klaim writes: > > > In an xsd file I have this element base type : > > > > > > > > > > > > > > And I want to define the value of the type attribute in the children > types, > > so I tried this : > > > > > > > > > > > > use="required" /> > > > > > > > > > > Visual Studio don't seem to bother but CodeSynthesis C++ code > > generatordon't seem to agree : > > > > error: attribute 'type' is already defined in base > > I am pretty sure CodeSynthesis XSD is correct here -- you cannot "extend" > a type to have the same attribute as is already defined in the base. > > > > How should I write this? I just want the value of the type attribute to > be > > specific to each different child type. > > What you will need is a restriction step: > > > > > > > > > > > > > > /> > > > > > Boris > From boris at codesynthesis.com Wed Nov 24 09:50:30 2010 From: boris at codesynthesis.com (Boris Kolpackov) Date: Wed Nov 24 09:43:15 2010 Subject: [xsd-users] autogenerate graphical user interface (GUI in QT) In-Reply-To: References: Message-ID: Hi Erik, Erik Sj?lund writes: > One way could possibly be to provide some extensions to the current > data object classes. The extensions would not contain any GUI widget > knowledge but instead more things like element names as strings, > pointers to set- and get-functions. The GUI widget mappings could > later be written by using those extensions. We are planning to add (optional) "dynamic introspection" API to the object model for the next release. The primary use will be XPath and XQuery support but it will also allow you to do the above. However, I am not sure how many GUI frameworks allow such a dynamic dialog construction. Usually there is some compilation process involved. Boris From boris at codesynthesis.com Wed Nov 24 10:05:59 2010 From: boris at codesynthesis.com (Boris Kolpackov) Date: Wed Nov 24 09:58:43 2010 Subject: [xsd-users] XSD : How to set attributes values in children element type? In-Reply-To: References: Message-ID: Hi Klaim, Klaim writes: > The solution you suggest is the same than the unique answer I got there ? Yes, the same as the "restriction then extension" solution. > If it's that one, then the problem is that both VS and CodeSynthesis agree > that the type attribute isn't available in the final type (the one that > inherit from the restriction) when you do a restriction step before an > extension. What do you mean by "not available"? The attribute is there, it is just restricted to a specific value. > Worse : some experiments show be that CodeSynthesis will not generate (in > C++) the assignation of the value of the attribute that is defined for > exemple in your example in the restriction. Yes, that's partly true. Since there is no equivalent to "inheritance by restriction" in C++, the generated code simply makes the derived type pretty much the same as the base, leaving it for the underlying parser to enforce the restriction. As a result, if you get the object model from parsing an XML document and validation is enabled, you will get the correct attribute value set. However, if you construct the object model programmatically in your application, then you will need to set the attribute value manually. > Do you know any other way to achieve a similar code than the C++ example I > provided to explain what I'm trying to get? You could customize the generated classes slightly to set the "fixed" values automatically. I.e., derive from the generated version and in the constructors, set the values corresponding to the kind of instance. For more information on type customization 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 mjklaim at gmail.com Wed Nov 24 11:19:43 2010 From: mjklaim at gmail.com (Klaim) Date: Wed Nov 24 11:19:50 2010 Subject: [xsd-users] XSD : How to set attributes values in children element type? In-Reply-To: References: Message-ID: If I understand correctly, if I use the restriction+extension pattern AND use fixed="the_value_I_want" in the restriction AND uses the xsd file for validation when parsing using the xsd-tree code generated by this tool, then "the_value_I_want" will be taken from the xsd (instead of the code) and set in the instantiated object? It that works, then my problem is solved because I need validation. I'll check this once home. On Wed, Nov 24, 2010 at 16:05, Boris Kolpackov wrote: > Hi Klaim, > > Klaim writes: > > > The solution you suggest is the same than the unique answer I got there ? > > Yes, the same as the "restriction then extension" solution. > > > If it's that one, then the problem is that both VS and CodeSynthesis > agree > > that the type attribute isn't available in the final type (the one that > > inherit from the restriction) when you do a restriction step before an > > extension. > > What do you mean by "not available"? The attribute is there, it is just > restricted to a specific value. > > > > Worse : some experiments show be that CodeSynthesis will not generate (in > > C++) the assignation of the value of the attribute that is defined for > > exemple in your example in the restriction. > > Yes, that's partly true. Since there is no equivalent to "inheritance by > restriction" in C++, the generated code simply makes the derived type > pretty much the same as the base, leaving it for the underlying parser > to enforce the restriction. As a result, if you get the object model > from parsing an XML document and validation is enabled, you will get > the correct attribute value set. However, if you construct the object > model programmatically in your application, then you will need to > set the attribute value manually. > > > > Do you know any other way to achieve a similar code than the C++ example > I > > provided to explain what I'm trying to get? > > You could customize the generated classes slightly to set the "fixed" > values automatically. I.e., derive from the generated version and > in the constructors, set the values corresponding to the kind of > instance. For more information on type customization 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 mjklaim at gmail.com Wed Nov 24 16:35:22 2010 From: mjklaim at gmail.com (Klaim) Date: Wed Nov 24 16:35:25 2010 Subject: [xsd-users] XSD : How to set attributes values in children element type? In-Reply-To: References: Message-ID: Thanks, it seems to work as you said! I still have other problems with the generated code but at least I got the whole thing correct. I'll send separate threads about the different problems I got. On Wed, Nov 24, 2010 at 17:19, Klaim wrote: > If I understand correctly, if I use the restriction+extension pattern AND > use fixed="the_value_I_want" in the restriction AND uses the xsd file for > validation when parsing using the xsd-tree code generated by this tool, then > "the_value_I_want" will be taken from the xsd (instead of the code) and set > in the instantiated object? > > It that works, then my problem is solved because I need validation. I'll > check this once home. > > > On Wed, Nov 24, 2010 at 16:05, Boris Kolpackov wrote: > >> Hi Klaim, >> >> Klaim writes: >> >> > The solution you suggest is the same than the unique answer I got there >> ? >> >> Yes, the same as the "restriction then extension" solution. >> >> > If it's that one, then the problem is that both VS and CodeSynthesis >> agree >> > that the type attribute isn't available in the final type (the one that >> > inherit from the restriction) when you do a restriction step before an >> > extension. >> >> What do you mean by "not available"? The attribute is there, it is just >> restricted to a specific value. >> >> >> > Worse : some experiments show be that CodeSynthesis will not generate >> (in >> > C++) the assignation of the value of the attribute that is defined for >> > exemple in your example in the restriction. >> >> Yes, that's partly true. Since there is no equivalent to "inheritance by >> restriction" in C++, the generated code simply makes the derived type >> pretty much the same as the base, leaving it for the underlying parser >> to enforce the restriction. As a result, if you get the object model >> from parsing an XML document and validation is enabled, you will get >> the correct attribute value set. However, if you construct the object >> model programmatically in your application, then you will need to >> set the attribute value manually. >> >> >> > Do you know any other way to achieve a similar code than the C++ example >> I >> > provided to explain what I'm trying to get? >> >> You could customize the generated classes slightly to set the "fixed" >> values automatically. I.e., derive from the generated version and >> in the constructors, set the values corresponding to the kind of >> instance. For more information on type customization 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 fschmidt at techfak.uni-bielefeld.de Thu Nov 25 10:12:25 2010 From: fschmidt at techfak.uni-bielefeld.de (Florian Schmidt) Date: Thu Nov 25 10:12:34 2010 Subject: [xsd-users] autogenerate graphical user interface (GUI in QT) In-Reply-To: References: Message-ID: <4CEE7CD9.1070308@techfak.uni-bielefeld.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/24/2010 03:50 PM, Boris Kolpackov wrote: > Hi Erik, > > Erik Sj?lund writes: > >> One way could possibly be to provide some extensions to the current >> data object classes. The extensions would not contain any GUI widget >> knowledge but instead more things like element names as strings, >> pointers to set- and get-functions. The GUI widget mappings could >> later be written by using those extensions. > > We are planning to add (optional) "dynamic introspection" API to the > object model for the next release. The primary use will be XPath and > XQuery support but it will also allow you to do the above. However, > I am not sure how many GUI frameworks allow such a dynamic dialog > construction. Usually there is some compilation process involved. Hi, i actually once started to write a small GUI tool for creating valid instance documents from a given schema. I used python (and bindings generated from PyxB) for this though as it allows for very dynamic introspection. I didn't get far due to time constraints [i have to hack robot control code instead ;D] but in principle i think it is possible to generate a GUI application that allows authoring of instance documents from a schema and i also think that the magic of generating bindings can help make this process easier.. The natural representation of an instance document is a tree, so that was the route i was going down. I actually considered asking for something like introspection into the model for XSD before, too, but i figured that other languages are much more suited for this kind of dynamic stuff.. Regards, Flo - -- Dipl.-Inform. Florian Paul Schmidt University of Bielefeld, Neuroinformatics Group, CITEC Contact: http://ekvv.uni-bielefeld.de/pers_publ/publ/personDetailAct?id=5504453 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkzufNYACgkQTb4s+qNo4RJJKgCeP/gflEJWfD0FxGlMIudQKeEB PiUAoLI18UHm3DvwPWRpIHnHHjhLShcq =16oT -----END PGP SIGNATURE----- From adrien.chauve at gmail.com Sun Nov 28 15:47:03 2010 From: adrien.chauve at gmail.com (Adrien Chauve) Date: Mon Nov 29 08:27:02 2010 Subject: [xsd-users] Error while compiling generated code with clang Message-ID: Hi, I tried to compile generated code with clang and got an error. It seems that there is an unqualified call to setg in zc-istream.txx (line 35). setg (b, b, e); ====> this->setg(b, b, e); By the way, I noticed clang is not one of the supported compilers. Do you plan to support it in the near future? Thanks very much, Adrien From boris at codesynthesis.com Mon Nov 29 09:25:10 2010 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon Nov 29 09:18:03 2010 Subject: [xsd-users] Error while compiling generated code with clang In-Reply-To: References: Message-ID: Hi Adrien, Adrien Chauve writes: > I tried to compile generated code with clang and got an error. It seems that > there is an unqualified call to setg in zc-istream.txx (line 35). > > setg (b, b, e); ====> this->setg(b, b, e); Hm, the arguments in this call are template parameter-dependent, so I am not sure why clang complains. None of the other supported C++ compilers do. Might be a bug in clang or it is being super pedantic. > By the way, I noticed clang is not one of the supported compilers. Do you > plan to support it in the near future? Yes, sure. I just tried to build XSD examples with cland 2.7 (the latest release available in Debian unstable) but got "cannot compile this decl yet" kind of errors. I see that 2.8 is the latest release but it is not yet packaged for Debian. Which version are you using? Boris From adrien.chauve at gmail.com Mon Nov 29 15:59:17 2010 From: adrien.chauve at gmail.com (Adrien Chauve) Date: Tue Nov 30 09:54:40 2010 Subject: [xsd-users] Error while compiling generated code with clang In-Reply-To: References: Message-ID: Hi Boris, Thank you for your answer. On Mon, Nov 29, 2010 at 15:25, Boris Kolpackov wrote: > > Hm, the arguments in this call are template parameter-dependent, so I am > not sure why clang complains. None of the other supported C++ compilers > do. Might be a bug in clang or it is being super pedantic. > > Yes, you're completely right. I forgot this trick. However, clang insists on it, giving this additional note: /usr/include/c++/4.4/streambuf:484:7: note: must qualify identifier to find this declaration in dependent base class setg(char_type* __gbeg, char_type* __gnext, char_type* __gend) What's curious is that clang doesn't complain with the following code: template struct Base { void foo(int) {} }; template struct Derived : Base { void bar() { this->foo(2); } void foobar() { T c; foo(c); } }; I'm going to ask in clang mailing list. > > > By the way, I noticed clang is not one of the supported compilers. Do you > > plan to support it in the near future? > > Yes, sure. I just tried to build XSD examples with cland 2.7 (the latest > release available in Debian unstable) but got "cannot compile this decl > yet" kind of errors. I see that 2.8 is the latest release but it is not > yet packaged for Debian. Which version are you using? > Indeed, I am using clang 2.8. Adrien From boris at codesynthesis.com Tue Nov 30 11:58:31 2010 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue Nov 30 11:51:01 2010 Subject: [xsd-users] Error while compiling generated code with clang In-Reply-To: References: Message-ID: Hi Adrien, Adrien Chauve writes: > I'm going to ask in clang mailing list. Great, let us know what they say. > Indeed, I am using clang 2.8. Ok, I've installed 2.8 and I see the same error. Plus there are more cases like this in the C++/Parser mapping. Boris From mjklaim at gmail.com Tue Nov 30 12:04:01 2010 From: mjklaim at gmail.com (Klaim) Date: Tue Nov 30 12:04:20 2010 Subject: [xsd-users] Error while compiling generated code with clang In-Reply-To: References: Message-ID: Just for information, the stable 2.8 version is more buggy on the C++ side than the trunk version (it seems). On Tue, Nov 30, 2010 at 17:58, Boris Kolpackov wrote: > Hi Adrien, > > Adrien Chauve writes: > > > I'm going to ask in clang mailing list. > > Great, let us know what they say. > > > > Indeed, I am using clang 2.8. > > Ok, I've installed 2.8 and I see the same error. Plus there are more > cases like this in the C++/Parser mapping. > > Boris > >