[xsd-users] Feature request: Explicit constructors

[Boris Kolpackov]

Hi Benjamin,

Benjamin Schindler <bschindler at inf.ethz.ch> 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