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: Minimal GCC/Linux shared lib + EH bug example


"David Abrahams" <david.abrahams@rcn.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 I
> get around the problems we're discussing. I routinely declare static
> reference members and initialize them through function calls to my shared
> library. Once static initialization is done, they all refer to the right
> 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? The C++ standard is very clear about that all instantiations
ought to refer to the same variable.

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.

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.

> 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?

Regards,
Martin


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