Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2004-05-08 05:26:25


Ian McCulloch <ianmcc_at_[hidden]> writes:

>> Probably ;-) It's all there right under "One definition rule" in the
>> standard.
>>
>> 3 Basic concepts 3.2 One definition rule
>>
>> -5- There can be more than one definition of a class type (clause
>> class), enumeration type (dcl.enum), inline function with external
>> linkage (dcl.fct.spec), class template (clause temp), non-static
>> function template (temp.fct), static data member of a class template
>> (temp.static), member function [core 249: template of a class
>> template ] (temp.mem.func), or template specialization for which some
>> template parameters are not specified (temp.spec, temp.class.spec) in
>> a program provided that each definition appears in a different
>> translation unit, and provided the definitions satisfy the following
>> requirements. Given such an entity named D defined in more than one
>> translation unit, then
>>
>>
>> - each definition of D shall consist of the same sequence of
>> tokens; and
>>
>> - in each definition of D, corresponding names, looked up according
>> to basic.lookup, shall refer to an entity defined within the
>> definition of D, or shall refer to the same entity, after
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
>
> To my reading of the standard, different typedef-names that are synonyms for
> the same type are the same entity with respect to the ODR, so I don't think
> any of this applies here.

If you limit the question to typedefs, you're right, but I'm not
limiting the question to typedefs. The problem I'm discussing is this
one:

    namespace
    {
       template <class T>
       typeof (T() + T()) add(T*, T*)
       {
          typeof(T() + T()) x;
          ...
          return x;
       }
    }

If the declaration of x (or add, for that matter, I'm pretty sure)
uses any names that refer to different entities in different TUs, it's
an ODR violation.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk