Re: Two class definitions in different translation units

[Alex Markin <alexanius at gmail dot com>]

Thanks for the answer.

> The compiler cannot warn, it has no way to know when compiling t1.cpp
> that there's a different definition in t2.cpp, and vice versa.

And what about lto (now it does not warn)?

Kind regards,
Markin Alex


2014-10-28 13:11 GMT+03:00 Jonathan Wakely <jwakely.gcc@gmail.com>:
> [Redirected from gcc@]
>
> On 28 October 2014 09:33, Alex Markin wrote:
>> As far as I understand the main issue here is that class A has
>> external linkage and linker do not analyse the fields of class, it
>> just watches class A by name. And the example itself breaks `3.2 One
>> definition rule':
>
> That's correct.
>
>>> 5.
>>> ...
>>> â each definition of D shall consist of the same sequence of tokens
>>
>>
>> And now my questions:
>>
>> * am I right with the understanding of situation and the example is UB?
>
> Yes
>
>> * if two definitions had the same fields and the same constructors,
>> should the program be correct?
>
> It's not quite that simple. Every definition of the class must consist
> of the same sequence of tokens, and all the names and functions it
> refers to must resolve to the same entities in every translation unit.
> The full rules are described in 3.2 [basic.def.odr] and are too long
> to quote here.
>
>
>> * is correct gcc behaviour with `-O1' a coincidence, or it detects
>> another class anyway?
>
> The constructors get inlined into foo(void*) and bar(void*)
>
>> * does it make sense to give a warning in that case?
>
> The compiler cannot warn, it has no way to know when compiling t1.cpp
> that there's a different definition in t2.cpp, and vice versa.
>
> The linker can warn, and the Gold linker has a --detect-odr-violations
> option that warns about some cases. The linker is not part of GCC
> though.