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
