Topic: The Spirit Of C++ Linkage
Author: Alessandro Vesely <MC6192@mclink.it>
Date: 1995/08/06 Raw View
I believe that some of the spirit of C is being inherited by
C++, so, although I'm not much versed in DWP wording, I can
hardly believe what
Steve Clamage wrote on 3 Aug 1995 16:07:35 GMT:
>
>In article 1415@ittpub, wil@ittpub.nl (Wil Evers) writes:
>>
[discussion on extern "C" and extern "C++" vendor's specifications]
>
>>- For each of these forms of external linkage, the standard should
require
>>the compiler vendor to specify which name encoding scheme and calling
>>conventions are used. As Steve Clamage pointed out, such a requirement
>>could be satisfied by to referring to some well-defined ABI. For extern
>>"C", 'same as C compiler XYZ version 2.0.2' would be good enough, as
long
>>as that compiler defines its name encoding scheme and calling
conventions.
>
>Now things get stickier. It's fine for you to say "name encoding scheme"
>and "calling conventions". But the standard would have to define what
>that means. What if there is no linker and no name encoding? What
>exactly must be specified in "calling conventions": Register usage? There
>might not be any registers. Stack frame layout? There might not be a
stack
>frame, or even a stack as it is commonly thought of.
>
>The standard would have to say what the vendor must specify, but without
>reference to hardware features which might not exist, and possibly
missing
>things which would be important on some platform.
I am curious to see an implementation without stack. I'm
not saying it's not possible, I'm curious because I never
saw one. In the ARM2 the term _stack_ usually just denotes
a general data structure, except in the circumlocution
_stack unwinding_, where it clearly is intended in its (low
level) meaning. I accept the point that existing code
matters, existing implementation don't. But couldn't it be
possible to consider just the current trend of existing
implementations? After all, existing code is (and will be)
written after existing implementations.
Do you really mean there may not be any registers?
At least, will there be a _computer_? I mean, the term
_hardware_ should have a neat meaning, that also includes
registers and memory sort of things, if the hardware has
any. Would the wording <as long as that compiler defines
its hardware-related characteristics> make more sense?
There must be a way in English to express the idea that a
C++ programmer should be able to know and to control how the
code she writes will be linked by the linker and executed by
the machine.
This opens a slightly different question. Imagine a C++
interpreter that accepts an abstract machine description and
some implementation hints and then is able to simulate
execution of a C++ program given its source. Of course
external linkage would not be provided, at least not as it
is commonly thought of. I would say that would be a
wonderful tool, but the standard would consider it _an
emulator of a C++ implementation_ or _a C++ implementation_
in its own right? (Assume you are licensed to encrypt your
source and pack it with the tool in order distribute the
*compiled* program.)
Later in the same message, Steve Clamage wrote:
>
>We cannot solve all problems with a language standard. Some people would
>like the standard to be specific enough that any compiler that met its
>requirements would be useful and efficient. IMHO, this can't be done,
>and isn't worth trying to do. (If someone wants to spend several
>person-years producing a C++ implementation that meets all the
requirements
>of the standard yet is useless, that's OK with me. But I won't buy it.)
>
I think Steve Clamage can hardly be considered an average
compiler's customer. My feeling is that the market will buy
powerful IDEs that enhance average application programmers
productivity. It's not XYZ's damage if a few programmers,
like Steve Clamage, won't be able to find compilers good
enough for them. In such scenario most programmers will not
recognize their own code when they'll look at it through a
plain text editor. At that point C++ will be nearer to an
alternate Visual Basic than to the spirit of C.
Shouldn't the standard specify the editor?
(sorry, I couldn't resist :-))
Bye
Ale