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

[Greg Chicares]

On 2010-01-16 18:40Z, Vaclav Slavik wrote:
> 
> On Sat, 2010-01-16 at 17:49 +0000, Greg Chicares wrote:
> 
>> 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.

Okay, now I understand the annoyance. I guess I've experienced it
myself, too, in "per-enum boilerplate" like:

std::string mc_str(mcenum_dbopt z)
{
    return mce_dbopt(z).str();
}

where I know only T=mcenum_dbopt. And there are similar kludges for:
  std::string mc_str(mcenum_run_basis);
  std::string mc_str(mcenum_state);

> 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.

Yes, like 'Trammel' in 'tn_range.hpp':
  template<typename Number, typename Trammel> class tn_range

> 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.

Let me state my concerns and see what you think about them.

- This class is rather fundamental to lmi, and is used pervasively,
so accidental pessimizations could be costly. That problem could be
avoided by extensive testing. Aside from what 'mc_enum_test.cpp'
covers, I'd be most concerned about bloating binary files and
increasing the time or the amount of RAM required to build them.

- I need to understand the resulting class (hierarchy) intimately.
The more radical the changes, the harder it'd be for me to find
enough time to review them promptly.

OTOH, there could be important advantages:

- Perhaps a refactored class could work around the known msvc
defect without making everything really ugly.

- This might be a nice way to get rid of extant ugliness like
    std::string mc_str(mcenum_dbopt);

- Perhaps a faster alternative to std::find() could be used, so
performance would improve--maybe even dramatically.

I should also briefly discuss what I don't necessarily like about
this class, and therefore wouldn't insist on preserving. I'm not
wedded to the use of arrays as non-type template parameters: it's
a neat trick, but I've already derived quite enough satisfaction
from using it and wouldn't insist on retaining it as a monument
to "cleverness". When adding a new type, I wanted to make it hard
to make a mistake with array sizes--but I also made it rather hard
to make any correct change. The metadata is scattered over too many
files. And I profoundly regret the macros.

Oh, and here:
  // Here write illustrative examples and anything that doesn't follow
  // the macro paradigm, such as enumerators with nonsuccessive values.
By abstracting the metadata in a different way, maybe we could
get rid of this need for special treatment.