This is the mail archive of the 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: Minimal GCC/Linux shared lib + EH bug example

----- Original Message -----
From: "Martin v. Loewis" <>

> "David Abrahams" <> 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:

// lib1.hpp
#include <typeinfo>
SomeClass& get_x(char const*);

// lib2.hpp, lib3.hpp, lib4.hpp
#include "lib1.hpp"
 template <class T>
struct object
    static int& x;
template <class T> int& object<T>::x = get_x(typeid(T).name());

// lib2.cpp
...something which instantiates object<X>::x...

#include <map>
#include lib2.hpp
int& get_x(char const* s)
    static map<char const*, int, compare_strings> m;
    return m[s];

> 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
with one-another.


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