Andrew Pinski wrote: > Well this allows for easier violating of ODR. I guess I am just a bit > off of what is going on here but I agree with Chris in that this > really should be rejected as you have stuff which is hidden and then > you call a non hidden member function. How can the vtable be hidden > while the member functions not be? I think if you try to throw that > class across boundaries, it will never be caught as the typeinfos are > different.
There's nothing that says that the class even has a vtable. Or, this might be a static member function. Obviously, if that function tries to access the vtable, it will fail to link -- but it might very well not need to access the hidden stuff. > So really I think this is just bad pratice and should at least get a > warning, even though code in real life exists, the code is broken to > say the least. I'm not sure why you say that the code is broken. It works. As far as I know it doesn't violate any specification. What's broken about it? This is valid: void f() __attribute__((visibility("hidden"))); void g() __attribute__((dllimport)); void f() { g(); }; So is: struct S { void f() __attribute__((visibility("hidden")); void g() __attribute__((dllimport)); }; void S::f() { S::g(); }; So, why not: struct S __attribute__((visibility("hidden")) { void f(); void g() __attribute__((dllimport)); }; void S::f() { S::g(); }; In any case, in practice, ARM's RealView compiler accepts: struct __declspec(notshared) S { __declspec(dllimport) void f(); void g(); }; void S::g() { f(); } And, there's a large body of code that uses this. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713