RE: RFC: Make dllimport/dllexport imply default visibility

[Danny Smith <dannysmith at clear dot net dot nz>]

> -----Original Message-----
> From: gcc-owner@gcc.gnu.org [mailto:gcc-owner@gcc.gnu.org] On 
> Behalf Of Mark Mitchell
> Sent: Saturday, 16 June 2007 11:47 a.m.
> 
> 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.  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.
> 
>


In windows dll's the default visibility of a symbol is hidden (GNU ld as
--export-all-extension to override this default, but that is not the
compiler's fault). 
So this, in a dll module source:
>> Consider:
>>
>>  struct __attribute__((vsibility ("hidden"))) S {
>>    void __declspec(dllimport) f();
>>  };

is equivalent to 

>>  struct __attribute__ S {
>>    void __declspec(dllimport) f();
>>  };


And certainly that is meaningful  on window's  targets

Danny