* Re: Easily-Read C++?
[not found] ` <85C92963672@annwfn.com>
@ 1994-10-11 18:37 ` Norman H. Cohen
1994-10-12 16:54 ` David Emery
0 siblings, 1 reply; 40+ messages in thread
From: Norman H. Cohen @ 1994-10-11 18:37 UTC (permalink / raw)
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
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Easily-Read C++?
1994-10-11 18:37 ` Easily-Read C++? Norman H. Cohen
@ 1994-10-12 16:54 ` David Emery
1994-10-14 21:13 ` Kevin Cline
0 siblings, 1 reply; 40+ messages in thread
From: David Emery @ 1994-10-12 16:54 UTC (permalink / raw)
The ambiguity 'inherent' in declarations such as
char * foo;
char ** foo;
char foo[];
char *foo[];
causes problems for C tools. Even though each of the above is
'unambiguous', common usage means that any of these can be used to
represent the others. At least one tool I know of (an RPC generator
for C) requires the user to disambiguate some of the above
declarations, to make sure that the tool generates the right code.
What's bad for tools is certainly bad for programmers....
dave
--
--The preceeding opinions do not necessarily reflect the opinions of
--The MITRE Corporation or its sponsors.
-- "A good plan violently executed -NOW- is better than a perfect plan
-- next week" George Patton
-- "Any damn fool can write a plan. It's the execution that gets you
-- all screwed up" James Hollingsworth
-------------------------------------------------------------------------
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Easily-Read C++?
1994-10-12 16:54 ` David Emery
@ 1994-10-14 21:13 ` Kevin Cline
1994-10-21 14:38 ` Thomas M. Breuel
0 siblings, 1 reply; 40+ messages in thread
From: Kevin Cline @ 1994-10-14 21:13 UTC (permalink / raw)
In article <EMERY.94Oct12165432@goldfinger.mitre.org>, emery@goldfinger.mitre.org (David Emery) writes:
|> The ambiguity 'inherent' in declarations such as
|> char * foo;
|> char ** foo;
|> char foo[];
|> char *foo[];
|> causes problems for C tools. Even though each of the above is
|> 'unambiguous', common usage means that any of these can be used to
|> represent the others. At least one tool I know of (an RPC generator
|> for C) requires the user to disambiguate some of the above
|> declarations, to make sure that the tool generates the right code.
|>
These declarations are not equivalent. The first is equivalent to the third,
and the second to the fourth.
The equivalence of C pointers and arrays is unfortunate. It is maintained
by C++ for backward compatibility reasons. Most C++ applications use
a library template array class instead of C arrays.
Kevin Cline
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Easily-Read C++?
1994-10-14 21:13 ` Kevin Cline
@ 1994-10-21 14:38 ` Thomas M. Breuel
1994-10-22 3:10 ` Michael M. Bishop
0 siblings, 1 reply; 40+ messages in thread
From: Thomas M. Breuel @ 1994-10-21 14:38 UTC (permalink / raw)
In article <CxoLLu.Av3@uunet!aadt> a311581@ventures.NoSubdomain.NoDomain (Kevin Cline) writes:
|In article <EMERY.94Oct12165432@goldfinger.mitre.org>, emery@goldfinger.mitre.org (David Emery) writes:
||> The ambiguity 'inherent' in declarations such as
||> char * foo;
||> char ** foo;
||> char foo[];
||> char *foo[];
||> causes problems for C tools. Even though each of the above is
||> 'unambiguous', common usage means that any of these can be used to
||> represent the others. At least one tool I know of (an RPC generator
||> for C) requires the user to disambiguate some of the above
||> declarations, to make sure that the tool generates the right code.
||>
|These declarations are not equivalent. The first is equivalent to the third,
|and the second to the fourth.
|
|The equivalence of C pointers and arrays is unfortunate. It is maintained
|by C++ for backward compatibility reasons. Most C++ applications use
|a library template array class instead of C arrays.
None of those declarations are equivalent (if people want to criticize
C, they should at least have a basic understanding of it!).
Furthermore, the problem that RPC systems have with C is that arrays
and pointers do not carry bounds information with them. (Another
problem is that C pointers can point to heap data, into the middle of
other data structures, or to stack data.)
That is indeed a problem in some situations, but it is not related to
declaration syntax. On the other hand, real-world users will probably
not accept a language that doesn't provide some equivalent of C's
plain arrays: the overhead of carrying bounds information around at
runtime is sometimes unacceptable.
In C++, none of this is a problem: arrays usually carry bounds
information (static or dynamic) and can easily be serialized for RPC.
C-style arrays need only be used in very specific situations.
Thomas.
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Easily-Read C++?
1994-10-21 14:38 ` Thomas M. Breuel
@ 1994-10-22 3:10 ` Michael M. Bishop
1994-10-26 0:39 ` -mlc-+Schilling J.
0 siblings, 1 reply; 40+ messages in thread
From: Michael M. Bishop @ 1994-10-22 3:10 UTC (permalink / raw)
In article <TMB.94Oct21153826@arolla.idiap.ch>,
Thomas M. Breuel <tmb@idiap.ch> wrote:
>That is indeed a problem in some situations, but it is not related to
>declaration syntax. On the other hand, real-world users will probably
>not accept a language that doesn't provide some equivalent of C's
>plain arrays: the overhead of carrying bounds information around at
>runtime is sometimes unacceptable.
You don't have to carry Ada array bounds information around at run-time.
You can use the pragma Suppress to remove those checks from the
generated object code. In fact, I believe that this is often done in
real-world applications. When building the system for the production
environment, the pragma is added. I know that this is nitpicking given the
context of this thread, but this is what I do when I have nothing of
substance to add to the conversation :-).
--
| Mike Bishop | The opinions expressed here reflect |
| bishopm@source.asset.com | those of this station, its management, |
| Member: Team Ada | and the entire world. |
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Easily-Read C++?
1994-10-22 3:10 ` Michael M. Bishop
@ 1994-10-26 0:39 ` -mlc-+Schilling J.
1994-10-27 14:54 ` Bob Duff
0 siblings, 1 reply; 40+ messages in thread
From: -mlc-+Schilling J. @ 1994-10-26 0:39 UTC (permalink / raw)
In article <389vqv$i6n@source.asset.com> bishopm@source.asset.com (Michael M. Bishop) writes:
>In article <TMB.94Oct21153826@arolla.idiap.ch>, Thomas M. Breuel <tmb@idiap.ch> wrote:
>>On the other hand, real-world users will probably
>>not accept a language that doesn't provide some equivalent of C's
>>plain arrays: the overhead of carrying bounds information around at
>>runtime is sometimes unacceptable.
>
>You don't have to carry Ada array bounds information around at run-time.
>You can use the pragma Suppress to remove those checks from the
>generated object code.
Pragma Suppress doesn't relate to carrying around array bounds at runtime,
but rather to whether index checks are done. If the array bounds are
dynamic, then it is necessary to carry them around in order to generate
correct indexing offset code, whether or not you are also doing the checks.
But more to the original point, if Ada arrays are declared as equivalents
of C's plain arrays, then the bounds will be static and they will _not_ be
carried around at runtime. (The bounds will materialise if you pass the
array to an unconstrained formal, but this happens to some extent in C
as well - typically you pass in both the beginning and ending addresses
of an array.)
--
Jonathan Schilling
Novell, UNIX Systems Group
jls@summit.novell.com
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Easily-Read C++?
1994-10-26 0:39 ` -mlc-+Schilling J.
@ 1994-10-27 14:54 ` Bob Duff
1994-10-27 15:35 ` Richard Kenner
` (2 more replies)
0 siblings, 3 replies; 40+ messages in thread
From: Bob Duff @ 1994-10-27 14:54 UTC (permalink / raw)
In article <38k8g2INNiff@marble.summit.novell.com>,
-mlc-+Schilling J. <jls@summit.novell.com> wrote:
>Pragma Suppress doesn't relate to carrying around array bounds at runtime,
>but rather to whether index checks are done. If the array bounds are
>dynamic, then it is necessary to carry them around in order to generate
>correct indexing offset code, whether or not you are also doing the checks.
I don't think that's quite right. The compiler can always store the
address of the zero-th element (even if there is no such element), and
then the indexing calculation doesn't need to subtract the lower bound.
Thus, if checks are suppressed, there should be no need to store the
bounds.
On the other hand, if there are any whole-array assignments, then the
size has to be stored (or some information from which the size can be
calculated).
I don't know how many compilers use zero-based arrays. I believe GNAT
does.
I don't know how many compilers are clever enough to make pragma
Suppress not only suppress the checking code, but also the data
necessary to perform the checks. It could get tricky, especially in the
presence of separate compilation.
- Bob
--
Bob Duff bobduff@inmet.com
Oak Tree Software, Inc.
Ada 9X Mapping/Revision Team (Intermetrics, Inc.)
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Easily-Read C++?
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
2 siblings, 0 replies; 40+ messages in thread
From: Richard Kenner @ 1994-10-27 15:35 UTC (permalink / raw)
In article <CyC6rB.JLr@inmet.camb.inmet.com> bobduff@dsd.camb.inmet.com (Bob Duff) writes:
>I don't know how many compilers use zero-based arrays. I believe GNAT
>does.
Not yet, though it is our intent to do so and we have set up our
fat pointer mechanism to make this easier.
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Easily-Read C++?
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
2 siblings, 0 replies; 40+ messages in thread
From: Robert Dewar @ 1994-10-27 23:09 UTC (permalink / raw)
Bob Duff guesses that if you store virtual origins and suppress checks you
do not need to pass bounds around.
It's tricky, since we intend in GNAT to use virtual origins at some point
(it is exactly why we use "fat" pointers for unconstrained types), we have
looked into this issue in some detail.
The trouble is that there are a number of subsidiary language features
that will require the bounds ('Address, 'Access, passing array to a
foreign routine ...)
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Easily-Read C++?
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
2 siblings, 1 reply; 40+ messages in thread
From: Adam Beneschan @ 1994-11-01 21:19 UTC (permalink / raw)
bobduff@dsd.camb.inmet.com (Bob Duff) writes:
> In article <38k8g2INNiff@marble.summit.novell.com>,
> -mlc-+Schilling J. <jls@summit.novell.com> wrote:
> >Pragma Suppress doesn't relate to carrying around array bounds at runtime,
> >but rather to whether index checks are done. If the array bounds are
> >dynamic, then it is necessary to carry them around in order to generate
> >correct indexing offset code, whether or not you are also doing the checks.
>
> I don't think that's quite right. The compiler can always store the
> address of the zero-th element (even if there is no such element), and
> then the indexing calculation doesn't need to subtract the lower bound.
> Thus, if checks are suppressed, there should be no need to store the
> bounds.
>
> On the other hand, if there are any whole-array assignments, then the
> size has to be stored (or some information from which the size can be
> calculated).
Also, if you use the 'FIRST, 'LAST, 'RANGE, or 'LENGTH attributes, you
will need to carry the bounds. Otherwise the following can't be
compiled:
pragma SUPPRESS (ALL_CHECKS);
type INT_ARRAY is array (NATURAL range <>) of INTEGER;
function SUM (A : INT_ARRAY) return INTEGER is
RESULT : INTEGER;
begin
RESULT := 0;
for I in A'RANGE loop
RESULT := RESULT + A(I);
end loop;
return RESULT;
end SUM;
I suppose that your suggestion will work if the *only* operation you
perform on a dynamic one-dimensional array is indexing, but quite
frankly I can't imagine anyone wanting to write a routine that takes a
dynamic array, uses only indexing, and doesn't use 'FIRST, 'LAST, or
'RANGE (or pass the array on to another routine that does).
Also, it should be noted that your suggestion won't work on dynamic
two-dimensional or higher-dimensional arrays.
-- Adam
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Easily-Read C++?
1994-11-01 21:19 ` Adam Beneschan
@ 1994-11-02 0:46 ` Bob Duff
0 siblings, 0 replies; 40+ messages in thread
From: Bob Duff @ 1994-11-02 0:46 UTC (permalink / raw)
In article <CyLxwF.7LK@irvine.com>, Adam Beneschan <adam@irvine.com> wrote:
>I suppose that your suggestion will work if the *only* operation you
>perform on a dynamic one-dimensional array is indexing, but quite
>frankly I can't imagine anyone wanting to write a routine that takes a
>dynamic array, uses only indexing, and doesn't use 'FIRST, 'LAST, or
>'RANGE (or pass the array on to another routine that does).
Yes, you are correct.
It is interesting to think about when a compiler could store just, say,
the address of the first element and the length (and calculate
everything else from that). Super-null arrays cause trouble:
X: String(100 .. -12345);
The length is zero, but Ada requires one to remember the actual bounds,
at least in some circumstances.
>Also, it should be noted that your suggestion won't work on dynamic
>two-dimensional or higher-dimensional arrays.
Correct. In the multi-dimensional case, the indexing calculation
depends on the size of the lower dimensions.
- Bob
--
Bob Duff bobduff@inmet.com
Oak Tree Software, Inc.
Ada 9X Mapping/Revision Team (Intermetrics, Inc.)
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Easily-Read C++?
@ 1994-10-14 10:50 Bob Wells #402
0 siblings, 0 replies; 40+ messages in thread
From: Bob Wells #402 @ 1994-10-14 10:50 UTC (permalink / raw)
Robert Dewar <dewar@CS.NYU.EDU> writes .....
> Subject: Re: Easily-Read C++?
>
> There are to my mind three justifications for comments:
>
> Saying WHY you are doing something, and WHY you did it that way
>
> Saying WHY you did NOT do something, and WHY you did NOT
>
> Describing WHAT the code does, but at a higher level of abstraction
> than the code itself.
G'day Robert,
I totally agree with the above justifications and would also add the
following two:
Describing assumptions about the format or structure of an external
interface, e.g. an incoming message.
-- STAMINA message originator format
-- ORIG/ROLE/HQ
Describing the corresponding meaning for values when they are
defined. For example.
-- The following corresponds to the field RBT in the STORE.QTID section of
-- the PEAQTID file when the TYP field contains a 1 and RBN /= 0.
--
type Rlb_Data is ( Sdd_Coordinates,
Plot_Identification,
Track_Identification,
Sdd_Test_Picture_Display,
Track_Id_Or_System_Coordinates,
System_Coordinates,
Ssr_Code );
Regards,
Bob W. (-:
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Easily-Read C++
@ 1994-10-12 3:06 Ken Garlington
0 siblings, 0 replies; 40+ messages in thread
From: Ken Garlington @ 1994-10-12 3:06 UTC (permalink / raw)
Fred McCall <merlin@ANNWFN.COM> writes:
<< Most of us don't expect people to understand what we write unless they
speak the language, not to mention that only trivial Ada programs are so
easily read and understood. >>
Wrong on both counts. I want people with very little language training or even
software engineering training (if any) to quickly understand the algorithms and
data structures I'm defining. This includes hardware engineers, system test
engineers, IIV&V, SQA, System Safety, etc. I want them to be able to understand
those programs, even if they are 50K source lines of code or more. Ada works
very well for this purpose. Does C++? Sounds like it's a non-issue, since C++
programmers only write for themselves and their fellow programmers.
^ permalink raw reply [flat|nested] 40+ messages in thread
* Easily-Read C++?
@ 1994-10-05 3:00 Ken Garlington
1994-10-05 9:42 ` Pierre Castori
` (4 more replies)
0 siblings, 5 replies; 40+ messages in thread
From: Ken Garlington @ 1994-10-05 3:00 UTC (permalink / raw)
Robin Rowe <cpp@NETCOM.COM> writes:
<< Here's how I read a piece of C++ code:
if(!object) // "If not object [then]"
{ cerr<<object.ErrorMsg(); // "output object's error
} // message,"
else // "else"
{ object++; // "increment object."
}
So what's unnatural about this? Sounds like English to me. >>
Not that I'm a C++ expert, but I have noticed that a lot of C/C++ code looks
like Greek to me. Certainly, that stuff on the right reads like English to me
(is this normal C style to comment every line?) but the stuff on the left I
have to think about a little. On the other hand:
If Not(object) then
Text_IO.Put_Line (Error_Message (corresponding_to => object));
else
object := object + 1;
end if;
is easily read by _any_ engineer (never mind software engineer) on my project.
(Of course, I would have to explain what the "not" of a numeric value is,
maybe, but a more meaningful function name is probably a good idea in this
case.) In fact, it looks suspiciously like the English explanation of the C
code. Note that some of these engineers didn't take the math class where "++"
means "add one to the thing before the ++." However, "X = X + 1" is something
they got pretty early on. That colon hanging off the equal sign doesn't seem to
bother them much.
Has anyone tried a study like the following? Take some C++ code from Software
Development, or Embedded Systems Programming, or whatever. Write the Ada 9X
equivalent. Show the 9X code to C++ programmers who have never seen Ada, and
the C++ code to Ada programmers who haven't worked with C recently. Which set
of code would be understood more often?
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Easily-Read C++?
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-05 14:26 ` Eric S. Sessoms
` (3 subsequent siblings)
4 siblings, 1 reply; 40+ messages in thread
From: Pierre Castori @ 1994-10-05 9:42 UTC (permalink / raw)
In article <941005030023_73672.2025_DHR103-1@CompuServe.COM>, Ken Garlington <73672.2025@COMPUSERVE.COM> writes:
|> |> Robin Rowe <cpp@NETCOM.COM> writes:
|> |>
|> |> Before I begin, I want to make two things clear. One, that I intend
|> |> no disrespect to the author of the original paper, and two, that I
|> |> am an expert in C++ but not in Ada.
|> |>
|> |> [lots of stuff deleted]
|> |>
|> |> << Here's how I read a piece of C++ code:
|> |>
|> |> if(!object) // "If not object [then]"
|> |> { cerr<<object.ErrorMsg(); // "output object's error
|> |> } // message,"
|> |> else // "else"
|> |> { object++; // "increment object."
|> |> }
|> |>
|> |> So what's unnatural about this? Sounds like English to me. >>
|> |>
Of course! Didn't you say you were a C++ expert? Would look weird if
you couldn't understand this easily don't you think so? By the way,
what about the same code without the comments? ...
|> Not that I'm a C++ expert, but I have noticed that a lot of C/C++ code looks
|> like Greek to me. Certainly, that stuff on the right reads like English to me
|> (is this normal C style to comment every line?) but the stuff on the left I
|> have to think about a little. On the other hand:
|>
|> If Not(object) then
|> Text_IO.Put_Line (Error_Message (corresponding_to => object));
|> else
|> object := object + 1;
|> end if;
|>
|> is easily read by _any_ engineer (never mind software engineer) on my project.
|> (Of course, I would have to explain what the "not" of a numeric value is,
|> maybe, but a more meaningful function name is probably a good idea in this
|> case.) In fact, it looks suspiciously like the English explanation of the C
|> code. Note that some of these engineers didn't take the math class where "++"
|> means "add one to the thing before the ++." However, "X = X + 1" is something
|> they got pretty early on. That colon hanging off the equal sign doesn't seem to
|> bother them much.
|>
Totally agreed. I can't understand how people can honestly claim C or C++ are
as readable as Ada. More generally did you realize how often C/C++
programmers use abbreviations? They seem to implicitly admit that what they are
writing will be understood. And this seems to be automatic in the C community.
This probably comes from the times when people were taught C. You learn to use
good old int (integer), rd (read) and fd (file descriptor). Then it is natural
to continue using such abbreviations. What is the big deal in writing
file_descriptor? Laziness? Why cerr and Msg in the example above?
Agreed that ErrorMsg is understandable. But again what is the problem in
writing Error_Message? Especially with nowadays editors that have so many
features to help you complete words, indent automatically, etc.
Comparatively, Ada programmers seldom abbreviate. I am not saying they never
do it. I am saying the tendency in the Ada community is naturally not to
use abbreviations (ease of reading). While the tendency in the C community is
naturally to use abbreviations (ease of writing). The C/C++ languages themself are
designed with some sort of a compact-statements-do-a-lot principle.
Abbreviations make programs much more difficult to read and understand.
In writing programs, I think many programmers forget the well-known principle:
a program is written once, read many. And "many" means many other people than
the author!
|> Has anyone tried a study like the following? Take some C++ code from Software
|> Development, or Embedded Systems Programming, or whatever. Write the Ada 9X
|> equivalent. Show the 9X code to C++ programmers who have never seen Ada, and
|> the C++ code to Ada programmers who haven't worked with C recently. Which set
|> of code would be understood more often?
Guess ... ;-)
In computer science papers that present some algorithms, it is seldom the case
that these algorithms are described in a C-like fashion. Most often, a Pascal-like
solution is used even when the algorithm is really implemented in C/C++. Howcome?
I thought C was THE widely accepted language. For me, this says it all.
//Pierre.
============================================================================
| Pierre Castori | Tel : +41 21 693 2054 |
| Dept. of Computer Science | Fax : +41 21 693 4701 |
| Swiss Federal Institute of Technology |-------------------------------|
| EPFL - IN ECUBLENS ______| Email: castori@litsun.epfl.ch |
| 1015 Lausanne (SWITZERLAND) | http://litwww.epfl.ch/~castori/.html |
============================================================================
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Easily-Read C++?
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>
0 siblings, 2 replies; 40+ messages in thread
From: Robert Dewar @ 1994-10-05 13:28 UTC (permalink / raw)
The point that C and C++ programmers tend to use abreviations and in general
short identifiers, where as Ada programmers tend to use long fully spelled
out names is a pretty important one. Because, good choice of names is often
critical to readability of code (more critical than the basic syntactic
structure of the language -- Basic with good names can be much more readable
than Ada with junk short names).
So, it isn't a language issue at all? right? you can perfectly well use nice
names in C++ (or for that matter Basic) if you want to.
Well, I am not so sure that this is not a language issue. THe trouble with
C, inherited by C++, is that it has a lot of very neat notations that
somehow are much nicer and neater with short names (much the same could
be said of many traditional mathematical notations, mathematicians tend
to call a function f, rather than Second_Order_Bessel_Function, but then
their "programs" are usually short).
i++
that's a nice neat notation, especially when composed in a complex
expression, but
Average_Daily_Rate_Of_Pay++
makes people laugh (I tell that as a joke, and C programmers as well as
Ada programmers laugh).
somehow, the ++ just ain't so neat in the context of long names.
How important is this effect? I don't know!
To what extent does it explain the empirical observation of difference
in style between C++ programmers and Ada programmers? I don't know!
I hasten to add that the universal quantifiers here are of course bogus,
not ALL C++ programmers choose junk names, and not all Ada programmers
choose good names (the most noticable counter examples I have seen in
both cases come from recently translplanted programmers, C++ programmers
trying to write Ada, or vice versa).
I would also add to this thread that the mere fact that there exists a
person who can easily read X does not mean that X is readable. I once
had a student who gaily wrote thousands of lines of uncommented assembly
language, and could read it just fine :-)
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Easily-Read C++?
1994-10-05 13:28 ` Robert Dewar
@ 1994-10-06 2:20 ` Benjamin Ketcham
[not found] ` <CxDL8H.KGE@csn.org>
1 sibling, 0 replies; 40+ messages in thread
From: Benjamin Ketcham @ 1994-10-06 2:20 UTC (permalink / raw)
In article <36ui0u$4dg@gnat.cs.nyu.edu>, Robert Dewar <dewar@cs.nyu.edu> wrote:
>Maybe the C line should be
>
> p(j,b,t)
>
>since it seems out of style to use those long names :-)
Robert:
You'd be a lot easier to take seriously (and since you are obviously
very knowledgeable I believe that taking you seriously is generally
a good idea) if you could resist the temptation to jump on every
opportunity to make gratuitous and unwarranted jabs at C/C++. Not
everyone who reads this newsgroup is a completely dedicated and rabid
Ada zealot who sees no utility whatever in any other language, so be
careful about assuming you are preaching to the converted. (I could
make a jab of my own about Ada right here, but I won't.)
The irony is, if I'm not highly mistaken, I think I've heard you
yourself complain from time to time about the poor signal/noise ratio
in this very newsgroup due to "language-bashing".
I guess you haven't looked at much X11 code if you think C programmers
like to use short names! Personally, I almost wonder whether problems
might arise occasionally due to names that do not differ within the
guaranteed minimum-significant number of characters (32, is it?)....
Sure, *some* C programmers use illegibly-short names, just as probably
*some* Ada programmers don't do enough thinking about program design
and robustness because they assume the compiler will protect them. If
the former are the rule, rather than the exception, in your universe,
then perhaps we just live in different universes.
--ben
PS: I don't have a problem with
++really_long_and_descriptive_variable_name;
It certainly looks better to me than
really_long_and_descriptive_variable_name := really_long_and_descriptive_variable_name + 1;
(Geez, had to use the editor to facilitate writing that last bit, and
if you really believe that it's more readable than the first one,
particularly if it were in a "real-world" context where there might
be dozens of variables beginning with, e.g., "really_long_and_", then
I'll just have to respectfully decline to agree.)
^ permalink raw reply [flat|nested] 40+ messages in thread
[parent not found: <CxDL8H.KGE@csn.org>]
* Re: Easily-Read C++?
1994-10-05 3:00 Easily-Read C++? Ken Garlington
1994-10-05 9:42 ` Pierre Castori
@ 1994-10-05 14:26 ` Eric S. Sessoms
1994-10-05 17:47 ` Kevin Cline
` (2 subsequent siblings)
4 siblings, 0 replies; 40+ messages in thread
From: Eric S. Sessoms @ 1994-10-05 14:26 UTC (permalink / raw)
On Tue, 4 Oct 1994, Ken Garlington wrote:
> Robin Rowe <cpp@NETCOM.COM> writes:
>
> << Here's how I read a piece of C++ code:
>
> if(!object) // "If not object [then]"
> { cerr<<object.ErrorMsg(); // "output object's error
> } // message,"
> else // "else"
> { object++; // "increment object."
> }
>
> So what's unnatural about this? Sounds like English to me. >>
I've been giving a lot of thought to this readability issue, since
as a native C/C++ speaker, I find the readability of Ada to be one
of its strong points. BUT, the factors I find contribute most to
the readability of Ada do not include its "englishness". Rather, some
of the language features such as subrange types, arbitrarily bounded
arrays, and arrays over enumerated or character types seem (to me) to
make the greatest contribution. (And nested procedure declarations,
can't forget that!)
Now, as Robin Rowe pointed out, these are not foreign concepts
in C++. In fact, they are all rather trivial given the wonderful
C++ template mechanism, but that's where they fall. *The necessary
templates are not standard.*
By taking these low level concepts as part of the language, Ada has
standardized a much larger part of what (some) programmers (like me)
do. The net effect is that in moving from one person's code to another
(or one shop's code to another, if they impose shop standards) there
is a slight decrease in reading effort from not having to re-learn
how Coder X has chosen to implement a few necessary low-level concepts.
just to throw in some pseudo-code:
enum days_of_week { sunday, monday, tuesday, wednesday, ..., saturday };
typedef Bounded<days_of_week, monday, friday> week_days;
Array<week_days, int> beers_drank;
beers_drank[wednesday] = 0;
Having only one integer type is also nice. Why, nearly as nice
as "class Integer {...};"! Do you see my point? I really doubt
there is much in Ada that you can't have in C++, but in Ada it
is (1) easier and (2) standardized -- so convince me that standardization
gives you something more than a larger language standard.
IMHO, it helps _a_lot_. IMHO, it will all be moot once standardized
C++ class libraries become commonly available.
Responses? Ideas? Criticisms? I'm very tired of "'begin end' is better
than '{ }'" arguments, and the "Ada programmers use longer names"
arguments, but I would be very interested in any further discussion of
what language elements contribute either to the readability of Ada or of
C++. Please post follow-ups here and direct all flames to:
eric sessoms (sesse@ruby.ils.unc.edu)
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Easily-Read C++?
1994-10-05 3:00 Easily-Read C++? Ken Garlington
1994-10-05 9:42 ` Pierre Castori
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 18:24 ` Magnus Kempe
[not found] ` <EACHUS.94Oct6101347@spectre.mitre.org>
4 siblings, 1 reply; 40+ messages in thread
From: Kevin Cline @ 1994-10-05 17:47 UTC (permalink / raw)
It doesn't matter how readable a programming language is to inexperienced
users of that language. Most people required to read code in C or Ada
end up reading a lot of it. It takes me longer to read Ada, even after
3 years experience, because there are more characters to look at.
Every field of human endeavor has created special words & symbols
to save time both in writing and reading. Ada's attempt to make code
read more like natural language opposes a trend that began with the
invention of writing.
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Easily-Read C++?
1994-10-05 3:00 Easily-Read C++? Ken Garlington
` (2 preceding siblings ...)
1994-10-05 17:47 ` Kevin Cline
@ 1994-10-05 18:24 ` Magnus Kempe
[not found] ` <EACHUS.94Oct6101347@spectre.mitre.org>
4 siblings, 0 replies; 40+ messages in thread
From: Magnus Kempe @ 1994-10-05 18:24 UTC (permalink / raw)
Ada was _designed_ to be readable. C++ is based on C, not something
which was designed to be readable (to say the least).
Is the code below readable? (pretty standard C++, no?) Try.
Read it out, loud.
--------------------------------------------------------------
template <class T>
class Stack {
public:
Stack () {size = 0; head = 0;};
~Stack () {if (head) delete head;};
void push (T& a);
void pop ();
T& top () {return head->item;};
int count () {return size;};
bool operation== (Stack<T>& a);
private:
int size;
Node<T> *head;
};
template <class T>
class Node {
public:
Node (T6 a, Node<T> *b): next(b), item(a) {};
~Node () {if (next != 0) delete next;};
private:
T item;
Node<T> *next;
friend class stack<T>;
};
--------------------------------------------------------------
How does one pronounce "void push (T& a);", or "Node<T> *b", or
"{}" ? Do you notice the typos?
Compare to a pretty standard Ada 9X equivalent:
--------------------------------------------------------------
generic
type Item_Type is
private;
package Stack_G is
type Stack_Type is
tagged limited private;
procedure Push (Stack : in out Stack_Type;
Item : in Item_Type);
procedure Pop (Stack : in out Stack_Type);
function Count (Stack : Stack_Type)
return Natural;
function Top (Stack : Stack_Type)
return Item_Type;
operator "=" (Left, Right : Stack_Type)
return Boolean;
private
type Cell_Type;
type Link_Type is
access cell_Type;
type Cell_Type is
record
Item : Item_Type;
Next : Link_Type;
end record;
type Stack_Type is
tagged limited record
Size : Natural := 0;
Head : Link_Type;
end record;
end Stack_G;
--------------------------------------------------------------
Do you notice the typos?
--
Magnus Kempe "I know not what course others may take, but as for me,
Magnus.Kempe@di.epfl.ch Give me Liberty... or give me Death!" -- Patrick Henry
^ permalink raw reply [flat|nested] 40+ messages in thread
[parent not found: <EACHUS.94Oct6101347@spectre.mitre.org>]
end of thread, other threads:[~1994-11-02 0:46 UTC | newest]
Thread overview: 40+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <3719k1$11gt@watnews1.watson.ibm.com>
[not found] ` <85C92963672@annwfn.com>
1994-10-11 18:37 ` Easily-Read C++? Norman H. Cohen
1994-10-12 16:54 ` 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
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox