In 3.2/3 [basic.def.odr] the standard says:

Every program shall contain exactly one definition of every non-inline function
or object that is used in that program; no diagnostic required.

There are two error cases:
    [1] Some non-inline function or object that is used has no definition.
            Why is no diagnostic required?

    [2] Some non-inline function or object that is used has more than one
definition.
            Why is no diagnostic required?

Neither of these (especially the first) seems difficult to diagnose at link-time
(2.1/9).  I guess the second case could be harder in the presence of dynamically
loaded libraries.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In article <9c6hv0$5o6$1@cam-news1.cambridge.arm.com>, scott douglass
<sdouglass@arm.com> writes
>    [2] Some non-inline function or object that is used has more than one
>definition.
>            Why is no diagnostic required?
>
>Neither of these (especially the first) seems difficult to diagnose at link-time
>(2.1/9).  I guess the second case could be harder in the presence of dynamically
>loaded libraries.

No, it is difficult in the presence of libraries. The normal method is
that these are searched sequentially to satisfy outstanding
requirements, once one of these has been satisfied it becomes irrelevant
that another library could also have satisfied it. Yes we can design
intelligent linkers that handle this problem, but it was the judgement
of the Standard's Committees that is was unreasonable to require this.


Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

"scott douglass" <sdouglass@arm.com> wrote in message
news:9c6hv0$5o6$1@cam-news1.cambridge.arm.com...
> In 3.2/3 [basic.def.odr] the standard says:
>
> Every program shall contain exactly one definition of every non-inline
function
> or object that is used in that program; no diagnostic required.
>
> There are two error cases:
>     [1] Some non-inline function or object that is used has no definition.
>             Why is no diagnostic required?
>
>     [2] Some non-inline function or object that is used has more than one
> definition.
>             Why is no diagnostic required?
>
> Neither of these (especially the first) seems difficult to diagnose at
link-time
> (2.1/9).  I guess the second case could be harder in the presence of
dynamically
> loaded libraries.

IMO because the standard defines the translator, not the linker. And, as you
noted, diagnostics for these cases are easy ... at link time.

--

Andrea Ferro

---------
Brainbench C++ Master. Scored higher than 97% of previous takers
Scores: Overall 4.46, Conceptual 5.0, Problem-Solving 5.0
More info http://www.brainbench.com/transcript.jsp?pid=2522556



---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In article <qNOPv4AY9+56Ewdl@ntlworld.com>,
Francis Glassborow  <francisG@robinton.demon.co.uk> wrote:
>In article <9c6hv0$5o6$1@cam-news1.cambridge.arm.com>, scott douglass
><sdouglass@arm.com> writes
>>    [2] Some non-inline function or object that is used has more than one
>>definition.
>>            Why is no diagnostic required?
>>
>>Neither of these (especially the first) seems difficult to diagnose at link-time
>>(2.1/9).  I guess the second case could be harder in the presence of dynamically
>>loaded libraries.
>
>No, it is difficult in the presence of libraries. The normal method is
>that these are searched sequentially to satisfy outstanding
>requirements, once one of these has been satisfied it becomes irrelevant
>that another library could also have satisfied it. Yes we can design
>intelligent linkers that handle this problem, but it was the judgement
>of the Standard's Committees that is was unreasonable to require this.

And sometimes programmers intentionally have duplicates among libraries and
object modules.  For instance, there are many versions of malloc()
available with different features (such as allowing the programmer to
designate a region of memory to be used as the heap, or to add debugging
features), and it's common to override the one in the standard C library
simply by putting something like -lmalloc in the linker options.  We don't
want the linker to complain "Duplicate definition of malloc()" when doing
this.

--
Barry Margolin, barmar@genuity.net
Genuity, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]