🚀 go-pugleaf

In article <27E765DF.12BD@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes:
|According to jimad@microsoft.UUCP (Jim ADCOCK):
|>In article <27E01E50.64DF@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes:
|>|
|>|   f1.c:
|>|      main() { blah("howdy"); }
|>|
|>|   f2.c:
|>|      #include <stdio.h>
|>|      blah(void *p) { puts(p); }
|>
|>If this *is* a language issue -- then it points out that the issue
|>of whether or not char* and void* has the "same representation" or not 
|>is moot -- because in C++ this example would fail to link ...
|
|Wrong on both points.  Declare blah() as 'extern "C"' in both modules,
|and this example will link (and run) just fine.  Or do you wish to
|wave a magic wand and make 'extern "C"' go away, too?

No I don't want to make 'extern "XYZ"' go away -- I just want people
to recognize such for what it is -- a totally implementation dependent
section of code that cannot be properly consider "C++" code.

Especially note that on vendor systems that don't have a matching C compiler,
an 'extern "C"' section would be meaningless -- except they might 
choose to make such a declaration a NO-OP, just in the odd chance that
they might be able to accept such code "successfully."

Again, I point out that 'extern "XYZ"' sections must be considered
strictly implementation dependent, and thus cannot be rightly considered
"C++" code.  If FooBar Corp creates a C++ compiler with some implementation
dependent features, and someone writes code making use of those 
implementation features, is that "C++" code?  I claim that only
the portable parts of the code can be considered "C++" -- the rest
of the code is more properly thought of as "FooBar" code.  "C++" is
that relatively small part of a totally compiler implementation that
the vast majority of independent compiler vendors and C++ programmers
can agree on.

On some systems 'extern "XYZ"' will need to do more than change the 
mechanisms of name mangling -- it may also change link mechanisms,
calling conventions, word sizes, keyword extensions recognized, etc.
Thus, as far as I'm concerned, a void* in an 'extern "XYZ"' section
may be a totally different beast from a void* in a C++ section.  So I
consider 'extern "XYZ"' meaningless for this discussion.

|>Thus I reiterate my statements that the C++ committee ought to stay
|>focused on specifying *language* not *implementation.*
|
|Fine, as long as you always emphasize that word "ought," and don't
|criticize people for using the language as it is specified.

I criticize people who think the language *is* specified.  It is not.
Some people seem to be saying C++ == ARM + Cfront + ANSI-C

I disagree.  I claim C++ == ARM - annotations

As of today, anything outside of (ARM - annotations) is not C++,
but rather implementation dependencies.

Perhaps someday the ANSI-C++ committee will issue documentation that
includes constraints -- like the ANSI-C specs have -- constraints specifying
"errors" that a conforming C++ compiler has to correctly reject in order to be 
conforming.  Until such a time, pretty much "anything goes."