Related articles |
---|
[13 earlier articles] |
Re: C as assembly language jim.granville@designtools.co.nz (Jim Granville) (2001-04-18) |
Re: C as assembly language joachim_d@gmx.de (Joachim Durchholz) (2001-05-03) |
Re: C as assembly language joachim_d@gmx.de (Joachim Durchholz) (2001-05-07) |
Re: C as assembly language Hans_Boehm@hp.com (Hans Boehm) (2001-05-07) |
Re: C as assembly language jthorn@galileo.thp.univie.ac.at (2001-05-13) |
Re: C as assembly language david.thompson1@worldnet.att.net (David Thompson) (2001-05-15) |
Re: C as assembly language thp@cs.ucr.edu (2002-03-31) |
From: | thp@cs.ucr.edu |
Newsgroups: | comp.compilers |
Date: | 31 Mar 2002 23:31:44 -0500 |
Organization: | University of California, Riverside |
References: | 01-04-027 01-04-085 |
Keywords: | C, design |
Posted-Date: | 31 Mar 2002 23:31:44 EST |
VBDis <vbdis@aol.com> wrote:
[...]
: C++ or C# are far away from C and processors, and establish their own
: model of execution on the target machine.
When I read the underlying models of execution (virtual machines) in
the C and the C++ standards they seem remarkably similar.
: Better use C or any other HLL instead, which better suits your
: expectations on OO programming.
Huh?
[...]
: C was designed for a specific set of
: processors, existing at that time (many decades ago), not at all for
: processors in general.
Which features of C do you see as being specific to those processors
of yesteryear, and "not at all for processors in general"? AFIK, the
C standards committee has gone to great lengths to avoid making
assumptions that would require less-than-optimal code on modern
architectures. For instance, one is not allowed to read a dangling
pointer because certain implementations on certain architectures use
registers that trap when dangling pointers are read.
Tom Payne
Return to the
comp.compilers page.
Search the
comp.compilers archives again.