🚀 go-pugleaf

In article <3vsaaj$1gs@rover.village.org>, imp@village.org says...
>
>In article <3vo9lr$los@metro.ucc.su.oz.au>,
>John Max Skaller <maxtal@Physics.usyd.edu.au> wrote:
>>       It isn't clear it is POSSIBLE to use qsort.
>>Suppose extern "C" functions use a DIFFERENT calling convention.
>
>This sounds like another of the committee's unwise calls.  I do
>understand the issues behind it, however, there is some legacy code
>that depends on being able to call qsort from C++.
>
>>       Result: qsort may not be useable: it has to be there,
>>it doesn't have to be useful. You certainly can't assume at this
>>point in time any use of it will be portable. The final Standard
>>might provide better guarrantees, but I have doubts.
>
>This is the part that worries me the most.  Traditionally, you've been
>able to do this, and as far as I know it works on all existing
>compilers (at least the major ones I've used).  Breaking this now
>isn't the best possible service that the committee could do to the
>application developers (although it does let the compiler writers off
>the hook more easily).
>
>IMHO, if qsort is part of the language, then it must be possible to
>write extern "C" functions in C++ and have the compiler cope.  After
>all, it *KNOWS* that the function is extern "C", so it should know
>enough to have it follow the 'C' ABI should it differ from the C++
>ABI.
>
>This isn't the more subtle issue of what that ABI actually is, merely
>a requirement that C++ functions that have "C" linkage must follow
>whatever ABI that the compiler uses for those functions.  Right now
>the compiler must be able to correctly call these functions (if it
>supports a "C" ABI).  It would seem prudent to require that the
>compiler generate callable functions as well as calls to functions.
>
>Or have I missed something subtle in this thread?
>
>Warner
>-- 
>Warner Losh             "VMS Forever"           home: imp@village.org
>Cyberspace Development, Inc                     work: imp@marketplace.com
>Makers of TIA, The Internet Adapter.            http://marketplace.com/

-- 
The opinions expressed in this message are my own personal views 
and do not reflect the official views of Microsoft Corporation.

In practice existing "C" linkage is defined by the host or target system,
not by a particular compiler.  Otherwise a given compiler is going
to have an awfully hard time calling any system libraries.
Thus "C" linkage rules are neither up to
the C++ committee nor any C committee to decide.

If/when "OO" operating systems catch on, then "C++" linkage
issues [better know as the "object model" for that particular OS] 
may in turn be effectively defined by these "OO" operating
systems.  Any compiler not supporting the standard operating
system "OO" linkages, or making them a pain to use, would
be unpopular, to put it mildly.

These are not new issues, but rather have been rediscovered
many times in the past as new operating systems have come
out and caught on.  The compilers not adapting to the needs
of the operating system and programmers using those operating
systems fall behind.

Part of the trick of standardizing a language is realizing
what isn't yours to standardize.  C was successfully standardized
by leaving OS-dependent issues out of the standard.