> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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
