Re: RFC: Make dllimport/dllexport imply default visibility

[Chris Lattner <clattner at apple dot com>]

On Jun 15, 2007, at 4:47 PM, Mark Mitchell wrote:
> Chris Lattner wrote:
> > This construct seems like it should be rejected by the C++ front-end.
> > The source is making two contradictory claims: the struct is not  
> > visible
> > outside this library, but part of it is implemented outside of it.
>
> I don't think there's a contradiction.  The declaration on the  
> structure
> is the default for the members and applies to the vtable and other  
> class
> data.

If we separate implementation details from the logical semantics, I  
see that anonymous namespaces and hidden visibility, when applied to  
a type, global impact the visibility of the type.  If the *type* is  
hidden, no members of that type, nor any other functions/methods that  
take or refer to it, should be able to be dllimport.

In your example:

> So, why not:
>
>   struct S __attribute__((visibility("hidden")) {
>     void f();
>     void g() __attribute__((dllimport));
>   };
>   void S::f() { S::g(); };

This may happen to work, but remember that there is an implicit  
"this" pointer in "g".  Regardless of whether "g" dereferences the  
this pointer, it still takes one.  I agree with Andrew that it is an  
ODR violation, regardless of whether these cases happen to not get  
caught in some cases.  The this pointer in S::f and the this pointer  
in S::g are two different types.

> I'm not sure why you say that the code is broken.  It works.

"working" and "making sense" are two different things :)


> As far as I know it doesn't violate any specification.

Is there any formal spec at all that defines dllimport, hidden  
visibility, and their interaction?


> There's no reason the members shouldn't be implemented elsewhere,
> and there's certainly existing code (in Windows, SymbianOS, and other
> DLL-based operating systems, whether or not there is on GNU/Linux)  
> that
> implements different class members in different DLLs, while still not
> exporting the class from its home DLL.  One situation where this is
> useful is when the class members are actually shared between multiple
> classes, or are also callable as C functions, etc.

IMO, regardless of whether this is accepted by other compilers, this  
is a serious logical inconsistency and should be rejected by  
default.  For compatibility with other compilers, I agree that it  
would be reasonable to add a compatibility flag to enable this more  
lenient behavior.

-Chris