用相同的函数签名链接两个强函数符号的结果使用g ++，为什么？

Question

I am confused about the linking procedure when linking two same function symbol.

point.h:

#ifndef _POINT_H_
#define _POINT_H_

struct dpoint_t
{
    /* data */
    double x, y;
};

struct ipoint_t
{
    /* data */
    int x, y;
};

#ifdef DOUBLE_POINT
    typedef struct dpoint_t data;
#else
    typedef struct ipoint_t data;
#endif

struct Point
{
    data p;
    int idx;
};
/*
#ifndef DOUBLE_POINT
__attribute__ ((weak)) 
#endif
*/
void * get_y(struct Point &x);

#endif

point.cpp:

#include "point.h"


void * get_y(struct Point &pt)
{
    int a = 1;
    return &(pt.p.y);
}

test.cpp:

#include <stdio.h>
#include "point.h"

int main()
{
    struct Point x;
    x.p.x = 10.0;
    x.p.y = 5.0;
    void *p = get_y(x);
    printf("double: %lf\nint: %d\n", *(double *)p, *(int *)p);
    return 0;
}

I get two objects by

g++ -o double_point -DDOUBLE_POINT -c point.cpp
g++ -o int_point -c point.cpp

and let use g++ to link them together with test.cpp

My question is:

why I can link them successfully, I mean there are 2 same symbol, why ld doesn't get error

I think if I use weak symbol on one of the functions, the linking result will always be the strong function symbol, but the result doesn't change, it always be the symbol that come first, I want to know why

my compiler:

GNU C++ version 3.4.5 20051201 (Red Hat 3.4.5-2) (x86_64-redhat-linux) compiled by GNU C version 3.4.5 20051201 (Red Hat 3.4.5-2).

GNU assembler version 2.15.92.0.2 (x86_64-redhat-linux) using BFD version 2.15.92.0.2 20040927

Answer 1

Have a look to the following links :

C++: Different classes with the same name in different translation units

http://en.wikipedia.org/wiki/One_Definition_Rule

Answer 2

You are violating the One Definition Rule, and thus causing undefined behavior. While I understand what you might be wanting to do, the fact is that your code is wrong and the compiler toolchain does not need to provide any specific behavior.

What is the real problem you want to solve? Because this is clearly not the way to the solution.