This is the mail archive of the
mailing list for the GCC project.
Re: Minimal GCC/Linux shared lib + EH bug example
----- Original Message -----
From: "Martin v. Loewis" <firstname.lastname@example.org>
> "David Abrahams" <email@example.com> writes:
> > > and not allowing static
> > > members in templates might be acceptable
> > !! absolutely not acceptable !!
> > Do you really mean "not allowing", here? The use of static members in
> > templates (known to probably not be shared) is one of the primary ways
> > get around the problems we're discussing. I routinely declare static
> > reference members and initialize them through function calls to my
> > library. Once static initialization is done, they all refer to the
> > piece of data. If I couldn't do that, I'd be royally shafted.
> Are you saying you rely on the fact that static members of template
> classes are not shared across multiple instantiations of the same
> template? T
No, I'm saying that I'm relying on being *allowed* to use them, and I don't
happen to care whether they're shared in this case. For example:
SomeClass& get_x(char const*);
// lib2.hpp, lib3.hpp, lib4.hpp
template <class T>
static int& x;
template <class T> int& object<T>::x = get_x(typeid(T).name());
...something which instantiates object<X>::x...
int& get_x(char const* s)
static map<char const*, int, compare_strings> m;
> The C++ standard is very clear about that all instantiations
> ought to refer to the same variable.
And it's very unclear about what to do with shared libraries. We in the
comittee are just starting to tackle that one, and I am confident we are
not going to require the ODR be preserved in cases where symbols are not
> Mark's point is, that, from the position of a compiler vendor, it is
> unacceptable to declare a feature as "supported", when there are usage
> restrictions on that feature in clear violation of the standard.
>From the point of view of the standard, shared libraries are not covered; a
vendor is in the territory of extensions, and any behavior is allowed. What
you can call "supported" is up to QOI.
> Also, how do you think you can initialize the static template member?
> Through function calls of the class template? Forget it, that might
> not work - you are relying here on functions being emitted together
> with the instantiation of the static member, and there is no guarantee
> that this will work.
I have no idea what the above might mean. I do not happen to be calling the
class template's own function members to initialize its data, but I can't
imagine how it would be a problem unless I were relying on sharing or
not-sharing... But I'm not.
> > Right. Also, let me point out that exceptions and RTTI deserve special
> > treatment because workarounds like the one described above are not
> > available.
> Ok, then what about block-local static variables in inline function,
> and in template functions?
These /are/ susceptible to the same sort of workaround, using references
(an extra level of indirection, the classic approach!) I wouldn't expect to
see a unique copy unless all instantiating libraries share symbols globally