[xsd-users] C++11, value semantics, and polymorphism

Ray Lischner rlischner at proteuseng.com
Thu Feb 14 07:04:00 EST 2013


We are jumping head first into C++11 and very much want to take full advantage of value semantics. We want to be able to construct most Code Synthesis objects without resorting to any dynamic memory allocation. Unless there are plans for Code Synthesis 4 to support this functionality, we will undertake the work ourselves.

It is a straightforward matter to modify xsd::cxx::tree::one<>, optional<>, and sequence<> to support value semantics as long as the types are not polymorphic. Making corresponding changes to xsd is not difficult. Most of our types are not polymorphic, and they are also the types that we most want to optimize.

But we need to support polymorphism, too. That's where we run into a hitch. I want the parsing functions to return values for value classes, but they must return pointers for polymorphic classes. I certainly don't want to force the user of a class to write different code depending on whether it is polymorphic, so the only solution I see is for xsd to generate a pimpl wrapper for polymorphic classes to hide the difference.

Thus, xsd would generate non-polymorphic classes normally. For a polymorphic class, it would generate a normal impl class and a pimpl wrapper. The pimpl wrapper would use the real type name; the impl class would append "_impl" to the class name (or something like that). The user should be able to use the wrapper the same way as a non-polymorphic class. Parsing functions would return a value for non-polymorphic types and a wrapper instance by value for polymorphic types.

The user sees only values. The only real difference in semantics is that assigning a derived-type to a base-type slices the value if non-polymorphic and preserves the derived-type value if polymorphic. The difference in performance is that value types can be parsed, constructed, moved, and manipulated without touching the heap.

One advantage of this approach is that the distinction between ref-to-const and auto_ptr arguments to constructors vanishes, and xsd can generate fewer constructors, passing all required arguments by value.

The changes to tree-header.cxx and tree-source.cxx are considerable, so I am asking, "is there any other way to support value semantics and polymorphism?"



Ray Lischner,
Distinguished Member of Technical Staff
133 National Business Pkwy, Ste 150     t. 443.539.3448
Annapolis Junction, MD 20701            c. 410.854.9787
rlischner at proteuseng.com                f. 443.539.3370


More information about the xsd-users mailing list