ODR: A simple question

[ebony.soft@gmail.com]

Dear all
Hi

I encountered a simple but IMO important problem about the C++ linkage
model and One Definition Rule. Why the following code link?

file1.cpp
int x;

file2.cpp
double x;

x was defined in two different translation units with different types.
It breaks the ODR.
The following code is also linked:

file1.cpp
int x;

file2.cpp
extern double x;
It is obvious the type x in declaration and definition are different.
I ran and tested codes in Visual Studio 6.0 and .Net 2005.

Thank you in advance
- Saeed Amrollahi

[Pete Becker]

Re: ODR: A simple question

On 2008-09-29 06:01:07 -0400, ebony.soft@gmai l.com said:

>
I encountered a simple but IMO important problem about the C++ linkage
model and One Definition Rule. Why the following code link?
>
file1.cpp
int x;
>
file2.cpp
double x;
>
x was defined in two different translation units with different types.
It breaks the ODR.

The language definition doesn't require compilers to diagnose
violations of the ODR. Code like this has undefined behavior. As a
practical matter, recognizing errors like this is expensive, given
C++'s separate compilation model.

--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)

[James Kanze]

Re: ODR: A simple question

On Sep 29, 1:17 pm, Pete Becker <p...@versatile coding.comwrote :

On 2008-09-29 06:01:07 -0400, ebony.s...@gmai l.com said:

I encountered a simple but IMO important problem about the
C++ linkage model and One Definition Rule. Why the following
code link?

file1.cpp
int x;

file2.cpp
double x;

x was defined in two different translation units with
different types. It breaks the ODR.

The language definition doesn't require compilers to diagnose
violations of the ODR. Code like this has undefined behavior. As a
practical matter, recognizing errors like this is expensive, given
C++'s separate compilation model.

And the relatively low quality of most linkers. It wouldn't be
very hard to implement, if the linker supported it. For
historical reasons, most linkers don't.

--
James Kanze (GABI Software) email:james.kan ze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

[ebony.soft@gmail.com]

Re: ODR: A simple question

On Sep 29, 2:17 pm, Pete Becker <p...@versatile coding.comwrote :

On 2008-09-29 06:01:07 -0400, ebony.s...@gmai l.com said:
>
>
>

I encountered a simple but IMO important problem about the C++ linkage
model and One Definition Rule. Why the following code link?

>

file1.cpp
int x;

>

file2.cpp
double x;

>

x was defined in two different translation units with different types.
It breaks the ODR.

>
The language definition doesn't require compilers to diagnose
violations of the ODR. Code like this has undefined behavior. As a
practical matter, recognizing errors like this is expensive, given
C++'s separate compilation model.
>
--
  Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of "The
Standard C++ Library Extensions: a Tutorial and Reference
(www.petebecker.com/tr1book)

Sorry for a day delay. I was out of office.
Thank you pete for you answer, but I didn't completely convince.
I thought may be some standard conversions were made (double to int or
vice versa)
I changed double to std::string, but program run. Just when I declare
the variable
with extern, I have to specifiy the type and compiler find the real
type.
Which clause or section of C++ standard draft mention your answer?

Regards,
- Saeed Amrollahi

[ebony.soft@gmail.com]

Re: ODR: A simple question

On Sep 29, 4:44 pm, James Kanze <james.ka...@gm ail.comwrote:

On Sep 29, 1:17 pm, Pete Becker <p...@versatile coding.comwrote :
>

On 2008-09-29 06:01:07 -0400, ebony.s...@gmai l.com said:

I encountered a simple but IMO important problem about the
C++ linkage model and One Definition Rule. Why the following
code link?
file1.cpp
int x;
file2.cpp
double x;
x was defined in two different translation units with
different types.  It breaks the ODR.

The language definition doesn't require compilers to diagnose
violations of the ODR. Code like this has undefined behavior. As a
practical matter, recognizing errors like this is expensive, given
C++'s separate compilation model.

>
And the relatively low quality of most linkers.  It wouldn't be
very hard to implement, if the linker supported it.  For
historical reasons, most linkers don't.
>
--
James Kanze (GABI Software)             email:james.ka. ..@gmail.com
Conseils en informatique orientée objet/
                   Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Sorry for a day delay. I was out of office.
Thank you for your answer. AFAIR, Stroustrup mentioned the poor
quality of linkers in 1st edition
of his book. Where can I find, C++ Linker specific information?

Regards,
Saeed Amrollahi

[Triple-DES]

Re: ODR: A simple question

On 30 Sep, 19:58, ebony.s...@gmai l.com wrote:

On Sep 29, 2:17 pm, Pete Becker <p...@versatile coding.comwrote :

On 2008-09-29 06:01:07 -0400, ebony.s...@gmai l.com said:

>

I encountered a simple but IMO important problem about the C++ linkage
model and One Definition Rule. Why the following code link?

>

file1.cpp
int x;

>

file2.cpp
double x;

>

x was defined in two different translation units with different types..
It breaks the ODR.

>

The language definition doesn't require compilers to diagnose
violations of the ODR. Code like this has undefined behavior. As a
practical matter, recognizing errors like this is expensive, given
C++'s separate compilation model.

>
Sorry for a day delay. I was out of office.
Thank you pete for you answer, but I didn't completely convince.
I thought may be some standard conversions were made (double to int or
vice versa)
I changed double to std::string, but program run. Just when I declare
the variable
with extern, I have to specifiy the type and compiler find the real
type.
Which clause or section of C++ standard draft mention your answer?
>

See 3.2 One definition rule [basic.def.odr]

Regards,
  - Saeed Amrollahi

[James Kanze]

Re: ODR: A simple question

On Sep 30, 8:06 pm, ebony.s...@gmai l.com wrote:

On Sep 29, 4:44 pm, James Kanze <james.ka...@gm ail.comwrote:

On Sep 29, 1:17 pm, Pete Becker <p...@versatile coding.comwrote :

On 2008-09-29 06:01:07 -0400, ebony.s...@gmai l.com said:
I encountered a simple but IMO important problem about the
C++ linkage model and One Definition Rule. Why the following
code link?
file1.cpp
int x;
file2.cpp
double x;
x was defined in two different translation units with
different types. It breaks the ODR.
The language definition doesn't require compilers to
diagnose violations of the ODR. Code like this has
undefined behavior. As a practical matter, recognizing
errors like this is expensive, given C++'s separate
compilation model.

And the relatively low quality of most linkers. It wouldn't
be very hard to implement, if the linker supported it. For
historical reasons, most linkers don't.

Thank you for your answer. AFAIR, Stroustrup mentioned the poor
quality of linkers in 1st edition
of his book.

Yes. C++ was originally designed to use existing linkers, with
a minimum of additional baggage. (There was, IIRC, always a
"pre-linker", which generated the code for dynamic
initialization. But that was it.)

Today, of course, templates require a lot more support, and much
of it could be used to allow greater freedom elsewhere as well.

Where can I find, C++ Linker specific information?

To tell the truth, I don't know. Linkers seem to be the poor
relative in the language translation area: you'll find all sorts
of information concerning compiler theory and the like, but very
little about linkers.

I think the question has been raised once or twice in
comp.compilers; you might try there. (Not because the question
is off subject here, but because that's where the people who
actually work on these things hang out.)

--
James Kanze (GABI Software) email:james.kan ze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34