[xsd-users] Mapping for string-based enumerations: string constructors?

Yury Zaytsev yury.zaytsev at traveltainment.de
Wed Mar 11 09:48:28 EDT 2015


Hi Boris,

On Wed, 11 Mar 2015, Boris Kolpackov wrote:

> Firstly, this is a programming error that will only be detected
> at runtime. Already bad news. There will be a performance
> penalty. Things get even worse once you consider inheritance of
> enumerations (yes, those things can inherit). Without some
> special double-check avoidance mechanism, this will be double
> (or triple, for two levels of inheritance, etc) performance
> penalty. So, overall, I don't consider this worth the extra
> complexity.

Thank you for the explanation! I concur with your analysis; indeed, it 
seems that adding an extra layer of checks isn't really worth it for the 
common use cases.

> The only solution that I am willing to entertain is an option
> that will disable the generation of these additional c-tors
> (but watch out for default attribute value initialization).

That should certainly work for my purposes, as I currently see no need to 
initialize the enum types e.g. with an empty string in my code, but 
conversely, it will catch invalid initializations at compile time.

However, at the same time it would be useful to have a public conversion 
function (string -> value) in conjunction with the option to disable 
string constructors.

For instance, I currently have dynamic translation tables stored as 
strings in the input files. I could then explicitly call

     EnumType::value v = EnumType::convert("key");
     const auto e = EnumType{v};

and be sure that if "key" (which comes from the translation table that I 
don't control) is not in the schema definition, the conversion will throw 
an exception at runtime.

I'm not sure how high this is going to be on your priorities list (I guess 
not very high ;-) ), but I can try to see if I can have a look into it in 
my spare time before you get to it, if you could point me to the entry 
points in the XSD source code where I'd have to make changes...

P.S. The XSD documentation is excellent, it takes some experience with the 
tool to really understand it, but now I'm really enjoying it.

All the best,

-- 
Dr. Yury V. Zaytsev
Senior Software Developer
IT Data Production

TravelTainment GmbH
Carlo-Schmid-Straße 12
52146 Würselen/Aachen, Germany
yury.zaytsev at traveltainment.de

http://www.traveltainment.de

Amtsgericht Aachen, HRB 15873
Geschäftsführer: Bernhard Steffens (Vorsitzender),
Dr. Oliver Rengelshausen



More information about the xsd-users mailing list