«

Because my english is very poor,so i give my program as follow:
////////////////////////////////////////////////////////////////////////////////////
one.hpp:
#include <iostream>
#ifndef TEST
#define TEST "The first print()"
inline void print()
{
std::cout<<TEST<<std::endl;
}

#else
#undef TEST
#define TEST "the second print()"
inline void print()
{
std::cout<<TEST<<std::endl;
}
#endif /*TEST*/
///////////////////////////////////////////////////////////////////////////////////////////////////
two.hpp:
#define TEST "none"
/////////////////////////////////////////////////////////////////////////////////////////////////
unit1.cpp:
#include "one.hpp"
#include "two.hpp" //attention about sequence of two headers
void doSomething()
{
print();
}
///////////////////////////////////////////////////////////////////////////////////////////////////
unit2.cpp
#include "two.hpp"
#include "one.hpp" //attention about sequence of two headers
int main()
{
print();
}

what we can see there are two "print()"defined,and all in the globe
namespace and
why there is no error about redefine "print()"?

redriver wrote:
> /////////////////////////////////////////////////////////////////////////////////////////////////
> unit1.cpp:
> #include "one.hpp"
> #include "two.hpp" //attention about sequence of two headers

> ///////////////////////////////////////////////////////////////////////////////////////////////////
> unit2.cpp
> #include "two.hpp"
> #include "one.hpp" //attention about sequence of two headers

There's no issue with building either of these two units - print() only
gets defined once in each. If you link the units together to build an
executable, yes, you are doing something bad, but whether or not the
linker tells you this is a) up to the linker, depending on what options
you give it, and b) off-topic for this group.

redriver wrote:
> Because my english is very poor,so i give my program as follow:
> ////////////////////////////////////////////////////////////////////////////////////
> one.hpp:
> #include <iostream>
> #ifndef TEST
> #define TEST "The first print()"
> inline void print()
> {
> std::cout<<TEST<<std::endl;
> }
>
> #else
> #undef TEST
> #define TEST "the second print()"
> inline void print()
> {
> std::cout<<TEST<<std::endl;
> }
> #endif /*TEST*/
> ///////////////////////////////////////////////////////////////////////////////////////////////////
> two.hpp:
> #define TEST "none"
> /////////////////////////////////////////////////////////////////////////////////////////////////
> unit1.cpp:
> #include "one.hpp"
> #include "two.hpp" //attention about sequence of two headers
> void doSomething()
> {
> print();
> }
> ///////////////////////////////////////////////////////////////////////////////////////////////////
> unit2.cpp
> #include "two.hpp"
> #include "one.hpp" //attention about sequence of two headers
> int main()
> {
> print();
> }
>
> what we can see there are two "print()"defined,and all in the globe
> namespace and
> why there is no error about redefine "print()"?

First of all, they are declared 'inline', so the compiler has to make
sure it "merges" all definitions of it into one (if it decides to create
an "out-of-line" definition, that is). The compiler is unable (or maybe
unwilling) to check that your functions have different bodies. It is
a violation of the One Definition Rule, but sometimes violations like
this are subtle and you yourself need to watch for them.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

Victor Bazarov <> wrote:

> First of all, they are declared 'inline', so the compiler has to make
> sure it "merges" all definitions of it into one (if it decides to create
> an "out-of-line" definition, that is). The compiler is unable (or maybe
> unwilling) to check that your functions have different bodies. It is
> a violation of the One Definition Rule, but sometimes violations like
> this are subtle and you yourself need to watch for them.

I admit I didn't catch the subtleties involved with the use of
"inline". OP's code is still wrong without inline, though, correct?

I suppose the use of "inline" is what led to the linker being quiet;
in my experience, this situation is reported by the linker assuming it
is invoked with reasonable arguments.

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.

Christopher Benson-Manica wrote:
> Victor Bazarov <> wrote:
>
>> First of all, they are declared 'inline', so the compiler has to make
>> sure it "merges" all definitions of it into one (if it decides to
>> create an "out-of-line" definition, that is). The compiler is
>> unable (or maybe unwilling) to check that your functions have
>> different bodies. It is
>> a violation of the One Definition Rule, but sometimes violations like
>> this are subtle and you yourself need to watch for them.
>
> I admit I didn't catch the subtleties involved with the use of
> "inline". OP's code is still wrong without inline, though, correct?

Theoretically. The bodies of the two functions are different. That goes
against the ODR. I don't know of any compiler that would enforce that,
however.

> I suppose the use of "inline" is what led to the linker being quiet;
> in my experience, this situation is reported by the linker assuming it
> is invoked with reasonable arguments.

Then your linker if more advanced than the ones I've seen.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask