🚀 go-pugleaf

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/