470,849 Members | 1,344 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 470,849 developers. It's quick & easy.

Is this right??Is redefine??

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()"?

May 10 '06 #1
4 1637

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.

May 10 '06 #2
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
May 10 '06 #3
Victor Bazarov <v.********@comacast.net> 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.
May 12 '06 #4
Christopher Benson-Manica wrote:
Victor Bazarov <v.********@comacast.net> 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
May 12 '06 #5

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

3 posts views Thread by junlia | last post: by
25 posts views Thread by paytam | last post: by
10 posts views Thread by Amber | last post: by
16 posts views Thread by Prayag Narula | last post: by
3 posts views Thread by Ernie.Pasveer | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.