[lmi] reusing mc_enum<> for serialization into XML

[Vaclav Slavik]

Hi (Greg),

I'm finally working on the switch to XML formats and I've hit a problem
with enums handling that I hope you may have some insight into, being
most familiar with mc_enum<> around here.

I started with converting the simpler file formats (.rnd and .tir) and
hit a problem with the rounding_style enum. I don't want to store it as
a number in XML file, because it would render the use of human-readable
and editable XML format somewhat pointless.

My current output format looks like this:

    <withdrawal>
      <decimals>2</decimals>
      <style>to-nearest</style>
    </withdrawal>

This requires per-enum serialization code along the lines of

    template<>
    const enum_type_io_map<rounding_style>::MapEntry
    enum_type_io_map<rounding_style>::map[] =
        { {r_indeterminate, "indeterminate"}
        , {r_toward_zero,   "toward-zero"}
        , {r_to_nearest,    "to-nearest"}
        , {r_upward,        "upward"}
        , {r_downward,      "downward"}
        , {r_current,       "current"}
        , {r_not_at_all,    "not-at-all"}
        };

The thing is, this does something that mc_enum<> already does, albeit in
-- IMHO -- more verbose way.

My first idea was to add mc_enum<rounding_style> and use it only for XML
serialization, while still using rounding_style type in the code as
before. This isn't possible without large changes to mc_enum<>, though,
because mc_enum has many more template parameters.

So I added some boilerplate code to convert between an (otherwise
unused) mce_rounding_style mc_enum-type and concert between it and
rounding_style when serializing. This is IMHO too much of a hack, it
requires too much ugly code (see e.g.
http://review.bakefile.org/r/146/diff/1-2/#index_header -- I'm not sure
it will be fully understandable without the rest of XML changes,
though).

The question is, how to best handle reading and writing of enums? That
is, non-mc_enum<> ones, mc_enum<> types are trivial.

Following are the options that I think are available to us:

(0a) Have string<->enum translation for non-mc_enum independently of
     mc_enum, as above. This duplicates functionality, that's bad. OTOH,
     it's very simple, and it means that we can use symbolic names
     ("to-nearest") when wring to XML, instead of mc_enum's
     human-readable descriptions.

(0b) Like (0a), but use this simpler mechanism in mc_enum. I.e. split
     mc_enum into a class that does pure string<->enum conversion and
     another class with all the extras (valid values, datum_base,
     virtual methods).

(1) Do it like I did, keep using non-mc_enum enums and convert them to 
    mc_enum only when reading and writing XML. It's a hack, IMHO hard to
    follow, with some boilerplate code needed per-enum. But it avoids
    duplication.

(2) Change all normal enums into mc_enums everywhere. It's clean
    solution that avoids duplication. But it's more work and it adds
    some overhead, because mc_enum is rather heavy class compared to 
    C++ enums. I don't know if this overhead is significant, you
    certainly have much clearer grasp of this than me.

(3) Something else...?

I'd appreciate any thoughts on the subject that you may have, I'm afraid
I got as far as I could on my own here, even with Vadim's help.

Thanks,
Vaclav