From -2225652905458255266 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: f78e5,ea96cc047f6a22cc X-Google-Attributes: gidf78e5,public X-Google-ArrivalTime: 2001-08-11 16:09:06 PST Path: archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!newsfeeds.belnet.be!news.belnet.be!newsfeed2.news.nl.uu.net!sun4nl!bullseye.news.demon.net!news.demon.nl!demon!mail2news.demon.nl!not-for-mail From: Scott Meyers Newsgroups: comp.std.c++ Subject: Re: extern "C" -- what is the intent? Date: Sat, 11 Aug 2001 23:07:05 GMT Organization: Scott Meyers Approved: Fergus Henderson , moderator of comp.std.c++ Message-ID: References: <090820010209154805%BobbySchmidt@mac.com> X-Trace: mail2news.demon.nl 997571312 mail2news:14013 mail2news mail2news.demon.nl 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) X-Newsreader: MicroPlanet Gravity v2.30 Lines: 87 Xref: archiver1.google.com comp.std.c++:6945 On Thu, 9 Aug 2001 18:26:15 GMT, Bobby Schmidt wrote: > To support his argument, Scott draws connections between subclauses 3.5 > and 7.5 that make me a bit nervous. Well duh. He's the MSDN columnist in charge of C# and he's nervous about the C++ Standard? :-) :-) :-) Anyway, here's the argument I sent to Bobby in response to his current CUJ column: I don't think your discussion of the semantics of extern "C" holds water. Let me explain why I care. This is from Item 34 of More Effective C++: The best way to view extern "C" is not as an assertion that the associated function is written in C, but as a statement that the function should be called as if it were written in C. (Technically, extern "C" means the function has C linkage, but what that means is far from clear. One thing it always means, however, is that name mangling is suppressed.) ... You can even declare C++ functions extern "C". This can be useful if you're writing a library in C++ that you'd like to provide to clients using other programming languages. As you can see, I have a vested interest in this issue. Linkage is defined in 3.5, where it's clear that linkage is a property of a name. In particular, there is nothing said about it being a relationship between two entities (except for 3.5/11, which I'll get to in a minute). Hence it makes no sense to say that X links to Y or Y links to X. Rather, X may have linkage and Y may have linkage. Linkage matters only for name lookup; whether a name is found during linking depends in part on the linkage of that name. 3.5/11 brings up the notion of linking "to" declarations for entities written in other languages. But what does this mean? Given the rest of 3.5, it can mean only one thing: when name lookups occur during linking, the names found may correspond to entities implemented by other languages. That is, 3.5/11 does nothing more than suggest that a C++ program may include entities implemented in languages other than C++. Let us thus trot off to 7.5. 7.5/2 introduces the notion of linkage "between" code fragments. Note that according to the usual rules of English, "between" is commutative: if X is between a and b, X is also between b and a. Hence, 7.5/2 could just as easily have been started this way: "Linkage between non-C++ and C++ code fragments..." (As an aside, my favorite part of 7.5/2 is "The semantics of a language linkage other than C++ or C are implementation-defined." Where does the Standard define the semantics of C++ and C linkage, especially given 7.5/9? On this matter, I stand by my statement in MEC++ above.) Of course, 7.5/3 is key. It requires support for "linkage to functions written in the C programming language." But 3.5 makes clear that linkage affects only the ability to perform name lookup during linking. I thus read 7.5/3 this way: If you assign "C" linkage to an entity written in C++, that entity can be found (via name lookup) during linking to functions written in the C programming language. Thus, declaring a C++ function extern "C" is a way of making it callable from C, as far as the Standard is concerned. As you point out in your column (and I point out at the beginning of MEC++ Item 34), there's a lot of stuff the Standard is NOT concerned with, but I think it's clear that extern "C" is indended to allow exactly the kind of thing that Phil Brooks and Jon Young said it was (provided the underlying C and C++ object models are compatible). Scott PS - Given what I think is less than crystal-clear wording in the Standard on this topic, it was my suggestion that Bobby attempt to discern the *intent* of the people who wrote the Standard. His posting is presumably at attempt to divine that intent. -- Check out "THE C++ Seminar," http://www.gotw.ca/cpp_seminar/ Also check out "Effective STL," http://www.aw.com/estl/ --- [ 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 ]