[xsd-users] RE: xsd bypasses customized types

[Boris Kolpackov]

Hi Richard,

Richard Cresswell <rcresswell at gmail.com> writes:

> Boris, that fixed the xsd tree generation, but the generated code
> still does not compile.  It creates a default constructor of form:
> 
> DerivedObject::
> DerivedObject ()
> : ::base::BaseObject ()
> {
> }
> 
> Shouldn't it detect that DerivedObject is derived from the custom type
> and create the correct constructors?

I assume by "correct constructors" you mean that your custom 
implementation of BaseObject class does not define a default
constructor. Unfortunately, the only way to detect this would
be to parse (as in C++) your BaseObject definition and figure
out which constructors it defines.

The way XSD handles this is that it expects the custom 
implementation to have the same interface as the generated 
version would have had. I don't see any other practical
way, unfortunately.


> Applying the patch also broke tests/cxx/tree/name-clash/inheritance.
> Could this be because of other missed patches? 

I am not sure what's the reason for this. In the current code
base all tests pass.


> cc.set ("cxx-tree-name-processor-stem-set", NameSet ());
> cc.set ("cxx-tree-name-processor-member-set", NameSet ());
> 
> was still
> 
> c.context ().set ("cxx-tree-name-processor-stem-set", stem_set);
> c.context ().set ("cxx-tree-name-processor-member-set", member_set);

The two code fragments are semantically equivalent in this case.


> I am concerned that my codebase diverges too much from where you are
> with 3.3, but I am reluctant to upgrade to the 3.3 beta since I will
> need to patch again when you do the final release.  Do you have an ETA
> for when the official 3.3 will go out?

It should be out later this week or early next week.

Boris