|[13 earlier articles]|
|Re: C as assembly language firstname.lastname@example.org (Jim Granville) (2001-04-18)|
|Re: C as assembly language email@example.com (Joachim Durchholz) (2001-05-03)|
|Re: C as assembly language firstname.lastname@example.org (Joachim Durchholz) (2001-05-07)|
|Re: C as assembly language Hans_Boehm@hp.com (Hans Boehm) (2001-05-07)|
|Re: C as assembly language email@example.com (2001-05-13)|
|Re: C as assembly language firstname.lastname@example.org (David Thompson) (2001-05-15)|
|Re: C as assembly language email@example.com (2002-03-31)|
|Date:||31 Mar 2002 23:31:44 -0500|
|Organization:||University of California, Riverside|
|Posted-Date:||31 Mar 2002 23:31:44 EST|
VBDis <firstname.lastname@example.org> 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.
: 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.
Return to the
Search the comp.compilers archives again.