In article <sjcD7AuA9.AEB@netcom.com>, Steven Correll <sjc@netcom.com> wrote:
>Steve Clamage (clamage@Eng.Sun.COM) wrote:
>: Further, if no FORTRAN compiler exists at all on that platform, what does
>: it mean to require that the C++ compiler support 'extern "FORTRAN"'? How
>: could a validation suite test it? It is very bad practice for a standard to
>: require something that cannot be verified.
>
>To carry this reasoning to its logical extremity, it's bad practice for the
>standard to require 'extern "C"', because it is untestable on a platform
>which lacks an ISO C compiler...

Speaking as a tester, I agree 100% with what Steve correll said, except
that he didn't go far enough.  It is untestable even on a platform which
_does_ have a C compiler, because the C++ standard doesn't specify what
does or doesn't constitute a valid (external) C translation unit.

--

-- Ron Guilmette, Sunnyvale, CA ---------- RG Consulting -------------------
---- E-mail: rfg@segfault.us.com ----------- Purveyors of Compiler Test ----
---- finger: rfg@rahul.net ----------------- Suites and Bullet-Proof Shoes -

You can consider 'extern "C"' as something specific to C++,
in a way extern "C" says : Well... this interface must be simpler
written in the subset of language I call "C".
You can test such headers with only a C++ compiler
(by checking domainname conflicts i.e. voluntary errors).
You don't really need to suppose there is anything outside like
an ISO C compiler.

extern FORTRAN is another matter. Could it mean something internal to C++ ?
If not it should be a #PRAGMA, not a part of the language.

Steve Clamage (clamage@Eng.Sun.COM) wrote:
: Further, if no FORTRAN compiler exists at all on that platform, what does
: it mean to require that the C++ compiler support 'extern "FORTRAN"'? How
: could a validation suite test it? It is very bad practice for a standard to
: require something that cannot be verified.

To carry this reasoning to its logical extremity, it's bad practice for the
standard to require 'extern "C"', because it is untestable on a platform
which lacks an ISO C compiler. (Perhaps one should not be allowed to implement
an ISO C++ compiler without first implementing an ISO C compiler. :-)) And
consider the C++ implementor's plight on a platform which supports multiple
implementations of ISO C which have mutually incompatible calling conventions.

I look forward to reading the language of the draft standard to see whether
the committee has found wording that manages to render 'extern "C"' any less
meaningless than 'extern "Fortran"' would be.
--
Steven Correll == PO Box 66625, Scotts Valley, CA 95067 == sjc@netcom.com

In article <3m15mt$rec@engnews2.eng.sun.com>,
Steve Clamage <clamage@Eng.Sun.COM> wrote:
>Finally, on a practicality note, virtually all (if not in fact all) systems
>which have both FORTRAN and C provide a mechanism for mixing the two
>languages. A C++ program can then access FORTRAN (and vice versa) in
>exactly the same way C does.

    Yes, in exactly the same unportable, error-ridden (does that '_' go
*before* or *after* the name, if it goes at all? Does it get capitalized or
lowercased? etc.) way that C does.

    It's at best misleading to say that "virtually all systems ... provide a
mechanism". Yes, there's usually some way to do it. No, it's usually not
documented in any obvious fashion (if at all).

    Jon
    __@/

In article gq6@fermat.mayo.edu, stan@chirpa.mayo.edu (Andrew Staniszewski) writes:
>
>The c++ language already has an interface to a another language, ie:
>
>extern "C" int func(...);
>
>since the compiler writer for a particular platform can easily handle the
>conversions for functions calls (I admit that for character data this may
>prove inefficient, but there again, I believe so would a user implimentation.)
>since the fortran compilers are (as far as I have seen) compatible for at least
>a particular platform, why not provide specifically for
>
>extern "FORTRAN" int func(...);

C++ is very closely related to C, and one design goal was to allow easy
migration from C to C++. Thus, a C++ program must have access to and from
C functions.

The linkage specification uses a string to specify a language.
An implementation must recognize "C" and "C++". It is allowed but not
required to recognize other languages as well.

If we require an implementation to recognize FORTRAN, then it gets hard
to know when to stop. What about COBOL, Pascal, Modula (-2, -3),
Ada, LISP, PL/I, ML, or <your favorite language here>?

Further, if no FORTRAN compiler exists at all on that platform, what does
it mean to require that the C++ compiler support 'extern "FORTRAN"'? How
could a validation suite test it? It is very bad practice for a standard to
require something that cannot be verified.

Finally, on a practicality note, virtually all (if not in fact all) systems
which have both FORTRAN and C provide a mechanism for mixing the two
languages. A C++ program can then access FORTRAN (and vice versa) in
exactly the same way C does. The 'extern "C"' requirement ensures that.

---
Steve Clamage, stephen.clamage@eng.sun.com