Re: [lmi] reusing mc_enum<> for serialization into XML

[Vaclav Slavik]

Hi,

On Sat, 2010-01-16 at 17:49 +0000, Greg Chicares wrote:
> > 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.
> 
> Jumping ahead, I'm pretty sure the best answer is ultimately to:
> > (2) Change all normal enums into mc_enums everywhere.
> though that can be deferred if it seems best.

OK, thanks.

> AIUI you want to read this:
> >       <style>to-nearest</style>
> and transform it:
> >         , {r_to_nearest,    "to-nearest"}
> to the enumerator 'r_to_nearest'. I.e., given a string name, get its
> corresponding enumerator. I think you can do that using class mc_enum:
>     explicit mc_enum(std::string const&);
>     T value() const;
> e.g.
>     rounding_style r = mc_enum<whatever>("to-nearest").value();
> where in practice you'd typedef the 'mc_enum<whatever>' part.

This would be really simple, in template code, if
whatever==rouding_style. That is, if mc_enum<> was declared as:

  template<typename T>
  class mc_enum ...

Then I'd write one template to rule all non-mc_enum enums and use
boost::is_enum to deal with the conversion in one place. Instead, I have
to write per-enum boilerplate like the code above, because mc_enum<>'s
declaration is this:

  template<typename T, std::size_t n, T const (*e)[n],
           char const*const (*c)[n]>
  class mc_enum ...

And there's no way I can determine "whatever" if I only know T. So I
_have_ to typedef mc_enum<whatever> to something.

This wouldn't matter if all (XML-serialized) enums were mc_enums -- I
wouldn't need to do any conversion then. It's an annoyance during the
transition phase, though.

The solution would be to change n, e and c template parameters from
template parameters to mc_enum<> members. Or, perhaps better, members of
some enum_metadata<> template class that would be specialized for every
supported type.

Would you agree with such change? I think we would still be able to keep
all important compile-time checks, but I'm not sure -- I don't fully
what's the benefit of the current approach compared to
BOOST_STATIC_ASSERT checks of array sizes.


> IOW, I think you can already do that without adding new capabilities
> to mc_enum<>, yet above you say:
> >  This isn't possible without large changes to mc_enum<>, though,
> so maybe I'm missing something. 

See the above description of mc_enum<>'s template parameters.

Thanks,
Vaclav