NetNews Usenet Archive 1992 #19/NN_1992_19.iso/spool/comp/edu/1528

Text File | 1992-09-03 | 4.9 KB | 112 lines

Xref: sparky comp.edu:1528 comp.lang.fortran:3422 comp.lang.misc:2929 comp.arch:9218 sci.math:10977
Newsgroups: comp.edu,comp.lang.fortran,comp.lang.misc,comp.arch,sci.math
Path: sparky!uunet!munnari.oz.au!cs.mu.OZ.AU!munta.cs.mu.OZ.AU!fjh
From: [e-mail] (Fergus James HENDERSON)
Subject: Re: Scientists as Programmers (was Re: Small Language Wanted)
Message-ID: <[e-mail]>
Sender: [e-mail]
Organization: Computer Science, University of Melbourne, Australia
References: <[e-mail]> <2![e-mail]> <[e-mail]> <[e-mail]>
Distribution: na
Date: Fri, 4 Sep 1992 08:06:00 GMT
Lines: 98

[e-mail] (Herman Rubin) writes:

>In article <[e-mail]> [e-mail] (Don Meyer) writes:
>>In article <2![e-mail]> [e-mail] (John Prentice) writes:
>> [ re: C++ and complex numbers ]
>>>Fortunately, you wouldn't need to because the designers were not brain
>>>dead enough to leave in out in the first place :-) .
>
>>'C' was intended as more of a systems language, in which case complex
>>numbers aren't usually needed.  C++ extends C without any particular
>>bias towards features for specific applications areas.  The philisophy
>>of extending the language via librarys (which can function quite as
>>nicely as built-in features) is a sound one.
>>I would hardly characterize this _considered choice_ as "brain-dead".
>
>This is not brain-dead, but it is certainly brain-damaged.  Inlining of
>stuff from libraries has to be done at compile time, or at most at assemble
>time, as at least the compiler needs to know how much space the inlined
>code will take.  If every addition, etc., required a subroutine call,
>the computer would run very much slower.  So one would have to use
>some type of language extension file at compile time, not libraries.

"Libraries" may include both source code and object code.
(I think the problem here is just that you are using a different definition
of "library".)
The normal way of doing things in C/C++ is put those parts of a library
that will the users will need at compile time in header files (.h).
With C++, the use of inline functions and templates means that more of
the library must be provided as source code than was the case for traditional
C libraries.

>The present compilers translate such things as +, *, &, etc., into
>some version of assembler.  Why not allow the user to say how other
>operations will be similarly translated, and add them to the list?

Using any particular assembly language is inherently non-portable, so clearly
this is not a matter which should be addressed by the C standard.
However individual C implementations may provide such a facility as an
extension if desired. Many C/C++ compilers allow inline assembly code;
gcc is one such compiler. For example, the following shows how you can
tell gcc to use the 68881's fsinx instruction:

    #include <stdio.h>
    #include <math.h>

    #define USE_68881_INSTRUCTIONS 1

    #if defined(__GNUC__) && defined(USE_68881_INSTRUCTIONS)
        inline double fast_sin(double arg) {
            double value;
            asm ("fsinx %1,%0": "=f" (value): "f" (arg));
            return value;
        }
    #else
        inline double fast_sin(double arg) { return sin(arg); }
    #endif

    int main() {
        printf("%f", fast_sin(3.14159/2));
    }

This feature is documented in the gcc-info file (node "Extended asm",
under node "Extensions"). Is that what you wanted?

>These operations often produce temporaries; why not tell the user
>how this is done, and let them be added to the list?

I'm not quite sure exactly what you are after here. Could you be
a bit more precise about how the user could specify how temporaries
are produced?

>These would not really complicate the language design or the compiler,
>except insofar as precedence is affected.

Hmmm... Now it sounds like you want operator overloading.
Please don't confuse the notational convenience of operators with
their usually efficient implementation in terms of single machine
instructions.
C++ allows you to overload existing operators, although to make compiler
writer's jobs easier, it does not allow you to introduce new operators.
This is a separate issue from the ability to write functions that compile
to a single inline machine instruction.

>Now why did the C designers use the term "typedef" for what should have
>been called "typealias"?  I have used Fortran compilers before the creation
>of C which allowed a limited number of user-defined types.

You could make a strong case that the word "typealias" would be better than
"typedef". If it really bothers you, you can just simply
    #define typealias typedef

>Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399

--
Fergus Henderson             [e-mail]
This .signature virus is a self-referential statement that is true - but
you will only be able to consistently believe it if you copy it to your own
.signature file!