[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lmi] reusing mc_enum<> for serialization into XML
From: |
Greg Chicares |
Subject: |
Re: [lmi] reusing mc_enum<> for serialization into XML |
Date: |
Wed, 24 Feb 2010 19:18:07 +0000 |
User-agent: |
Thunderbird 2.0.0.23 (Windows/20090812) |
On 2010-02-02 08:07Z, Vaclav Slavik wrote:
>
> [...] Raw patch is here:
> http://review.bakefile.org/r/154/diff/raw/
http://svn.savannah.gnu.org/viewvc?view=rev&root=lmi&revision=4776
Here's a detail that deserves discussion (which I'll present in
terms of your original patch, for clarity). In 'mc_enum.tpp':
BOOST_STATIC_ASSERT(sizeof(typename enum_info::enums_t) ==
sizeof(enum_info::enums()));
BOOST_STATIC_ASSERT(sizeof(typename enum_info::strings_t) ==
sizeof(enum_info::strings()));
BOOST_STATIC_ASSERT(enum_info::n == sizeof(enum_info::enums())/sizeof(T));
BOOST_STATIC_ASSERT(enum_info::n ==
sizeof(enum_info::strings())/sizeof(const char*));
I think it's provably impossible for these assertions to fail,
because enum_info comes from here:
template<typename T, std::size_t sz, T const (*e)[sz], char const*const
(*c)[sz]>
struct mc_enum_type_info_impl
where we probably wouldn't bother to write:
BOOST_STATIC_ASSERT(sz == sizeof e / sizeof(T));
BOOST_STATIC_ASSERT(sz == sizeof c / sizeof(char*));
If we made an undisciplined change that defeated the compile-time
checking of array sizes, then we could wind up with:
some_type some_enums[] = {one, two}; // error--need three
// Instantiated with sz = 3, whereas the array has sz = 2...
template<typename T, std::size_t sz, T const (*e)[sz], char const*const
(*c)[sz]>
struct ...
but template argument 'e' would be an array of three elements, so it's
too late to check the cardinality there (and attempting to access the
third would cause a SIGSEGV).
However, do you feel that such assertions are valuable as documentation?