This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: threads in C++
- To: gcc at gcc dot gnu dot org, ross dot s at ihug dot co dot nz
- Subject: Re: threads in C++
- From: Mike Stump <mrs at windriver dot com>
- Date: Mon, 15 Nov 1999 18:23:48 -0800 (PST)
> Date: Tue, 16 Nov 1999 12:33:08 +1200
> From: Ross Smith <ross.s@ihug.co.nz>
> Not quite.
Well, ok, I was strictly speaking wrong. I gave the practical answer.
It is practically true. The reality is it is an implementation
detail, if there can be any linkage between two compilers. The
standard can't mandate linkability between two compilers, so in
effect, even extern "C" is implementation defined. Because extern "C"
_is_ implementation defined, and because linkage of extern "C++"
static member functions is implementation defined, strictly speaking
they are in the same class. Using extern "C" is not any more correct
than using a ststic member function in this context, strictly
speaking. Use it at your own assumed risk.
So were does that leave us? Well, the gcc/g++ implementations define
extern "C" as working between languages, and usually between releases,
though there are some exceptions. Further they define static member
functions as offering link compatibility, meaning the user can use it,
and it will work. Now, will we backpeddle on this? Hum... I guess
we might want to at some point, though I doubt we will ever need to.
I think we can evolve tracking linkages in such a way as to offer this
feature in the future, even if we might want to generate different
styles of code.
Thanks for keeping me honest.