«

two class with same name exist in different dynamic linked library:

a.so
class REGION() {
public:
....
~REGION() {}
}

b.so
class REGION() {
public:
....
~REGION() {}
}

this breaks ODR ?

my problem is that a.so's ~REGION be linked to b.so's ~REGION
defination. moving the defination of ~REGION in a.so to a .cxx, wrongly
linked reverse (why not inline ~REGION()?)

thanks

scl wrote:
> two class with same name exist in different dynamic linked library:
>
> a.so
> class REGION() {
> public:
> ...
> ~REGION() {}
> }
>
> b.so
> class REGION() {
> public:
> ...
> ~REGION() {}
> }
>
> this breaks ODR ?
>
It's not even syntactically correct.

If the two class definitions aren't identical, it is a violation.

REGION::~REGION is supposed to be a unique concept. C++ knows
nothing of DLL's.

Why is that ron

If the classes are in different headers and no other translation unit
includes both headersI would assume it would ok to do so.

Raj

<> skrev i en meddelelse
news: ups.com...
> Why is that ron

First of all because the standard says so.
>
> If the classes are in different headers and no other translation unit
> includes both headersI would assume it would ok to do so.
>
It surely is not. Even if a destructor is inlined, the compiler is not
required to inline the code. The result could be multiple definitions
resulting in linker-errors.
But again: the important thing is that multiple definitions simply are not
allowed.

> Raj
>

/Peter

wrote:
> ...
> If the classes are in different headers and no other translation unit
> includes both headersI would assume it would ok to do so.
> ...

In C++ classes declared in non-local scope have external linkage. Which
means (for classes) that you can define a class with the same name in
the same scope more than once (in different translation units), but all
definitions must be exactly the same. You violated that requirement,
which caused the original problem.

--
Best regards,
Andrey Tarasevich

If a.so and b.so are dynamic library files, You are mixing the concept in
different domain. There are only *OBJECTS*(or say instances, or symbols) of
classes, variables or functions in dynamic libary file. It's impossible that
any definition could exist in a dynamic library file.

But I notice that you mentioned:
moving the defination of ~REGION in a.so to a .cxx
This let me believe that a.so is a source code file rather than a dynamic
library file, if this is true, I don't understand your question.




"scl" <>
??????: groups.com...
> two class with same name exist in different dynamic linked library:
>
> a.so
> class REGION() {
> public:
> ...
> ~REGION() {}
> }
>
> b.so
> class REGION() {
> public:
> ...
> ~REGION() {}
> }
>
> this breaks ODR ?
>
> my problem is that a.so's ~REGION be linked to b.so's ~REGION
> defination. moving the defination of ~REGION in a.so to a .cxx, wrongly
> linked reverse (why not inline ~REGION()?)
>
> thanks
>

wrote in news:1111242480.908558.86670
@o13g2000cwo.googlegroups.com:

> Why is that ron
>
> If the classes are in different headers and no other translation unit
> includes both headersI would assume it would ok to do so.

However, from a C++ point of view, when you end up dynamically loading both
DLLs into your program, you are effectively linking the two translation
units together. At that point you have a name collision.

This one aspect of things that namespaces solve. If they were in different
namespaces, the decorated name would be different (somehow... it's up to
the compiler/linker to figure it out).

yes, it's runtime problem; it's O.K. for compilation


....
dlopen(a.so)
dlopen(b.so)
....
//here in a.so new and delete REGION objects, but call ~REGION in b.so
....
//here I can NOT dlclose(a.so)
....
//here in b.so new and delete REGION objects, but may call ~REGION in
a.so
....

> yes, it's runtime problem; it's O.K. for compilation
>
>
> ...
> dlopen(a.so)
> dlopen(b.so)
> ...
> //here in a.so new and delete REGION objects, but call ~REGION in b.so
> ...
> //here I can NOT dlclose(a.so)
> ...
> //here in b.so new and delete REGION objects, but may call ~REGION in
> a.so
> ...

This makes sense now, normally to handle C++ dynamic library with dlopen,
you have to create *create* and *destroy* interfaces at least for using
classes in DLL file, if you do like your example, dlopen will not work
properly.

For example:
In a.so's source you should define:
extern "C" {
REGION* create_A_Region() {return new REGION;}
void destroy_A_Region(REGION*) {delete pRegion;}
}
In b.so's source:
extern "C" {
REGION* create_B_Region() {return new REGION;}
void destroy_B_Region(REGION*) {delete pRegion;}
}