[boost] Re: Re: Re: Typeof: Review result

From: Arkadiy Vertleyb (vertleyb_at_[hidden])
Date: 2005-06-02 14:07:01

"Peder Holt" <peder.holt_at_[hidden]> wrote

> On 6/2/05, Chris Uzdavinis <chris_at_[hidden]> wrote:
> > 1) The docs say that the BOOST_TYPEOF_INCREMENT_REGISTRATION_GROUP()
> >    macro is used in .hpp or .cpp files.  I'm curious how it works in a
> >    .hpp file if that file is included in multiple .cpp files.  Does it
> >    create a new group for the same types in each file?
>
> Yes. That is where the basis for possible ODR violations arises.
> We have tried testing if this causes any problems for the compilers we
> support, but it seems to work ok.

A registration group is just a number.  At the moment of registration we
combine this number with __LINE__, thus getting a unique id for each type or
template.

A registration macro expands into a number of template specializations that
help us to encode and decode the registered type/template (hence the
requirement to specify it in the context of global namespace).  In different
translation units, depending on the order of #includs, the same types may
have different ids, and so the same specializations -- different bodies.
This is technically an ODR violation.

To work this around, the encoding/decoding templates were placed into an
unnamed namespace, so that they are different in different TUs, and not a
subject to ODR.  Unfortunately this doesn't fix the problem completely.
Since typeof now relies on different templates in different TUs, it itself
becomes a subject of ODR violation, if used in a header:

TU1

struct A
{
    typedef BOOST_TYPEOF(1 + 0.5) type; /*double*/
};

TU2

struct A
{
    typedef BOOST_TYPEOF(1 + 0.5) type; /*also double, but calculated
through different set of templates */
};

This issue was discussed at some point in the past.  The decision was made
to ignore this ODR violation, as long as compilers don't care.

Fortunately, the compilers don't seem to care.  We have a specific test that
reproduces this situation as a part of our test rutine.  Also, Martin Wille
helped me to run this through como, strict mode, which is considered to be
the strictest compiler around.  Como didn't complain either.

The only way to avoid the ODR violation seem to be to assign registration
group numbers explicitly, and this would seriously reduce the usability of
the library.

Regards,
Arkadiy