comp.lang.ada
 help / color / mirror / Atom feed
From: ncohen@watson.ibm.com (Norman H. Cohen)
Subject: Re: Easily-Read C++?
Date: 11 Oct 1994 18:37:02 GMT
Date: 1994-10-11T18:37:02+00:00	[thread overview]
Message-ID: <37em0e$oh0@watnews1.watson.ibm.com> (raw)
In-Reply-To: 85C92963672@annwfn.com

In article <85C92963672@annwfn.com>, merlin@annwfn.com (Fred McCall) writes: 

|> In <3719k1$11gt@watnews1.watson.ibm.com> ncohen@watson.ibm.com Norman H. Cohen writes: 
...
|> >
|> >A more substantive objection to C++ is the fragility of programs written
|> >in the language.  Over and over again in the Annotated C++ Reference
|> >Manual we see the phrase "You are warned," as if that shifts all
|> >responsibility for an error-prone construct from the language designer to
|> >the programmer who falls into the trap that has been set for him.
|>
|> Well, that's no worse than needing a copy of the Standard to be able to
|> figure out what the hell Ada should be doing in a given situation.

1. It IS worse.  The C++ rule makes it easy for a simple clerical error
   to corrupt the data structures of the run-time system.

2. The insinuation in this strange comparison is false.  Every language
   has rules whose details have to be looked up now and then, but most
   of the time an Ada progammer does NOT "need a copy of the Standard to
   be able to figure out what the hell Ada should be doing in a given
   situation."

|> >For example, the C++ type system (inherited from C) does not distinguish
|> >between a pointer to an array of type T and a pointer to an individual
|> >object of type T.
|>
|> Well, if you're not bright enough to keep the single fact in mind that
|> arrays are not first class types in C (or C++), then you have a point.

The problem is not in UNDERSTANDING that C does not distinguish between
pointer-to-T and pointer-to-array-of-T, it is in coping with that
language deficiency.  The fact of the matter is that C++ allocators and
delete statements DO distinguish between the two in their run-time
behavior, so that a two-character clerical error has disastrous results;
but the C/C++ type system does NOT distinguish between the two at compile
time, so this error cannot, in general, be caught by the compiler.

|> You should seek a safer language.  Ada is not going to be safe enough
|> for you, either.  I'd suggest something using rubber letters.

Programming with the Goodyear blimp is overkill.  Type-safe deallocation,
as provided in Ada by strongly-typed instantiations of
Unchecked_Deallocation, is quite sufficient, thank you.

--
Norman H. Cohen    ncohen@watson.ibm.com



       reply	other threads:[~1994-10-11 18:37 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <3719k1$11gt@watnews1.watson.ibm.com>
     [not found] ` <85C92963672@annwfn.com>
1994-10-11 18:37   ` Norman H. Cohen [this message]
1994-10-12 16:54     ` Easily-Read C++? David Emery
1994-10-14 21:13       ` Kevin Cline
1994-10-21 14:38         ` Thomas M. Breuel
1994-10-22  3:10           ` Michael M. Bishop
1994-10-26  0:39             ` -mlc-+Schilling J.
1994-10-27 14:54               ` Bob Duff
1994-10-27 15:35                 ` Richard Kenner
1994-10-27 23:09                 ` Robert Dewar
1994-11-01 21:19                 ` Adam Beneschan
1994-11-02  0:46                   ` Bob Duff
1994-10-14 10:50 Bob Wells #402
  -- strict thread matches above, loose matches on Subject: below --
1994-10-12  3:06 Easily-Read C++ Ken Garlington
1994-10-05  3:00 Easily-Read C++? Ken Garlington
1994-10-05  9:42 ` Pierre Castori
1994-10-05 13:28   ` Robert Dewar
1994-10-06  2:20     ` Benjamin Ketcham
     [not found]     ` <CxDL8H.KGE@csn.org>
     [not found]       ` <milodCxH2E4.7F4@netcom.com>
     [not found]         ` <CxHJv0.Kw0@csn.org>
1994-10-12 17:03           ` John DiCamillo
1994-10-05 14:26 ` Eric S. Sessoms
1994-10-05 17:47 ` Kevin Cline
1994-10-05 22:02   ` Robert Dewar
1994-10-05 22:23     ` Richard Kenner
     [not found]       ` <124377@cup.portal.com>
1994-10-11 18:11         ` David Weller
1994-10-11 18:43         ` Robert Dewar
1994-10-12 13:15           ` Norman H. Cohen
1994-10-12 14:10             ` Robert Firth
1994-10-13 19:33             ` John D. Reading
1994-10-13  0:51         ` Keith Thompson @pulsar
1994-10-05 18:24 ` Magnus Kempe
     [not found] ` <EACHUS.94Oct6101347@spectre.mitre.org>
     [not found]   ` <371a3p$nos@gnat.cs.nyu.edu>
     [not found]     ` <1994Oct7.153254.29848@swlvx2.msd.ray.com>
     [not found]       ` <374uke$8mo@delphi.cs.ucla.edu>
     [not found]         ` <37bno4$ko4@gnat.cs.nyu.edu>
1994-10-11 13:00           ` Robert Firth
1994-10-11 13:44             ` Casper H.S. Dik
1994-10-11 19:03               ` Robert Dewar
1994-10-12 16:38               ` John DiCamillo
1994-10-11 18:52             ` Robert Dewar
1994-10-12 13:49               ` Norman H. Cohen
     [not found]           ` <37eej8$6ie@siberia.gatech.edu>
1994-10-11 18:55             ` Robert Dewar
1994-10-12 13:35               ` John M. Mills
1994-10-12 19:48                 ` Robert Dewar
     [not found]         ` <CxFr5B.K1G@news.otago.ac.nz>
     [not found]           ` <DAG.94Oct10075533@bellman.control.lth.se>
1994-10-11 17:50             ` Norman H. Cohen
     [not found]     ` <373vd2$39n@theopolis.orl.mmc.com>
     [not found]       ` <CxBvq7.GrH@inmet.camb.inmet.com>
     [not found]         ` <37bnic$kj2@gnat.cs.nyu.edu>
1994-10-11 18:02           ` Norman H. Cohen
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox