This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFC: Make dllimport/dllexport imply default visibility



On Jun 19, 2007, at 7:49 AM, Richard Earnshaw wrote:


On Mon, 2007-06-18 at 10:04 -0700, Mark Mitchell wrote:
I suspect that the realview compiler accepts
this as an oversight or a bug, not as an intentional feature.

Let's ask.


Richard E., is the fact that RealView 3.0SP1 accepts:

  class __declspec(notshared) S {
    __declspec(dllimport) void f();
  };

a bug or a feature? If this is considered a bug, is it something that
RealView is likely to change in a future release, or will it be
preserved for the forseeable future for backwards compatibility?

This is well beyond my sphere of expertise, so I've asked one of the
original developers of the spec. He asserts that the above is supported
and intentional. Hopefully I've correctly represented his position
below.


His key point is that 'notshared' on a class is not the same as making
the whole class hidden: only the class impedimenta (vtables, rtti) is
hidden, but the rest of the class can be exported as normal.  And that
since it can be exported, there's no reason why definitions of member
functions can't be imported.

This description also makes sense, but is different than what was described before. To me, this description/implementation is extremely problematic, because the extension cannot be described without describing the implementation (specifically presence of vtables etc), which is unlike any standard C++ feature.


Some more specific questions:

1. If a class is hidden, does that default all the members (not just the metadata) to be notshared?
2. If a class with vtable is hidden, what visibility constraints exist on virtual methods?
3. What does 'notshared' on a class without a vtable mean, what effect does it have?
4. If classes with vtables have different behavior than those without, is this something we want?
5. How does this impact the ODR?


-Chris


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]