* Eric Blake wrote on Tue, Mar 17, 2009 at 03:34:35PM CET:
>
> Ralf brought up an interesting point - how often do people mix C
and C++
> compilers of different origins, and expect things to work? In other
> words, it seems to me that the most common use case is that you
either
> stick with the vendor compiler in all cases (hence the workaround
for the
> Sun compiler),
If that were the only use case, then the Sun issue (the one reported a
couple of weeks ago, not the one for older Sun suite versions) could
have been fixed in a simpler way: by trying _Restrict first.
> or you use gcc in all cases. But if we're mistaken, and
> people really DO want to mix vendor C and g++ (or vendor C++ and
gcc),
> then we must either entirely avoid restrict in C++, or else we
must indeed
> make AC_C_RESTRICT perform additional testing inside an
> AC_LANG_PUSH([C++])/AC_LANG_POP block, if the configure script does
> anything for C++.
FWIW, this issue comes up more generally at times. For example,
several
bits in Libtool implicitly assume the compilers are from the same
suite,
or at least roughly similar in that they use the same linker under the
hood. Lifting all such restrictions while still allowing to create
mixed language code is pretty difficult in general (but would be
nice to
have!).
Cheers,
Ralf