NetNews Usenet Archive 1993 #3/NN_1993_3.iso/spool/comp/lang/c/20048

Internet Message Format | 1993-01-21 | 7.4 KB

Xref: sparky comp.lang.c:20048 comp.lang.c++:19725
Path: sparky!uunet!elroy.jpl.nasa.gov!usc!howland.reston.ans.net!zaphod.mps.ohio-state.edu!uwm.edu!cs.utexas.edu!geraldo.cc.utexas.edu!emx.cc.utexas.edu!not-for-mail
From: [e-mail] (Jamshid Afshar)
Newsgroups: comp.lang.c,comp.lang.c++
Subject: Re: C/C++ Speed
Date: 21 Jan 1993 21:50:37 -0600
Organization: The University of Texas at Austin, Austin, Texas
Lines: 154
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <mg.726986956@tyrolia>
NNTP-Posting-Host: emx.cc.utexas.edu

In article <mg.726986956@tyrolia> mg@tyrolia (Michael Golan) writes:
>2. Stroustrup claims:
>>    Programs in the common subset of C and C++ results in
>>    equal sized code that execute at equal speed.
>>If that conclusion doesn't appear to hold, check if your C and C++
>>compilers are of similar quality.
>
>This is the #1 problem of C++, poor implementation!
>We have been waiting for years, literally. But by the time the vendors get
>a version stable, the language has changed enough to force a compiler
>rewrite.

Stroustrup is talking about identical code compilable by both a C and
a C++ compiler.  I've haven't experienced a slowdown when compiling my
C code with a C++ compiler (though I have found errors in the code).
Yes, C++ compilers, esp.  earlier versions, have had lots of bugs
related to C++ features (esp. newly implemented ones).  But, I know of
no C++ compilers that have problems compiling C code well.

Yes, templates and exception handling require a lot of work from
compiler writers.  Yes, the early implementations of these features
do/will have bugs.  As I have said before, I am still much more
productive using templates and working around bugs than not using
templates.  If you don't want to work around compiler bugs, don't use
templates.  I believe you can rather safely and portably write C++
w/out templates on all modern C++ compilers.

>Lets compare apples to apples. On most systems, today, the C++
>implementation is incomplete, buggy and overall poor. Still, people
>are moving to use it, which doesn't show sanity on their side.

On the PC, the most widely used system, the two most popular compilers
are MSC7 and BC++.  I would not describe either of them as poor or
buggy.  I don't know about UNIX, Mac, etc., but I can't think of any
reason for PC programmers to shy away from C++ since their C compilers
also do C++, and do it well.

>3. Size/speed:
>If you have a virtual function in a class, it gets pulled in even if
>it is never called. No linkers exist to prevent this, as far as I know.

I've heard Topspeed C++ does this kind of optimization.  Anyway, I
don't think it's that serious of a problem.  Even non-optimizing
linkers will usually only pull in an object file from a library if
something in there is referenced (ie, if no ctor in the file is used,
no vtable is referenced).

>Given that ALL C++ libraries use virtual functions, the size difference is
>significant.

Well, the general C++ class library JCOOL (see pub/GECOOL/JCOOL.TXT at
cs.utexas.edu) uses virtual functions in only one of its classes:
List.  The other couple of dozen classes (sets, hash tables, matrices,
etc) don't use virtual functions.  C++ doesn't force one to use
virtual functions, and I think you can write a lot of useful classes
without them.

>Most C++ code has comments about buggy compilers, amazing as this may sound.

I don't think this is amazing at all.  Buggy software is a fact of
life, whether that software is a compiler, os or application.

>4. Safety
>   C++ does not protect againt typical system code:
>    write_int(int x) {
>    char *p ;
>    p = (char *) x;    // oops, I meant &x !!
>    write(f,p,sizeof(int));
>    }

This is silly.  C++ (and ANSI C) do protect you from these kind of
errors because they allow you to use safer functions which don't
require a cast.  C++ goes further in that its data abstraction,
template, and inheritance features allow you to better implement
persistence.

>   it "adds" stuff like        double (x) ;   // declare new x ?!
>   and don't complain about
>    double **x;
>    x= (new double**)[5] ;    /* the compiler liked it! */

Yes it would be nice if the compiler complained, but the code is
syntacticly legal.  What's your point?  C is where C++ got the ability
to write obfuscated stuff like this.  The advantage of C++ is that it
allows you to do the following instead:

    Matrix<double> x(5,5);
    Array<double> z(5);
    x[5] = z;

>I am amazed at the number of people who are moving to C++ when it is
>clear, even if this is the prefect langauge, that the
>implementation and quality are at least a year away.

No software's quality improves unless people are using it.  With the
number of people using C++, and the amount of code being written, C++
compiler quality will increase (and has been increasing) at a much
higher rate.

You can already safely and portably use most of C++'s features.  I
predict practically all template implementations will be very stable
by the end of this year and that template implementations will be
wide-spread.  On the other hand, I doubt we'll even *see* more
than a couple of exception handling implementations this year.

>All of these, when they
>had all the tools and knowledge to design a good language which will
>have most C's features and speed, but with higher abstraction, better
>modularity, run time checks, etc etc.

First, I hope you agree that no language could replace C unless it
also could work with C code, at least by linking to it but more likely
actually compiling it.  If there is a better language that can replace
C, where is it and where can I get a copy for my DOS/Windows system?

>They will also wonder about our ability to do anything, when no decent
>tools exist, not even for cross-referencing!

C++ tools in general are not near the maturity level of C tools.
There are some systems that have C++ tools as good or better than the
C tools, but most systems are not at that level.  This is the way it
is with any new technology.  Programmers have to decide when they are
ready for a new technology, and when it is ready for them.

>For C++ it is clearly too late. C++ is a committee work. Which means
>all the stupid features will be kept, no useful stuff will be added,
>and wierd useless stuff will be added.

I think exception handling is a pretty useful feature.  What stupid
features can be removed with breaking C compatibility?  What weird
useless stuff is being added?

>New discussion: if there was a new language, D, that had the same low
>level C code, much cleaner design, and C style ( {} and not begin-end, etc,
>most C code easily ported, if not compatible), would you use it?
>What will it take for people to consider an alternative to C++?
>Lets say it is a watered-down C++, fewer rules, no MI, real type checks
>including pointers and runtime etc. do you buy it?

Btw, MI is very important in a staticly typed language (go argue in
comp.lang.eiffel if you don't agree).

How can your hypothetical D language both compile the same low level C
code, and do run-time type checking, etc?  If Stroustrup didn't care
about C compatibility, he could have designed a much better and safer
language.  Unfortunately it would never have gotten used.

You cannot replace something without providing a way to easily use the
thing being replaced.  That is now taken for granted in operating
systems, why is it so hard for people to accept that the same goes for
computer languages?

Jamshid Afshar
[e-mail]