[xsd-users] different behavior by xsd 3.0 and 3.2

Jeffrey Yu jeffrey.yu at panpacificinvestment.com
Mon Oct 6 13:40:43 EDT 2008


Hi Boris,

The --guard-prefix helps fix the problem.  Thanks.

What I meant on "better name mangling mechanism" is when xsd compiler
generates variables according to the user xsd file, it might maintain a map
between its internal ones and user's, in addition to the one's created in
order to generate the data object.  In the problem I ran into, it happens my
variable value_type collides with xsd's value_type for value.  When xsd
compiler generates its internal variables, can it, let say, add __ as suffix
on each external variables so it can reduce the likelihood of bumping the
external one off the map?

It shouldn't be that difficult as I see it, you are adding the suffix _value
to the external variables, what if the algorithm is __value_ instead, I
mean, it would be less likely for programmers use complex naming convention
__value_ on their own.

Just a thought.

Jeff



-----Original Message-----
From: Boris Kolpackov [mailto:boris at codesynthesis.com] 
Sent: Monday, October 06, 2008 12:59 PM
To: Jeffrey Yu
Cc: 'XSD-users'
Subject: Re: [xsd-users] different behavior by xsd 3.0 and 3.2

Hi Jeffrey,

Jeffrey Yu <jeffrey.yu at panpacificinvestment.com> writes:

> Do you think it is possible to deploy a better name mangling mechanism 
> in xsd compiler so variable names can be unique and don't collide 
> With the user-defined variables?

This is a hard problem. If the translation (XML Schema to C++ in our
case) adds any names then there is always a chance they will conflict
with the ones in the source. So the only true solution to this problem
is not to add any names which is not really an option in our case. There
are further complication with, for example, C++ not allowing a member
function to have the same name as the class. In XML Schema you can have 
a type and an element/attribute inside this type with the same name.


> In short, it is the preprocessors placed in top of the .hxx have the
> different names caused the problem.

You can override the include guard prefix with the --guard-prefix
option, for example:

$ xsd cxx-tree foo/bar.xsd

In this case the guard will be FOO_BAR_HXX. If we add the option:

$ xsd cxx-tree --guard-prefix p foo/bar.xsd

the guard will be P_BAR_HXX regardless of the path to the schema.

Boris




More information about the xsd-users mailing list