From -1426068474298165939 X-Google-Language: ENGLISH,ASCII X-Google-Thread: f78e5,ea96cc047f6a22cc X-Google-Attributes: gidf78e5,public X-Google-ArrivalTime: 2001-08-27 04:55:01 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!news.tele.dk!small.news.tele.dk!212.74.64.35!colt.net!dispose.news.demon.net!news.demon.co.uk!demon!mail2news.demon.co.uk!not-for-mail From: joerg.barfurth@attglobal.net (Joerg Barfurth) Newsgroups: comp.std.c++ Subject: Re: extern "C" -- what is the intent? Date: Mon, 27 Aug 2001 11:54:25 GMT Organization: My beloved Family Approved: Fergus Henderson , moderator of comp.std.c++ Message-ID: <1eys049.1mtaactofnng2N%joerg.barfurth@attglobal.net> References: <090820010209154805%BobbySchmidt@mac.com> <9l62tf$c2g$1@panix3.panix.com> X-Trace: mail2news.demon.co.uk 998913271 mail2news:838 mail2news mail2news.demon.co.uk X-Complaints-To: abuse@demon.net X-Mail2News-Path: news.demon.net!mulga.cs.mu.oz.au X-Authentication-Warning: mulga.cs.mu.OZ.AU: fjh set sender to devnull@stump.algebra.com using -f X-Robomod: STUMP, ichudov@algebra.com (Igor Chudov) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 User-Agent: MacSOUP/D-2.4.6 (unregistered for 412 days) Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mulga.cs.mu.OZ.AU id VAA20342 Lines: 97 Xref: archiver1.google.com comp.std.c++:7173 Hans Aberg wrote: > I am disregarding the fact that the compilers always must somehow be tu= ned > together. But that is the key point. Maybe it is the only point. You can really talk about achieving linkage only between implementations, not languages. Thus to realize what linkage specifications promise, you need implementations of the languages concerned, plus compatibility effort by at least one of the implementors.=20 For sustaining the compatibility, you either need collaboration of both or some third party defining and evolving an ABI.=20 IMO 7.5/9 says it all. > It seems me that the standard is flawed, as what is called "linkage to = the > language X" does not mean that one can actually link to code written in > the language X.=20 AFAICT it is only in 7.5/3 that the standard explicitly mentions "linking to code written in the programming language X", with "X" =3D=3D "C". Otherwise 'language linkage' is used as a technical term. It really means only that there is a string attached to each name and function type. The name simply reflects the intened use. OTOH the standard requires support for "C" language linkage, with specific changes to the semantics within C++. But it simply cannot require "that one can actually link to code written in the language C", as there needn't be any C implementation on the same platform - at least its existence shouldn't be mandated by the C++standard. > There are two ways around this: One is to change the name > to say "pseudo-linkage", so that it becomes explicitly clear that it is > merely a way for the C++ compiler can attach language labels onto the c= ode > so that the linker might use it for linking. I don't think "pseudo-linkage" captures it any better. I agree that "language linkage" raises expectations that implementations of the "linkage tag" need not fulfill. =20 > Another way would be to strengthen the requirement so that linkage to t= he > language X actually means that one can link code to that language (even > though, clearly, it still depends on the two compiler being tuned > together).=20 Would you then also require that such a compiler exists. Would a C++-implementation become nonconforming when production of the C compiler it collaborates with is terminated. > extern "C" short foo(int); > is not legal unless one has specified conversion operators > extern "C++" int -> extern "C" int > extern "C" short -> extern "C++" short Who would have to specify them where ? =20 > The spin off if forcing such conversion operators to be explicit in the > language is that the types of the different languages need not be tuned > together: In the example, it does not matter anymore that the integral > types of the two different languages are the same.=20 You still need a language in which to specify the needed bridging code. And that should be part of which language ? And once you have that, it suffices to support linkage to the bridging language on either end. > One could also go a > step further, and use it to tune together different compilers of the sa= me > language, that is, if it is somehow possible to indicate in the "extern= " > declaration the name of the compiler. I don't think there is anything to prevent this now. In fact I think you could make a fully conforming compiler that additionally supports 'extern "g++ 3.0"', 'extern "WinAPI"' or 'extern "stdcall"=B4'.=20 Regards, J=F6rg --=20 J=F6rg Barfurth joerg.barfurth@attglobal.net <<<<<<<<<<<<< using std::disclaimer; <<<<<<<<<<<<<<<<<<<<<<<<<<<< Software Developer http://www.OpenOffice.org StarOffice Configuration http://www.sun.com/staroffice --- [ comp.std.c++ is moderated. To submit articles, try just posting with ] [ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ] [ --- Please see the FAQ before posting. --- ] [ FAQ: http://www.research.att.com/~austern/csc/faq.html ]