From kroiz at hyperroll.com Sun Apr 1 09:41:45 2007 From: kroiz at hyperroll.com (Guy Kroizman) Date: Sun Oct 11 15:33:55 2009 Subject: [xsd-users] redefinition error Message-ID: Hi, How can I make all the generated code be in its own namespace? From boris at codesynthesis.com Sun Apr 1 09:59:13 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:55 2009 Subject: [xsd-users] redefinition error In-Reply-To: References: Message-ID: <20070401135913.GA30987@karelia> Hi Guy, Guy Kroizman writes: > How can I make all the generated code be in its own namespace? Use the --namespace-map option. If your schema does not have a target namespace, you can still use this option with empty string indicating XML Schema namespace, e.g., --namespace-map =my_namespace Will generate code for no-namespace schemas in my_namespace C++ namespace. For more information about this option see the XSD compiler manual: http://www.codesynthesis.com/projects/xsd/documentation/xsd.xhtml hth, -boris -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 652 bytes Desc: Digital signature Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20070401/c6a8339f/attachment.pgp From kroiz at hyperroll.com Mon Apr 2 05:19:53 2007 From: kroiz at hyperroll.com (Guy Kroizman) Date: Sun Oct 11 15:33:55 2009 Subject: [xsd-users] redefinition error In-Reply-To: <20070401135913.GA30987@karelia> References: <20070401135913.GA30987@karelia> Message-ID: Thanks, that works great. On 4/1/07, Boris Kolpackov wrote: > > Hi Guy, > > Guy Kroizman writes: > > > How can I make all the generated code be in its own namespace? > > Use the --namespace-map option. If your schema does not have a > target namespace, you can still use this option with empty string > indicating XML Schema namespace, e.g., > > --namespace-map =my_namespace > > Will generate code for no-namespace schemas in my_namespace C++ > namespace. For more information about this option see the XSD > compiler manual: > > http://www.codesynthesis.com/projects/xsd/documentation/xsd.xhtml > > hth, > -boris > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.5 (GNU/Linux) > > iQGVAwUBRg+6sciAKQuuCE8dAQLyLAv/cyiftY9TFJYVx7KUF7v0KcW1v0m0wdYb > zUch4Lx2m0/789X5LXly5Blj/aokm8q4EdiGFoEhd1HRrIxNWz945VgF+dI7lJk1 > pKnNr+tJz/fFFGk9RIMa0QZer9wVP5Yq9Oqk9MjehRRh84cy6fACHZEi9tDUJ3R1 > PwmEIq7HpdW3e+O4562NWH4qFdusq1We4DWKW4SJjfg9pcDtBDf/MlWYYQVtb8mR > ujnmBwBCSls3B0kaxWsqxPM2uXLxAXhPS+BpqJ31Mah0bT1pXkgVZpPUTTV1lZ24 > U3jKMpZDgLa5yBtMfL1bCedKqMoI9fXODbx4ajMov6rv9PmocF/WNfyQSMjIlwVa > tDdnXH2YIs6zYEy2CvUYmAvvU9e3Yj7jm9EIEHj2QCFbT38Y5NQYmp4FHNKUXvbJ > Z8RH+quWQaNQfkRiwv93rKt/B0yQo7ai7P9lwMNlWEvxsPsJJwP/deqUFIapYVFA > /iuafrMYYGUzI1Hw9FEp3J9jkVkTTcny > =JIQl > -----END PGP SIGNATURE----- > > -- Q: What do agnostic, insomniac dyslexics do at night? A: Stay awake and wonder if there's a dog. From boris at codesynthesis.com Mon Apr 2 08:31:01 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:55 2009 Subject: [xsd-users] New idea for stream insertion & extraction In-Reply-To: References: <20070330170615.GC25761@karelia> <20070330204533.GB26301@karelia> Message-ID: <20070402123101.GA1376@karelia> Hi Ray, I've CC'ed xsd-users to my reply in case others are interested in this. Ray Lischner writes: > > I think the right approach here is to implement custom stream > > support in the generated code. For your BME format it should be > > trivial to do, especially now when I moved all the serialization > > logic from optional and sequence containers to the generated > > code. Furthermore, I think, you can reuse all the stream insertion > > and extraction infrastructure for built-in types so that you > > do not need to change anything in libxsd. Let me know if you > > are interested in this approach and I will give you a more > > detailed guidelines on what needs to be done. > > I'm very interested. The actual code is generated in the following files (all in xsd/cxx/tree) insertion stream-insertion-header.?xx stream-insertion-source.?xx extraction tree-header.cxx stream-extraction-source.?xx Note that for extraction, the declarations are generated in tree-header.cxx since for extraction we use constructors and they have to be generated in class definitions. To generate your own insertion/extraction operators/c-tors you would probably want to copy the above files (except tree-header.cxx where you will just add your code inline). The code generation is pretty simple. There are four "type" traversers: List, Union, Enumeration and Complex. For Complex there are also Element and Attribute traversers that each have cases for one, optional and sequence cardinality classes. Things are a bit complicated by the presence of the polymorphic case. What you may want to do is to implement non-polymorphic case first and then add support for polymorphism later. In the tree-header.cxx file you only need to touch List, Union, Enumeration and Complex where you add declaration of your extraction c-tors. Once you've done all this, you will need to call the generators as well as generate #include directives etc. To find all the places where you may need to add your code simply search for generate_insertion and generate_extraction in xsd/cxx/tree. You can either add a command line option for your own streams or, if you need to always generate them, simply call generators unconditionally. Finally, you will need to provide ostream/istream specializations for your stream types, similar to what is found in the ace-cdr-* files in libxsd. I believe you already know how to do that. hth, -boris -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 652 bytes Desc: Digital signature Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20070402/763f85f6/attachment.pgp From kroiz at hyperroll.com Wed Apr 4 02:00:46 2007 From: kroiz at hyperroll.com (Guy Kroizman) Date: Sun Oct 11 15:33:55 2009 Subject: [xsd-users] use of auto_ptr Message-ID: I noticed all the function that create my main object return auto_ptr. what if I want to construct an object that is not bound to the scope in which it is created? I know I can release the object from the auto_ptr. but it seemed strange to me so I thought I might be missing something. From boris at codesynthesis.com Wed Apr 4 04:24:00 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:55 2009 Subject: [xsd-users] use of auto_ptr In-Reply-To: References: Message-ID: <20070404082400.GA6777@karelia> Hi Guy, Guy Kroizman writes: > I noticed all the function that create my main object return auto_ptr. > what if I want to construct an object that is not bound to the scope in > which it is created? The object is dynamically allocated exactly to allow it to survive beyond the current scope if needed. The alternative to returning it inside auto_ptr is to return a naked pointer but this is not exception-safe. As you said, you can always detach the underlying pointer from auto_ptr (with the release() call) and store it anywhere you want (e.g., in boost shared_ptr or as a member of a class). We use auto_ptr because it is available as part of the standard C++ library and doesn't require any external dependencies. hth, -boris -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 652 bytes Desc: Digital signature Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20070404/2f6831fe/attachment.pgp From boris at codesynthesis.com Wed Apr 4 05:02:56 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:55 2009 Subject: [xsd-users] use of auto_ptr In-Reply-To: References: <20070404082400.GA6777@karelia> Message-ID: <20070404090256.GB6777@karelia> Hi Guy, Guy Kroizman writes: I've CC'ed xsd-users to my reply. Please do the same in your future posts. > I would prefer to get a naked pointer and deciding my self how to > handle it. If we always returned naked pointers then it would be impossible to write exception-safe code using XSD. Because it is a common consensus that exception-safe code is a good thing, we cannot make this change just to satisfy a minority that does not care about exception safety. After all, it is just an extra call to release() to get rid of auto_ptr: foo_t* f = foo ("foo.xml").release (); [The rest of the original post follows for context.] > but I also understand the design consideration that since I did not > do "new" I could forget to delete it. > and by using auto_ptr I am receiving explicit ownership. > anyway thanks for the explanation. hth, -boris -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 652 bytes Desc: Digital signature Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20070404/e7e838c2/attachment.pgp From kroiz at hyperroll.com Wed Apr 4 05:59:33 2007 From: kroiz at hyperroll.com (Guy Kroizman) Date: Sun Oct 11 15:33:55 2009 Subject: [xsd-users] use of auto_ptr In-Reply-To: <20070404090256.GB6777@karelia> References: <20070404082400.GA6777@karelia> <20070404090256.GB6777@karelia> Message-ID: why is it impossible to write exception-safe code using naked pointers? As you suggested before, I could keep the naked pointer as a member in a class the will destroy it in the destructor. that is exception-safe. right? On 4/4/07, Boris Kolpackov wrote: > > Hi Guy, > > Guy Kroizman writes: > > I've CC'ed xsd-users to my reply. Please do the same in your future > posts. > > > I would prefer to get a naked pointer and deciding my self how to > > handle it. > > If we always returned naked pointers then it would be impossible to > write exception-safe code using XSD. Because it is a common consensus > that exception-safe code is a good thing, we cannot make this change > just to satisfy a minority that does not care about exception safety. > > After all, it is just an extra call to release() to get rid of auto_ptr: > > foo_t* f = foo ("foo.xml").release (); > > > [The rest of the original post follows for context.] > > > but I also understand the design consideration that since I did not > > do "new" I could forget to delete it. > > and by using auto_ptr I am receiving explicit ownership. > > anyway thanks for the explanation. > > > hth, > -boris > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.5 (GNU/Linux) > > iQGVAwUBRhNpwMiAKQuuCE8dAQKr6Av8C0H5J5SfBkDmclsuuv05pFxgQN8VUhhg > qyvZNEh3NtsVx1QUHyjlkZOJFrLNSBtd3HWlifEm3VPYkg0DP6vLLHAT9mKMjIBq > wTgI0YJMZj/e16swNbUJX5G/CYReC6/qunF6Q/kkEiUpaoI5tEqxtloAgexqtoqe > 1TI3Go2Y75AQ2WU0E6lLZusDVSfzA9oamb44XVq0AWBLxrTESfagER5qQjOihzwt > K5aBu8WzbEC+X+0iPLALkzQVY3PAOJwfdR6y2N3+SLbBDkT68O8mHLQMbg9/4VC9 > n91pssoLvEGFBpaEyIf+Cptswgdl73y5Tfa+Ow5jeg7vMazTZ7ctrmiX7RyEww+Q > lrpzBp6fhwaEo2m+6QkGcjSPn263KxGo++bIFYL1Sx7K2HCixr3vnqfi4s9Gsa3L > 9+jcvt88nmWzdCGp5Uo6SL8YHT/pW25YmCWRButtYuco4pQ1QQWhkMjXLs9TuJS+ > 29mK4dpPzan7S2GRUEUhq0nLnpRDTMbK > =fI21 > -----END PGP SIGNATURE----- > > -- Q: What do agnostic, insomniac dyslexics do at night? A: Stay awake and wonder if there's a dog. From boris at codesynthesis.com Wed Apr 4 06:16:20 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:55 2009 Subject: [xsd-users] use of auto_ptr In-Reply-To: References: <20070404082400.GA6777@karelia> <20070404090256.GB6777@karelia> Message-ID: <20070404101620.GC6777@karelia> Hi Guy, Guy Kroizman writes: > why is it impossible to write exception-safe code using naked pointers? This is a complicated issue. In a few words it has to do with the possibility of an exception being thrown while nobody "own" the naked pointer. The two situations in this case are: (1) One of the argument's destructor could throw. For example, assuming foo() returns a dynamically allocated object as a naked pointer: foo_t* f = foo ("foo.xml", 0 , xml_schema::properties ()); Here if the temporary for the third argument throws during destruction the object will be leaked. This situation is somewhat far-fetched because destructors normally do not throw. (2) The second situation is a lot more real. Suppose you have a function that takes two arguments: class bar_t {...}; void f (foo_t*, const bar_t&); And you do something like this: f (foo ("foo.xml"), bar ()); The C++ standard does not specify the order in which arguments are evaluated. So it is possible that foo("foo.xml") will be called first and bar() second. If bar's constructor throws, then the object returned by foo() is leaked. > As you suggested before, I could keep the naked pointer as a member in a > class the will destroy it in the destructor. > that is exception-safe. right? It can be made exception-safe but it is a lot of work if you keep naked pointers around. It is easier to make each member clean-up after itself automatically by using smart pointers. For more on this see, for example, this C++ FAQ entry: http://www.parashift.com/c++-faq-lite/exceptions.html#faq-17.4 hth, -boris -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 652 bytes Desc: Digital signature Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20070404/e226d5b9/attachment.pgp From kroiz at hyperroll.com Wed Apr 4 07:20:57 2007 From: kroiz at hyperroll.com (Guy Kroizman) Date: Sun Oct 11 15:33:55 2009 Subject: [xsd-users] use of auto_ptr In-Reply-To: <20070404101620.GC6777@karelia> References: <20070404082400.GA6777@karelia> <20070404090256.GB6777@karelia> <20070404101620.GC6777@karelia> Message-ID: still, it is not impossible to write exception-safe. hard maybe but not impossible. after all I think most programers, will take ownership of the naked pointer. so they will have to. I also dont argue with this decision. I now understand it better. I just was not familliar with auto_ptr. thanks again. On 4/4/07, Boris Kolpackov wrote: > > Hi Guy, > > Guy Kroizman writes: > > > why is it impossible to write exception-safe code using naked pointers? > > This is a complicated issue. In a few words it has to do with the > possibility of an exception being thrown while nobody "own" the > naked pointer. The two situations in this case are: > > (1) One of the argument's destructor could throw. For example, assuming > foo() returns a dynamically allocated object as a naked pointer: > > foo_t* f = foo ("foo.xml", 0 , xml_schema::properties ()); > > Here if the temporary for the third argument throws during destruction > the object will be leaked. This situation is somewhat far-fetched > because destructors normally do not throw. > > (2) The second situation is a lot more real. Suppose you have a > function that takes two arguments: > > class bar_t {...}; > void f (foo_t*, const bar_t&); > > And you do something like this: > > f (foo ("foo.xml"), bar ()); > > The C++ standard does not specify the order in which arguments > are evaluated. So it is possible that foo("foo.xml") will be > called first and bar() second. If bar's constructor throws, > then the object returned by foo() is leaked. > > > > As you suggested before, I could keep the naked pointer as a member in a > > class the will destroy it in the destructor. > > that is exception-safe. right? > > It can be made exception-safe but it is a lot of work if you keep naked > pointers around. It is easier to make each member clean-up after itself > automatically by using smart pointers. For more on this see, for example, > this C++ FAQ entry: > > http://www.parashift.com/c++-faq-lite/exceptions.html#faq-17.4 > > > hth, > -boris > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.5 (GNU/Linux) > > iQGVAwUBRhN69MiAKQuuCE8dAQJGYQv+MsZNIq81igWWm6WA+yp/HJo1uTUnJ0F0 > qHXEjBzxd7f6JQ4kDtcKdHltdqQT28pWeXpqG1g3lxHNC16xVy/o3yWkbgcfYLbU > FJunMWBEIz1/KAWICp15FC4nVuypMXy2eJg4btzdejFFDqV1sBdIjqcOQ4oMJfkt > Ky9f7lFpWUmQOavHZGSVsAKdjTndLfekVeUytaOebireiVX7zYNVwYgi9iciS1+o > SPoteSfVFEVMmX3jdgUmU+zqJreLWbbycy2surRSDz+8hAoAPA1e91H/xOE5Ibw9 > dpF5xkHLp9mWjAVze6NYRFuJBOLCOlGQAV6irDr6miwi86/fOfSKdtVZHpLbcERH > cPejnlFmGht5dl2PH2idGYp6kSwC6XipnCLOvbroX9sHGbecvBBoKD1w4bDCjnhx > 6v5F4hW+uwzmybOmLwm/4nMRZrnu2A9fbICNY1ZSj5WmUNso2JPTgRbmCRIVgt36 > KGc6i1KioZ+1fOr1gC8AC0mTfoJORwH+ > =WXWg > -----END PGP SIGNATURE----- > > -- Q: What do agnostic, insomniac dyslexics do at night? A: Stay awake and wonder if there's a dog. From boris at codesynthesis.com Wed Apr 4 08:04:42 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:55 2009 Subject: [xsd-users] use of auto_ptr In-Reply-To: References: <20070404082400.GA6777@karelia> <20070404090256.GB6777@karelia> <20070404101620.GC6777@karelia> Message-ID: <20070404120442.GA7490@karelia> Hi Guy, Guy Kroizman writes: > still, it is not impossible to write exception-safe. hard maybe but not > impossible. Without throwing destructors (which is almost always the case), I agree, "impossible" is a bit to strong a word. Let's say returning naked pointers makes it easy to accidently write exception-unsafe and/or leaky code. -boris -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 652 bytes Desc: Digital signature Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20070404/bd8be54e/attachment.pgp From gerard at lanois.com Thu Apr 5 17:21:43 2007 From: gerard at lanois.com (Gerard Lanois) Date: Sun Oct 11 15:33:55 2009 Subject: [xsd-users] fatal error C1046: compiler limit : struct nested too deeply Message-ID: <5a454940704051421p1f204ee9g58109bb2b83a5e17@mail.gmail.com> I have a fairly deep document structure. Apparently too deep for Microsoft Visual C++ .NET 2003, according to the above error message. I've searched the FAQ, Wiki, mailing list, and online documentation - I can't find any reference to this. I thought I remembered this being discussed on the mailing list last year some time. Anyway, is there a way to tell the xsd tool not to nest the structures as it generates the .hxx/.cxx? (to "flatten" the schema?) The schema I am working with was provided to me by a third party, and editing it directly is not an option. Thanks, -Gerard From boris at codesynthesis.com Fri Apr 6 07:18:38 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:55 2009 Subject: [xsd-users] fatal error C1046: compiler limit : struct nested too deeply In-Reply-To: <5a454940704051421p1f204ee9g58109bb2b83a5e17@mail.gmail.com> References: <5a454940704051421p1f204ee9g58109bb2b83a5e17@mail.gmail.com> Message-ID: <20070406111838.GA12670@karelia> Hi Gerard, Gerard Lanois writes: > Anyway, is there a way to tell the xsd tool not to nest the structures as it > generates the .hxx/.cxx? (to "flatten" the schema?) There is the --morph-anonymous option which names all anonymous types and as a result reduces nesting to the maximum of 3 levels. If this does not help then it would be great if you could post the part of the generated code (along with the surrounding code all the way to the namespace scope) that triggers the error. thanks, -boris -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 652 bytes Desc: Digital signature Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20070406/ca0663d2/attachment.pgp From rlischner at proteus-technologies.com Fri Apr 6 11:54:43 2007 From: rlischner at proteus-technologies.com (Ray Lischner) Date: Sun Oct 11 15:33:55 2009 Subject: [xsd-users] bug in cxx/tree/stream-extraction.hxx Message-ID: Extracting a sequence of fundamental values doesn't work because as_size needs to be an lvalue, not an rvalue. Change line 115 of cxx/tree/stream-extraction.hxx to use a variable, as is done for the non-fundamental-type case, earlier in the file. -- Ray Lischner, Proteus Technologies From boris at codesynthesis.com Fri Apr 6 12:38:25 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:55 2009 Subject: [xsd-users] bug in cxx/tree/stream-extraction.hxx In-Reply-To: References: Message-ID: <20070406163825.GE12670@karelia> Hi Ray, Ray Lischner writes: > Extracting a sequence of fundamental values doesn't work because > as_size needs to be an lvalue, not an rvalue. Change line 115 of > cxx/tree/stream-extraction.hxx to use a variable, as is done for > the non-fundamental-type case, earlier in the file. I've already spotted and fixed this in the 3.0.0 code base. Anyway, thanks for reporting this! -boris -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 652 bytes Desc: Digital signature Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20070406/3be8b560/attachment.pgp From gerard at lanois.com Mon Apr 9 13:43:23 2007 From: gerard at lanois.com (Gerard Lanois) Date: Sun Oct 11 15:33:55 2009 Subject: [xsd-users] Having trouble with NMTOKENS Message-ID: <5a454940704091043g10b25e04wc3d456930a486335@mail.gmail.com> Here is my schema .xsd file: Characters from the Simpsons. This works fine. However, if I change the NMTOKEN to be NMTOKENS (note the "S" at the end), the resulting .cxx file does not compile. I produced the .cxx by just running xsd on the above schema (called BlahSchema.xsd) with no command line options. Is NMTOKENS working as expected? It seems to be supported. Thanks, -Gerard PS: Here are the compilation errors I get: Compiling... BlahSchema.cxx c:\users\gerard\ReadBLAH\BlahSchema.cxx(49) : error C2664: 'xsd::cxx::tree::nmtokens::nmtokens(const xercesc_2_7::DOMElement &,xsd::cxx::tree::flags,xsd::cxx::tree::type *)' : cannot convert parameter 1 from 'const char *const ' to 'const xercesc_2_7::DOMElement &' with [ C=char, B=xml_schema::simple_type, nmtoken=xml_schema::nmtoken ] Reason: cannot convert from 'const char *const ' to 'const xercesc_2_7::DOMElement' No constructor could take the source type, or constructor overload resolution was ambiguous c:\users\gerard\ReadBLAH\BlahSchema.cxx(70) : error C2440: 'type cast' : cannot convert from 'const char *const ' to 'xsd::cxx::tree::nmtokens' with [ C=char, B=xml_schema::simple_type, nmtoken=xml_schema::nmtoken ] No constructor could take the source type, or constructor overload resolution was ambiguous c:\users\gerard\ReadBLAH\BlahSchema.cxx(155) : error C2679: binary '!=' : no operator found which takes a right-hand operand of type 'const SIMPSONS_TYPE' (or there is no acceptable conversion) c:\users\gerard\ReadBLAH\BlahSchema.cxx(157) : error C2440: 'type cast' : cannot convert from 'const SIMPSONS_TYPE' to 'xsd::cxx::tree::unexpected_enumerator' with [ C=char ] No constructor could take the source type, or constructor overload resolution was ambiguous From boris at codesynthesis.com Mon Apr 9 14:00:34 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:55 2009 Subject: [xsd-users] Having trouble with NMTOKENS In-Reply-To: <5a454940704091043g10b25e04wc3d456930a486335@mail.gmail.com> References: <5a454940704091043g10b25e04wc3d456930a486335@mail.gmail.com> Message-ID: <20070409180034.GA22568@karelia> Hi Gerard, Gerard Lanois writes: > However, if I change the NMTOKEN to be NMTOKENS > (note the "S" at the end), the resulting .cxx file does not compile. That's a bug. I've fixed it for the next release. If you would like, I can send you a pre-release binary with this fix. Also note that using NMTOKENS as a base for this enumeration does not make much sense. NMTOKENS is a list (space-separated) of NMTOKEN. Also the generated code for the two will be quite different. The NMTOKEN based type will have nice C++ enum translation while the NMTOKENS-based case will be translated to simple derivation. hth, -boris -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 652 bytes Desc: Digital signature Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20070409/790fb7b7/attachment.pgp From gerard at lanois.com Mon Apr 9 14:37:51 2007 From: gerard at lanois.com (Gerard Lanois) Date: Sun Oct 11 15:33:55 2009 Subject: [xsd-users] Having trouble with NMTOKENS In-Reply-To: <20070409180034.GA22568@karelia> References: <5a454940704091043g10b25e04wc3d456930a486335@mail.gmail.com> <20070409180034.GA22568@karelia> Message-ID: <5a454940704091137t5a0fde4as34cb1ed26b4b2977@mail.gmail.com> I would greatly appreciate if you could send me a pre-release binary with the fix. I am in complete agreement with your second paragraph. This was a contrived example just to demonstrate the problem. My "real" schema is big and complicated, and has more appropriate usage of NMTOKENS. Thanks for your help! -Gerard On 4/9/07, Boris Kolpackov wrote: > Hi Gerard, > > Gerard Lanois writes: > > > However, if I change the NMTOKEN to be NMTOKENS > > (note the "S" at the end), the resulting .cxx file does not compile. > > That's a bug. I've fixed it for the next release. If you would like, > I can send you a pre-release binary with this fix. > > Also note that using NMTOKENS as a base for this enumeration does > not make much sense. NMTOKENS is a list (space-separated) of NMTOKEN. > Also the generated code for the two will be quite different. The > NMTOKEN based type will have nice C++ enum translation while the > NMTOKENS-based case will be translated to simple derivation. > > > hth, > -boris > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.5 (GNU/Linux) > > iQGVAwUBRhp/QsiAKQuuCE8dAQIE3wwAojPdv9khVDsGA0MMtMYdluhwRrMChaRV > R/P+yrCC/qNUMjWrzcIm60B+eFTauz8sCqy08rk7+G9Mc24YumjK+OVTYFaFPw4g > DiEvu2e7DhQecWN/p7/C6mvP05bkdLqhwfT+4/rMEOTaYmiI6Y69HSNoEl0JtbcY > z9p7Lcjd1OcBQygN5k+gtdxw4WkpeSYFX/XtnKSqy8P0BxG2uGddv0/Y/9UcImP3 > NC4hb6F1sEPkXm6CGG8XbMOiipwGrNkXY1cPK6YxgxQWQUte8BOBpq3qUGMnu7py > RpQEm233ZGsUP3UpSHtTKUyGg5ECaTLck84ux17Jan7TGAMp0MQj4dmoudVRJPfs > RuwDCDI+T5ygsb5MmK5CDMeiG6DZ3Fv2toTye9PT1bh7JXuCcq7dui6LPbIfFSSi > +LH+5zZ/mwSLeKCp6iP/eTzLQ/4/52MutNz4JN6pE/6coZq1jb5TzOx37EB3Z7H/ > PV9DebGKC8Cyh2vbAnR9J2lljrsnANYN > =LWSq > -----END PGP SIGNATURE----- > > From gerard at lanois.com Tue Apr 10 11:15:42 2007 From: gerard at lanois.com (Gerard Lanois) Date: Sun Oct 11 15:33:55 2009 Subject: [xsd-users] fatal error C1046: compiler limit : struct nested too deeply In-Reply-To: <20070406111838.GA12670@karelia> References: <5a454940704051421p1f204ee9g58109bb2b83a5e17@mail.gmail.com> <20070406111838.GA12670@karelia> Message-ID: <5a454940704100815p24a74601xad5915de0e50c204@mail.gmail.com> When I use --morph-anonymous, I find that the standard idiom for parsing a document does not compile: int _tmain(int argc, _TCHAR* argv[]) { std::auto_ptr blah(BLAH(argv[1])); return 0; } The above gives the following compilation errors: c:\users\gerard\ReadBLAH\ReadBLAH.cpp(11) : error C2039: 'type' : is not a member of 'BLAH' c:\users\gerard\ReadBLAH\BlahSchema.hxx(278) : see declaration of 'BLAH' c:\users\gerard\ReadBLAH\ReadBLAH.cpp(11) : error C2065: 'type' : undeclared identifier It seems that --morph-anonymous prevents the usual "public: typedef _xsd_BLAH_::BLAH type;" from being generated in class BLAH. What constructor & auto_ptr statement should I use to achieve a successful parsing, equivalent to the one given above? Thanks for all your help, -Gerard On 4/6/07, Boris Kolpackov wrote: > Hi Gerard, > > Gerard Lanois writes: > > > Anyway, is there a way to tell the xsd tool not to nest the structures as it > > generates the .hxx/.cxx? (to "flatten" the schema?) > > There is the --morph-anonymous option which names all anonymous types and > as a result reduces nesting to the maximum of 3 levels. If this does not > help then it would be great if you could post the part of the generated > code (along with the surrounding code all the way to the namespace scope) > that triggers the error. > > > thanks, > -boris > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.5 (GNU/Linux) > > iQGVAwUBRhYsjsiAKQuuCE8dAQKwKgv/Xb4J55BR0Bhennh+XEejIe/TV7cFijm3 > 1UxmnO7syc9Hm5R5KzUli/maj8kr1G0zJU7PwDG4Dm1WpHv+qtNOJXY8K1/xV/fj > bPKqzYMYvZxPzDoVr7CpB0Vsrwh2dZ4P+vHy4Vxxj82U7wRmL+E/O/xwbnejPmrj > nnoBtRWsLVHuGowV3RySdBAuCI3euiXwoCBfvwCqNP+ArLpnMBoSykxVEU+Ejqch > 21S7vvZRtiozIgElGvZprRRgY7wl1EajwdaNRcYaONF5muybU0OX8tOrwayLWuaL > tVWjfuPsfpRXmXgacF1nSu0cEbKFbYU4qZs0L8AejulxT+/GJLJOvEjFnP6y+/un > xtQuIBX/GyLPcBiwjZU7cv5ZgH+h8S63382lcAdIeg/okxkdOqOxxgsLWVdS15kH > YQYCbDaUlJmRPoWiDbM9GeNru7hUvXPX0RUkJRsHk7cGKEANc0DeCnWAjIOCBMiu > +U8/DNslzdeztYhfBqwgGcvFTSzqtbpH > =chS9 > -----END PGP SIGNATURE----- > > From boris at codesynthesis.com Tue Apr 10 11:12:21 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:55 2009 Subject: [xsd-users] fatal error C1046: compiler limit : struct nested too deeply In-Reply-To: <5a454940704100815p24a74601xad5915de0e50c204@mail.gmail.com> References: <5a454940704051421p1f204ee9g58109bb2b83a5e17@mail.gmail.com> <20070406111838.GA12670@karelia> <5a454940704100815p24a74601xad5915de0e50c204@mail.gmail.com> Message-ID: <20070410151221.GE26221@karelia> Hi Gerard, Gerard Lanois writes: > When I use --morph-anonymous, I find that the standard > idiom for parsing a document does not compile: > > std::auto_ptr blah(BLAH(argv[1])); > > [...] > > It seems that --morph-anonymous prevents the usual > "public: typedef _xsd_BLAH_::BLAH type;" from being > generated in class BLAH. When you use the --morph-anonymous option, all anonymous types become explicitly named. As a result, the generated code can change. In case of a global element with anonymous type: ... The transformation performed by the --morph-anonymous option results in the following equivalent schema (this is performed internally by the compiler): ... And the generated code now looks like this: class foo { ... }; std::auto_ptr foo_ (const char* url); Note that the name of the parsing functions is escaped with '_' to avoid name clashes. The usage becomes: std::auto_ptr f = foo_ ("foo.xml"); hth, -boris -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 652 bytes Desc: Digital signature Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20070410/3bbd369b/attachment.pgp From glenn.nieuwenhuyse at gmail.com Tue Apr 10 11:35:34 2007 From: glenn.nieuwenhuyse at gmail.com (Glenn Nieuwenhuyse) Date: Sun Oct 11 15:33:55 2009 Subject: [xsd-users] --suppress-parsing generates compiler errors Message-ID: <147ae4280704100835l5f8e0b14hd40552a196712892@mail.gmail.com> Hi all, I'm using xsd to generate C++ code from a given xsd file. I first used the following command line string: xsd cxx-tree --generate-inline --generate-serialization --generate-ostream --parts 4 filename.xsd This works fine however I don't need the parsing code and would like to reduce the size of the code generated by using the --suppress-parsing option. The code generation works fine but when I try to compile I get compiler errors. Due to the fact that it still tries to use a constructor containing a DOMelement which is normally only needed in case you use the parsing code. Has anybody experienced this already or know a work around for this. Kind regards, Glenn. From boris at codesynthesis.com Tue Apr 10 11:31:10 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:55 2009 Subject: [xsd-users] --suppress-parsing generates compiler errors In-Reply-To: <147ae4280704100835l5f8e0b14hd40552a196712892@mail.gmail.com> References: <147ae4280704100835l5f8e0b14hd40552a196712892@mail.gmail.com> Message-ID: <20070410153110.GF26221@karelia> Hi Glenn, Glenn Nieuwenhuyse writes: > This works fine however I don't need the parsing code and would like to > reduce the size of the code generated by using the --suppress-parsing > option. The code generation works fine but when I try to compile I get > compiler errors. Due to the fact that it still tries to use a constructor > containing a DOMelement which is normally only needed in case you use the > parsing code. We have a test for this situation but it passes without any problems. Would it be possible for you to show a fragment of your schema that results in the generated code that triggers the error. A small test case would also do. thanks, -boris -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 652 bytes Desc: Digital signature Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20070410/041d48ed/attachment.pgp From gerard at lanois.com Tue Apr 10 13:27:37 2007 From: gerard at lanois.com (Gerard Lanois) Date: Sun Oct 11 15:33:55 2009 Subject: [xsd-users] fatal error C1046: compiler limit : struct nested too deeply In-Reply-To: <20070410151221.GE26221@karelia> References: <5a454940704051421p1f204ee9g58109bb2b83a5e17@mail.gmail.com> <20070406111838.GA12670@karelia> <5a454940704100815p24a74601xad5915de0e50c204@mail.gmail.com> <20070410151221.GE26221@karelia> Message-ID: <5a454940704101027m2347ee6bxd4cd2f8dc46abe99@mail.gmail.com> Thanks - that was exactly what I was looking for. The explanation you give below would make for a nice addition to either the C++/Tree Mapping User Manual, the XSD man page (under the description of the --morph-anonymous option) or perhaps in the wiki. I could add it to the wiki if you could suggest an ideal location for it. Or maybe add this material to the C++/Tree Mapping Quick Guide. In any case, thanks again for your help this week. I think I'm off and running now. I've sucessfully parsed and dumped a document using all the advice you've provided. Cheers, -Gerard On 4/10/07, Boris Kolpackov wrote: > Hi Gerard, > > Gerard Lanois writes: > > > When I use --morph-anonymous, I find that the standard > > idiom for parsing a document does not compile: > > > > std::auto_ptr blah(BLAH(argv[1])); > > > > [...] > > > > It seems that --morph-anonymous prevents the usual > > "public: typedef _xsd_BLAH_::BLAH type;" from being > > generated in class BLAH. > > When you use the --morph-anonymous option, all anonymous types become > explicitly named. As a result, the generated code can change. In case > of a global element with anonymous type: > > > > > ... > > > > The transformation performed by the --morph-anonymous option results > in the following equivalent schema (this is performed internally by > the compiler): > > > ... > > > > > And the generated code now looks like this: > > class foo > { > ... > }; > > std::auto_ptr foo_ (const char* url); > > > Note that the name of the parsing functions is escaped with '_' to avoid > name clashes. The usage becomes: > > std::auto_ptr f = foo_ ("foo.xml"); > > > hth, > -boris > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.5 (GNU/Linux) > > iQGVAwUBRhupVciAKQuuCE8dAQJijAv+PMH/kQpAvQVcPgUWSVZe4bX1kNceakzd > B74LGcOjWOKXujYZ5UgFnlYQFToWluPJgPKdtisjyNV6LB5ZEeuLWsbG81V5vhdC > LR/jBIhGoiL6OgLLJK50YzvTltAgQMU/8DxGPE/W2GCKr8mJfQISgb10mvLr/ofs > Xhjn9YqrzL5UhXeBX2DiGrR9hukep6wyXE1xt+uH4R3ArZ+qvR8JJHzHA42rJJPR > xTbV+lpoqgMO1eLhkgGDIpTbILdSGVMOPTQpHjlLui7Qz+Pina5OeVkyr+67Htrd > u+W3l4ypK0bjQdoAYGg2b/B6LCaXsy0QphMastN7q4LoWGI1fIqI/wnAFFPERJYv > nau202Eu/ZSEgubXoivygwgW3alGQ8SIEP7xeYUViSP2c/cYrBlfbqpfme/mXkg1 > g0IRdDOBZ3oZsjGDchOjyRx45ofg/9pSLgXrcZ/eMq+WHei77kjV8szaRt+zG5MP > ftLA+IccP4I4IYFS2Rz66ityD24JIbDQ > =tEmU > -----END PGP SIGNATURE----- > > From boris at codesynthesis.com Tue Apr 10 13:55:06 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:55 2009 Subject: [xsd-users] fatal error C1046: compiler limit : struct nested too deeply In-Reply-To: <5a454940704101027m2347ee6bxd4cd2f8dc46abe99@mail.gmail.com> References: <5a454940704051421p1f204ee9g58109bb2b83a5e17@mail.gmail.com> <20070406111838.GA12670@karelia> <5a454940704100815p24a74601xad5915de0e50c204@mail.gmail.com> <20070410151221.GE26221@karelia> <5a454940704101027m2347ee6bxd4cd2f8dc46abe99@mail.gmail.com> Message-ID: <20070410175506.GH26221@karelia> Hi Gerard, Gerard Lanois writes: > The explanation you give below would make for a nice addition > to either the C++/Tree Mapping User Manual, the XSD man page > (under the description of the --morph-anonymous option) or > perhaps in the wiki. I could add it to the wiki if you could > suggest an ideal location for it. That's a good idea but I think we have a better solution: in the next version of XSD we will turn anonymous type morphing on by default. Hopefully after that change nobody will run into this problem anymore. -boris -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 652 bytes Desc: Digital signature Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20070410/04268518/attachment.pgp From boris at codesynthesis.com Wed Apr 11 04:29:34 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:55 2009 Subject: [xsd-users] --suppress-parsing generates compiler errors In-Reply-To: <147ae4280704102345j4850dbd3j4a8a6dc3c07f8710@mail.gmail.com> References: <147ae4280704100835l5f8e0b14hd40552a196712892@mail.gmail.com> <20070410153110.GF26221@karelia> <147ae4280704102345j4850dbd3j4a8a6dc3c07f8710@mail.gmail.com> Message-ID: <20070411082934.GA28625@karelia> Hi Glenn, I've CC'ed xsd-users to my reply so that others with similar problems can benefit from this discussion. Glenn Nieuwenhuyse writes: > In attachment you'll find an example of an xsd file which illustrates this > problem. I see what the problem is now: the generated code for default/fixed attributes relies on one of the parsing constructors. I will need to think some more on how to fix this without diminishing the benefits of --suppress-parsing. Hopefully the fix will be in the next release. A workaround for the meantime is to put simple types that are used in default/fixed attributes (like type_attr_type in the schema you provided) into a separate schema file which is included into the main schema. You can then compile this schema file without the --suppress-parsing option to generate the parsing constructors. Thanks for the bug report and the test case! -boris -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 652 bytes Desc: Digital signature Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20070411/72873aa0/attachment.pgp From mark.kinzie at jhuapl.edu Wed Apr 11 17:26:35 2007 From: mark.kinzie at jhuapl.edu (Mark Kinzie) Date: Sun Oct 11 15:33:55 2009 Subject: [xsd-users] Assertion when parsing multiple files with keep_dom, dont_initialize Message-ID: <461D528B.2050100@jhuapl.edu> Hi, I'm getting: "Assertion failed: c != 0, file c:\source\visualstudio\oasis\simitar\lib\xsd\include\xsd\cxx\tree\elements.hxx, line 473" The circumstances are: I'm calling XMLPlatformUtils::Initialize(); ... auto_ptr a( typeA( uri, xml_schema::flags::keep_dom | xml_schema::flags::dont_initialize )); ... // Then, accessing elements within a and calling _node() to get a DOMNode from within a, then... auto_ptr b( typeB( uri, xml_schema::flags::keep_dom | xml_schema::flags::dont_initialize )); // Then I access elements of b, but before I can even get to the point of calling _node(), // I get the above assertion when trying to access an element within b. If I remove the keep_dom and dont_initialize flags on the second call, everything works OK, except of course that when I call _node() I get null. Am I doing this improperly? Thanks, Mark From boris at codesynthesis.com Wed Apr 11 17:45:40 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:55 2009 Subject: [xsd-users] Assertion when parsing multiple files with keep_dom, dont_initialize In-Reply-To: <461D528B.2050100@jhuapl.edu> References: <461D528B.2050100@jhuapl.edu> Message-ID: <20070411214540.GE28625@karelia> Hi Mark, Mark Kinzie writes: > auto_ptr b( > typeB( > uri, xml_schema::flags::keep_dom | > xml_schema::flags::dont_initialize > )); > > // Then I access elements of b, but before I can even get to the > point of calling _node(), > // I get the above assertion when trying to access an element > within b. Hm, this is interesting. The assertion is in the clone() function for an internal type that stores the DOM association data. The strange part is that clone() is called when you are accessing the data, in which case no copying should happen (unless you are making a copy of a sub-tree, of course). Can you should how you access the elements in b? Does anything change if you comment out the code that deals with 'a'? Also, if you could come up with a test case that reproduces this problem, then that would great. I could then try to debug it. thanks, -boris -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 652 bytes Desc: Digital signature Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20070411/66357411/attachment.pgp From boris at codesynthesis.com Thu Apr 12 14:46:02 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:55 2009 Subject: [xsd-users] Assertion when parsing multiple files with keep_dom, dont_initialize In-Reply-To: <461D528B.2050100@jhuapl.edu> References: <461D528B.2050100@jhuapl.edu> Message-ID: <20070412184602.GD32480@karelia> Hi Mark, I've managed to reproduce and fix this problem. Let me know if you would like a patch (the changes are limited to the header-only libxsd). hth, -boris -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 652 bytes Desc: Digital signature Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20070412/b494d8bb/attachment.pgp From rlischner at proteus-technologies.com Mon Apr 16 10:57:19 2007 From: rlischner at proteus-technologies.com (Ray Lischner) Date: Sun Oct 11 15:33:55 2009 Subject: [xsd-users] bug in containers.hxx:362 Message-ID: There is a bug in libxsd/xsd/cxx/tree/containers.hxx, line 362. The operator== overload for optional<> recurses infinitely. To fix, change "a == b" to "!a == !b" (or the logical equivalent). -- Ray Lischner, Proteus Technologies From boris at codesynthesis.com Mon Apr 16 12:40:19 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:56 2009 Subject: [xsd-users] bug in containers.hxx:362 In-Reply-To: References: Message-ID: <20070416164019.GB9961@karelia> Hi Ray, Ray Lischner writes: > There is a bug in libxsd/xsd/cxx/tree/containers.hxx, line 362. The > operator== overload for optional<> recurses infinitely. To fix, change > "a == b" to "!a == !b" (or the logical equivalent). Fixed by changing "a == b" to "a.present () == b.present ()". Thanks for reporting this! -boris -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 652 bytes Desc: Digital signature Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20070416/6dc06489/attachment.pgp From bao.young at gmail.com Sun Apr 22 11:37:59 2007 From: bao.young at gmail.com (Bao Young) Date: Sun Oct 11 15:33:56 2009 Subject: [xsd-users] Link to stylesheet in xml output Message-ID: <11ae802b0704220837t1ae4efaey2ac933d4b42e99b9@mail.gmail.com> Hello, Is that a way for XSD to include a link to a stylesheet in the output xml file? Thanks for any help, Bao From boris at codesynthesis.com Sun Apr 22 15:40:39 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:56 2009 Subject: [xsd-users] Link to stylesheet in xml output In-Reply-To: <11ae802b0704220837t1ae4efaey2ac933d4b42e99b9@mail.gmail.com> References: <11ae802b0704220837t1ae4efaey2ac933d4b42e99b9@mail.gmail.com> Message-ID: <20070422194039.GB28074@karelia> Hi Bao, Bao Young writes: > Is that a way for XSD to include a link to a stylesheet in the output xml > file? > > XSD can't do it but you can do it yourself by (1) serializing the tree representation to DOM (using the corresponding serialization function), (2) adding the processing instruction (that's what that thing above is called), and (3) serializing the DOM document to XML. Here is an example code that does this: using namespace xercesc; namespace xml = xsd::cxx::xml; XMLPlatformUtils::Initialize (); { foo& f = ... // f is the root of the tree representation // (1) // xml_schema::namespace_infomap map; xml::dom::auto_ptr doc = bar (f, map); // (2) // DOMElement* root = doc->getDocumentElement(); DOMProcessingInstruction* pi = doc->createProcessingInstruction ( xml::string ("xml-stylesheet").c_str (), xml::string ("type=\"text/xsl\" href=\"simple.xsl\"").c_str ()); doc->insertBefore(pi, root); // (3) // std::ofstream ofs ("out.xml"); serialize (ofs, *doc); } XMLPlatformUtils::Terminate (); The serialize() function is taken from the FAQ entry 3.2: http://wiki.codesynthesis.com/Tree/FAQ hth, -boris -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 652 bytes Desc: Digital signature Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20070422/8be1d92b/attachment.pgp From glenn.nieuwenhuyse at gmail.com Mon Apr 23 17:01:52 2007 From: glenn.nieuwenhuyse at gmail.com (Glenn Nieuwenhuyse) Date: Sun Oct 11 15:33:56 2009 Subject: [xsd-users] Unexplained code size increase Message-ID: <147ae4280704231401o7b832a2bvee24e126d12fa383@mail.gmail.com> Hi all, In the process of compiling code out of XML Schema files with the xsd --cxx-tree tool, I was surprised about the vast amount of binary code increase I saw in my binary. My original code was 5.2MB binary whilst after the addition of the code for XML generation the binary code size went up to 16MB. I was able to reduce that amount, thanks to your help on the --suppress-parsing bug and thanks to the --generate-inline switch, to ~11.5MB. Having xerces linked statically costs about 2MB of the 6.5MB increase which leaves about 4.5MB open for the generated code and of course the code using it. To illustrate my problem I have made a small test case (see attachment): Currently my XML Schema is written as in the Large.xsd-file . The Small.xsd-file is one of the possible solutions I'm looking into. The XMLGenerator.h-file is similar to what I'm using in my software. When compiling the example (instructions below) and using "size" to view the size of each of the binary sections this is the result: (Using GCC 3.4.3) (note that "nothing" is an almost-empty binary while small uses the Small schema and LARGE uses the Large schema) small : LARGE : nothing : section size addr section size addr section size addr .interp 13 268435796 .interp 13 268435796 .interp 13 268435796 .note.ABI-tag 32 268435812 .note.ABI-tag 32 268435812 .note.ABI-tag 32 268435812 .hash 1660 268435844 .hash 1664 268435844 .hash 208 268435844 .dynsym 3456 268437504 .dynsym 3472 268437508 .dynsym 528 268436052 .dynstr 4569 268440960 .dynstr 4519 268440980 .dynstr 1017 268436580 .gnu.version 432 268445530 .gnu.version 434 268445500 .gnu.version 66 268437598 .gnu.version_r 128 268445964 .gnu.version_r 128 268445936 .gnu.version_r 128 268437664 .rela.dyn 336 268446092 .rela.dyn 360 268446064 .rela.dyn 120 268437792 .rela.plt 744 268446428 .rela.plt 756 268446424 .rela.plt 216 268437912 .init 40 268447172 .init 40 268447180 .init 40 268438128 .text 58852 268447212 .text 105916 268447220 .text 2336 268438168 .fini 32 268506064 .fini 32 268553136 .fini 32 268440504 .rodata 3896 268506096 .rodata 6960 268553168 .rodata 110 268440536 .sdata2 0 268509992 .sdata2 0 268560128 .sdata2 0 268440648 .eh_frame_hdr 1828 268509992 .eh_frame_hdr 3068 268560128 .eh_frame_hdr 52 268440648 .eh_frame 8072 268511820 .eh_frame 14168 268563196 .eh_frame 200 268440700 .gcc_except_table 5348 268519892 .gcc_except_table 11904 268577364 .gcc_except_table 76 268440900 .ctors 12 268591104 .ctors 16 268656640 .ctors 12 268506512 .dtors 8 268591116 .dtors 8 268656656 .dtors 8 268506524 .jcr 4 268591124 .jcr 4 268656664 .jcr 4 268506532 .got2 16 268591128 .got2 16 268656668 .got2 16 268506536 .dynamic 232 268591144 .dynamic 232 268656684 .dynamic 224 268506552 .data 8 268591376 .data 8 268656916 .data 8 268506776 .got 20 268591384 .got 20 268656924 .got 20 268506784 .sdata 80 268591404 .sdata 100 268656944 .sdata 8 268506804 .sbss 27 268591488 .sbss 27 268657048 .sbss 2 268506812 .plt 816 268591516 .plt 828 268657076 .plt 288 268506816 .bss 644 268592336 .bss 1084 268657904 .bss 372 268507104 .comment 520 0 .comment 585 0 .comment 455 0 .debug_aranges 1744 0 .debug_aranges 2520 0 .debug_aranges 216 0 .debug_pubnames 24925 0 .debug_pubnames 37488 0 .debug_pubnames 3412 0 .debug_info 285224 0 .debug_info 422446 0 .debug_info 44659 0 .debug_abbrev 6204 0 .debug_abbrev 9444 0 .debug_abbrev 2522 0 .debug_line 32279 0 .debug_line 54768 0 .debug_line 3251 0 .debug_frame 9004 0 .debug_frame 15392 0 .debug_frame 284 0 .debug_str 165635 0 .debug_str 179847 0 .debug_str 52735 0 .debug_ranges 6392 0 .debug_ranges 9232 0 .debug_ranges 88 0 Total 623232 Total 887531 Total 113758 For merely 10 small classes ~50KB of stripped binary code (.text section) seems huge. Taken that my real XSD-file is a lot bigger, you can imagine where the 4.5MBis coming from. Looking at the generated code I see lots of simple functions (empty constructors using initializer lists, functions returning immediately, the DOM-generating functions, ...). None of them look like they can produce that amount of code. Even when nosing through the gcc-generated assembly I can not spot anything irregular. The example allows you to generate these results using the included example file. There's a makeExample shell-script included which you can adjust for your specific configuration (compiler, stripper and XSD directory) however when everything is standard it should work out of the box. I'm hoping you can help me out in finding (and perhaps eliminating) where the extra binary code is coming from between the Large.xsd and the Small.xsdfile. Kind regards, Glenn. -------------- next part -------------- A non-text attachment was scrubbed... Name: example.tar.gz Type: application/x-gzip Size: 2603 bytes Desc: not available Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20070423/da4b0add/example.tar.bin From boris at codesynthesis.com Tue Apr 24 17:13:24 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:56 2009 Subject: [xsd-users] Unexplained code size increase In-Reply-To: <147ae4280704231401o7b832a2bvee24e126d12fa383@mail.gmail.com> References: <147ae4280704231401o7b832a2bvee24e126d12fa383@mail.gmail.com> Message-ID: <20070424211324.GB3639@karelia> Hi Glenn, Glenn Nieuwenhuyse writes: > For merely 10 small classes ~50KB of stripped binary code (.text section) > seems huge. Thanks for a nice test case. Some time ago we did extensive code analysis and optimization which resulted in significant space reduction. We used nm to dump and analyze the size of each symbol in the resulting object code. I tried the same techniques on your example. To make sure we compare apples to apples, I commented out everything in test.cpp so that main() is an empty function. Then, with the help of nm (command: nm -C -S --size-sort -r d Large.o), I got a list of things that end up in the object file for each bitfieldN type: 0000000000000000 0000000000000011 V typeinfo name for bitfield1 0000000000000000 0000000000000024 V typeinfo for bitfield1 0000000000001344 0000000000000040 B bitfield1::txt::default_value_ 0000000000001280 0000000000000040 B bitfield1::type::default_value_ 0000000000000000 0000000000000040 V vtable for bitfield1 0000000000000000 0000000000000112 W bitfield1::~bitfield1() 0000000000009888 0000000000000115 T bitfield1::_clone(xsd::cxx::tree::flags, xsd::cxx::tree::_type*) const 0000000000000000 0000000000000126 W bitfield1::~bitfield1() 0000000000010208 0000000000000184 T bitfield1::bitfield1(bitfield_1 const&, xsd::cxx::tree::string > const&, type_attr_type const&) 0000000000009696 0000000000000184 T bitfield1::bitfield1(bitfield1 const&, xsd::cxx::tree::flags, xsd::cxx::tree::_type*) 0000000000010400 0000000000000184 T bitfield1::bitfield1(bitfield_1 const&, xsd::cxx::tree::string > const&, type_attr_type const&) 0000000000010016 0000000000000184 T bitfield1::bitfield1(bitfield1 const&, xsd::cxx::tree::flags, xsd::cxx::tree::_type*) 0000000000023456 0000000000000603 T operator<<(xercesc_2_7::DOMElement&, bitfield1 const&) The second column is the size. It adds up to 1847 bytes per type. The strange thing here is that at the same time the size difference between the .text section of large and small is 29648 bytes or 3294 bytes per type. I am not quite sure where this difference comes from. Other sections that grew are .rodata, .bss, and exception handling related sections. From this analysis it appears that optimizing the individual functions won't make much difference. If you have any further ideas -- let me know. I am also going to ask on the g++ newsgroup about this. hth, -boris -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 652 bytes Desc: Digital signature Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20070424/6adbe7b1/attachment.pgp From boris at codesynthesis.com Wed Apr 25 05:31:25 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:56 2009 Subject: [xsd-users] Support for Windows on x86-64 Message-ID: <20070425093125.GA6604@karelia> Hi, We have tested and are now supporting Windows on x86-64 (aka AMD64, EM64T, and x64 in Microsoft terminology) with Visual Studio 2005 and Intel C++ 9.0 and 9.1. We have also packaged precompiled Xerces-C++ libraries for x86-64 built with Visual Studio 2005. The package can be downloaded from the usual place: http://www.codesynthesis.com/products/xsd/download.xhtml -boris -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 652 bytes Desc: Digital signature Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20070425/f6a8585b/attachment.pgp From balaji.yalamarthi at wipro.com Wed Apr 25 07:58:43 2007 From: balaji.yalamarthi at wipro.com (balaji.yalamarthi@wipro.com) Date: Sun Oct 11 15:33:56 2009 Subject: [xsd-users] help needed for installing xsd on my linux system Message-ID: Hi , I want to extract data from my xml using its schema.For that I am trying to install xsd on my mechine (I am installing according to the instructions on the web) I downloaded from http://www.codesynthesis.com/products/xsd/ .... build-0.2.2.tar.bz2 boost-jam-3.1.13.tgz boost_1_33_1.tar.bz2 xerces-c-src_2_7_0.tar.gz libcult-1.2.0.tar.bz2 libfrontend-elements-1.0.2.tar.bz2 libbackend-elements-1.0.4.tar.bz2 libxsd-frontend-1.6.0.tar.bz2 xsd-2.1.0.tar.bz2 ..... To install xsd on my mechine I was able to install ... boost-jam-3.1.13.tgz boost_1_33_1.tar.bz2 ....on my linux machine But while installing build-0.2.2.tar.bz2 I am facing segmentation fault while make is done. Please let me know how to go a head. Wating for reply. Regards Balaji The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com From boris at codesynthesis.com Wed Apr 25 07:58:31 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:56 2009 Subject: [xsd-users] help needed for installing xsd on my linux system In-Reply-To: References: Message-ID: <20070425115831.GD6604@karelia> Hi Balaji, balaji.yalamarthi@wipro.com writes: > (I am installing according to the instructions on the web) Is there any reason why you can't use precompiled binary from http://www.codesynthesis.com/products/xsd/download.xhtml There are a number of packages for GNU/Linux including .deb for Debian and .rpm for RedHat/SUSE. There is also the .tar.bz2 package that can be used on any GNU/Linux distribution. Using precompiled binary distribution is a much easier way to start using XSD. hth, -boris -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 652 bytes Desc: Digital signature Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20070425/b58ddbf6/attachment.pgp From kai.klesatschke at netallied.de Fri Apr 27 10:25:55 2007 From: kai.klesatschke at netallied.de (Kai Klesatschke) Date: Sun Oct 11 15:33:56 2009 Subject: [xsd-users] xerces and icu Message-ID: <463207F3.1050407@netallied.de> Hello, uses someone xsd/xerces-c with ICU? My problem is that I need to recompile xerces to link together with ICU. Regards, Kai From boris at codesynthesis.com Fri Apr 27 10:33:05 2007 From: boris at codesynthesis.com (Boris Kolpackov) Date: Sun Oct 11 15:33:56 2009 Subject: [xsd-users] xerces and icu In-Reply-To: <463207F3.1050407@netallied.de> References: <463207F3.1050407@netallied.de> Message-ID: <20070104143312.GB3027@karelia> Hi Kai, Kai Klesatschke writes: > uses someone xsd/xerces-c with ICU? Yes, I use Debian-stock Xerces-C++ that is built with ICU. > My problem is that I need to recompile xerces to link together > with ICU. That shouldn't be too hard. Which platform are you using? -boris -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 652 bytes Desc: Digital signature Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20070427/52089788/attachment.pgp