Easily-Read C++?

Easily-Read C++?

[Ken Garlington]

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?

Re: Easily-Read C++?

[Pierre Castori]

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 |
============================================================================

Re: Easily-Read C++?

[Robert Dewar]

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 :-)

Re: Easily-Read C++?

[Eric S. Sessoms]

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)

Re: Easily-Read C++?

[Kevin Cline]

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.

Re: Easily-Read C++?

[Magnus Kempe]

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

Re: Easily-Read C++?

[Robert Dewar]

Right, and comments also slow down you reading because they add unnecessary
characters .. I certainly know far too many programmers who think that
way ...

Re: Easily-Read C++?

[Richard Kenner]

In article <36v7p4$amf@gnat.cs.nyu.edu> dewar@cs.nyu.edu (Robert Dewar) writes:
>Right, and comments also slow down you reading because they add unnecessary
>characters .. I certainly know far too many programmers who think that
>way ...

There are actually times when it can!  Consider the following fragment
of an assembler language program for the PDP-11 written by someone who
was told to write a comment on every line:

	ADD	#1,R0		;Add one to R0.

That actually *does* slow down reading!

One company, either DEC (I think) or CDC (less likely) actively
discouraged this sort of thing in their coding standard.

Re: Easily-Read C++?

[Benjamin Ketcham]

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.)

Re: Easily-Read C++?

[Robert Firth]

In article <37bno4$ko4@gnat.cs.nyu.edu> dewar@cs.nyu.edu (Robert Dewar) writes:

>An interesting point about the ++ notation is that it appears as far as
>I can tell to give undefined results or rather implementation dependent
>resultsin the presence of threads, in particular, is it possible for
>++c to store a 4 in memory (where there was a 3 before), and then return
>6 as a result of rereading c, where intermediate updates have occurred.

Unfortunately, as far as I can see this is almost inevitable.  The
construct expands, semantically, to

	valof { c := c+1; resultis c }

Well, one can try to make the increment an atomic operation, giving,
for instance (PE3200 code)

	LIS R1, 1	; load 1 into a temp register
	AM R1, C(RD)	; add it to memory cell C

but then you are forced to do another read

	L R0, C(RD)	; now load new value of C into result reg

and, as Robert Dewar mentioned, who knows what has happened in
the meantime?

The alternative is to make the result computation essentially
atomic:

	L R0, C(RD)	; get value of C into result reg
	AIS R0, 1	; add 1 to it and leave as result
	ST R0, C(RD)	; and store back new value

and, again, anything could have happened to the variable C between
the read and the write.  So the compiler writer, with the best will
in the world (a rare quality, I fear) is still pretty much stuck.

The C code I've seen is absolutely littered with this stuff. I am
continually amazed that *anything* still works when people write
true multitasking code in C.

Re: Easily-Read C++?

[Casper H.S. Dik]

firth@sei.cmu.edu (Robert Firth) writes:

>The C code I've seen is absolutely littered with this stuff. I am
>continually amazed that *anything* still works when people write
>true multitasking code in C.

Why?  The only think you need to take care of in C when writing
multi-threaded code is using proper (explicit) locking of global
data.  Most of the foo++ usages in C are of automatic variables.
Those aren't shared between threads or even function invocations
and consequently there is no problem with c++ kind of code.

However, when incrementing a global variable one should do something
like this:

	set_write_lock(foo_lock);
	foo++;
	unlock_write_lock(foo_lock);

The problem with C multi-threading is making the locking explicit.
You may also need to make such variable "volatile"  which is C-speak
for "can be modified behind my back".

Locking is also necessary for reading variables that are shared
between threads (and modified by some of those threads).

I really don't see what the difference between "foo = foo + 1"
or foo++ is in this context.

Casper

Re: Easily-Read C++?

[Norman H. Cohen]

In article <DAG.94Oct10075533@bellman.control.lth.se>, dag@control.lth.se
(Dag Bruck) writes: 

|> I may be worth pointing out that the C++ standard will provide some
|> additional tokens, e.g.: 
|>
|>      and     <=>     &&
|>      or      <=>     ||
|>      not     <=>     !
|>
|>      bitand  <=>     &
|>      bitor   <=>     |
|>      xor     <=>     ^
|>
|> I think C users can get a similar effect by including iso646.h.
|>
|> Gee!  The world is changing.

Indeed.  Now General Whittaker will be able to key in C++ programs on his
keypunch.

:-)

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

Re: Easily-Read C++?

[Norman H. Cohen]

In article <37bnic$kj2@gnat.cs.nyu.edu>, dewar@cs.nyu.edu (Robert Dewar)
writes: 

|> One little addition on min and max, they are static attributes and so can
|> be used in static expressions. That's quite useful....

I agree.  I only wish there were a way--short of writing
Largest_Integer_Type'Pos(Largest_Integer_Type'Max(...,...))--to use 'Max
and 'Min in universal expressions.  In fact, even this doesn't work for
real numbers.

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

Re: Easily-Read C++?

[David Weller]

In article <124377@cup.portal.com>,  <R_Tim_Coslet@cup.portal.com> wrote:
>In article: 36v90m$9r4@cmcl2.NYU.EDU> 
>	kenner@lab.ultra.nyu.edu (Richard Kenner) wrote:
>>There are actually times when it can!  Consider the following fragment
>>of an assembler language program for the PDP-11 written by someone who
>>was told to write a comment on every line:
>>
>>	ADD	#1,R0		;Add one to R0.
>>
>>That actually *does* slow down reading!
>>
>Useless comments like that should be BANNED.
>
>If a comment can't say anything that the code doesn't already say,
>either the comment shouldn't be there or maybe the comment needs
>complete rethinking to ADD something that the code DOESN'T say (e.g.
>what is in R0? "Add one to counter" or "Increment flight level" would
>be MUCH more informative than simply repeating the code).

Ben Brosgol wrote an article many years ago on correct commenting.
He pointed out that the only thing worse than commenting the above
code as "Increment R0 by 1" was to say "Decrement R0 by 1" :-)


-- 
Proud (and vocal) member of Team Ada! (and Team OS/2)        ||This is not your
   	      Ada -- Very Cool.  Doesn't Suck.               ||  father's Ada 
For all sorts of interesting Ada tidbits, run the command:   ||________________
"finger dweller@starbase.neosoft.com | more" (or e-mail with "finger" as subj.)
   ObNitPick: Spelling Ada as ADA is like spelling C++ as CPLUSPLUS. :-) 

Re: Easily-Read C++?

[Norman H. Cohen]

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

Re: Easily-Read C++?

[Robert Dewar]

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.

Re: Easily-Read C++?

[Robert Dewar]

Robert (Firth), you didn't look at my question quite carefully enough.
Of course it can be the case that ++c clobbers a value stored by someone
else, but I asked the following:

is it permissible for ++c to STORE a different value from what it returns?

Now of course on all machines, as illustrated by your second code example
(which is really the only possibility on all RISC machines, and is the
best code on all modern machines), it is possible to generate code so
the answer is NO

    x := x + 1; (x left in a register)
    (use the value in the register)

I would expect that this code is what is generated by most C compilers. The
only possible exception is on CISC machines with increment memory or add to
memory instructions, when in fact it certainly can answer YES to my question,
as illustrated by the first example.

Reading the C standard clearly does not answer my question, so we must
presume that the two sequences of code have quite a different effect.

Note that we ought to assume that the variable involved is volatile, and
you would expect that a volatile variable would be accessed in a
comprehensible canonical style (this is certainly true in Ada), but the
++c and c++ constructs definitely mean that even if c is volatile you
don't know how often it is read and written.

I certainly agree with your parting thought! (how can anyone write
parallel code in C that is portabl).

Re: Easily-Read C++?

[Robert Dewar]

John (Mills), I assume that you see from my previous post that the question
I posed is indeed a well defined one. I assumed that we are dealing with
a volatile variable here, since otherwise all bets are off of course in
the presence of concurrent access), but assuming the variable is atomic in
the Ada sense (something you can't specify in C, but you can in practice
count on, given a reasonable guess about the hardware and the compiler), 
there is still a fundamental question: how many reads are you allowed,
only 1, or are you allowed 2?

Re: Easily-Read C++?

[Robert Dewar]

Casper, you say that shared access to global data requires locking. This
plain isn't true, there are all sorts of algorithms that work fine with
shared variables. THe purpose of volatile (in either Ada or C/C++) and of
atomic in Ada, is precisely to facilitate this kind of usage. Sure in
some sense it is cleaner not to use shared variables (in another context
we would say it is cleaner not to use global variables, or even, if you
are a functional programming fan, that it is cleaner not to use *any*
variables).

However, both C and Ada recognize that in certain cases, the use of shared
variables is useful and legitimate (a bounded buffer with one consumer and
one producer is a classical case, see for example the coding of the keyboard
buffer in the PC BIOS).

THe point is that Ada's definition is considerably more secure that C/C++
here. That's the original point I was making. Ada naturally has to worry
about non-sequential semantics, since the standard includes non-sequential
execution. In the C standard however, there is no serious consideration of
concurrent semantics (that's what I mean by non-sequential here) because
the language itself has no such notion. However, lots of C programs do
have multiple threads and concurrent execution, and in such contexts, 
asking what is atomic, and how many times volatile variables are accessed
is of semantic significance.

Actually even in the absence of concurrent semantics, if a volatile
variable refers to a memory mapped I/O location, it may be quite important
to know how many times a variable is referenced, since the references may
have external semantic effects.

Of course a cautious programmer will simply avoid the use of ++mem for
such a variable, but it is a little uncomfortable for things to be so
ill-defined.

Re: Easily-Read C++

[Ken Garlington]

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.

Re: Attractive comments better?

[R_Tim_Coslet]

>One important key to writing readable C and C++ programs is to treat headers
>as the full equivalent of Ada specs, and comment them appropriately. 
>Historically, many C programmers treat headers as a kind of annoyance
>required by the silly compiler which can't figure it out for itself,
>and write the absolute minimum of text in headers with minimal comments.

Or worse yet, I've seen a few C programmers actually putting CODE (not
just declarations but actual CODE) in some header files! This results
in programs that mysteriously grow RAPIDLY in size of executable :-(
I couldn't believe it the first time I encountered it, at least Ada
simply will NOT let you even attempt this!

                                        R. Tim Coslet

Usenet: R_Tim_Coslet@cup.portal.com
        technology, n.  domesticated natural phenomena

Re: Easily-Read C++?

[Norman H. Cohen]

In article <37emcj$sk5@gnat.cs.nyu.edu>, dewar@cs.nyu.edu (Robert Dewar)
writes: 

|> 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.

Another purpose is to leave advice to future maintainers about how to
add enhancements that you have anticipated: 

   -- Additional devices can be accommodated by deriving new
   --   types from Driver_Type.

   -- To add a reserved word, simply add it to the aggregate used to
   --    initialize Vocabulary.  Add the new word in alphabetical
   --    order so that the binary search in Lookup will continue to work.

In modifying other peoples' code, I've sometimes found comments
performing another useful function as well:  Utterly incoherent comments
warn the reader that the original programmer had no idea what the
*(^%(*$)%!! he was doing, so that the reader knows to regard the code
with suspicion.

My favorite comment (for honesty, if nothing else) comes from a ksh
profile: 

   #the next two lines are copied from the korn shell paper
   #i don't know why it works, but it seems to

The runner up comes from an assembly-language program: 

   xor R3,R4,R3    THIS IS TRICKY.

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

Re: Easily-Read C++?

[John M. Mills]

WARNING: long-winded response follows:

In article <37en3i$sn7@gnat.cs.nyu.edu>, Robert Dewar <dewar@cs.nyu.edu> wrote:
>John (Mills), I assume that you see from my previous post that the question
>I posed is indeed a well defined one. I assumed that we are dealing with
>a volatile variable here, since otherwise all bets are off of course in
>the presence of concurrent access), but assuming the variable is atomic in
>the Ada sense (something you can't specify in C, but you can in practice
>count on, given a reasonable guess about the hardware and the compiler), 
>there is still a fundamental question: how many reads are you allowed,
>only 1, or are you allowed 2?

DISCLAIMER:  I am not a qualified language lawyer in either C or Ada!

Robert --

I apologize for missing the thrust of your posting.  I understand that C
defines the precedence, but not necessarily the order of evaluation of
elements of an r-value expression, so that implementation dependencies may
be encountered in using the unary ++ and -- pre- and post-fix operators.

Thus, I would not use an expression such as:
   y = ++x + x;

This is independent of the issue of parallel processes, whether interrupt-
activated or threaded.  I do not know whether judicious use of parentheses
can eliminate possible dependencies, either.

If the variable is declared 'volatile,' I would expect the compiler to read
the storage location each time I used the variable name in an expression or
control statement.  I would expect this is in Ada or C.  I don't know if this
removes all ambiguity in the case, for example, of a pointer-referenced
access.  (See DISCLAIMER.)

Were you suggesting that one thread of C code might intercede during the
evaluation of an expression on another thread?  Does Ada guarantee this
would never happen?  I am unsure what distinction you want to make here.
I took a quick look at the LRM index, but didn't turn up 'atomic.' Please
clue me on that.  Thanks.

We often use common variables and memory-mapped I/O in Ada to communicate
between tasks and between independent programs running on multiple processors
on a common VME bus.  We have had task-to-task interference in such cases,
on one processor.  In that case we could have used the rendezvous mechanism
to arbitrate the activity, but instead we created a lock/unlock package
which seems to work well.  I couldn't guarantee it immune to deadlock, but
it _will_ prevent invisible alteration of data by a competing task.  This could
be rewritten and used in C -- there's nothing special in our Ada.

I am quite interested in this question, as we encounter competitive access
fairly often in our designs.  We have taken the proverbial approach of
porcupines to sexual intercourse: we are very, _very_ careful! I have been
burned many times by this type of contention, and the most recent case
was in Ada.

I may still be missing the point.  If so, please excuse me and feel free to
try another tack -- maybe e-mail, since I'm rather obtuse.

Regards --jmm--

-- 
John M. Mills, SRE -- john.m.mills@gtri.gatech.edu -- (404)528-3258 (voice)
   Georgia Tech/ GTRI/ SDL, 7220 Richardson Rd., Smyrna, GA 30080
   "Well, I'm an Assistant Regurgitation Engineer --
     but I should make Senior R.E. next year" _The_Far_Side_, G. Larson

Re: Easily-Read C++?

[Norman H. Cohen]

In article <37emsq$smg@gnat.cs.nyu.edu>, dewar@cs.nyu.edu (Robert Dewar)
writes: 

|> is it permissible for ++c to STORE a different value from what it returns?
...
|> Reading the C standard clearly does not answer my question, so we must
|> presume that the two sequences of code have quite a different effect.

Actually, the C standard clearly indicates that this can happen even in
circumstances that do not involve concurrency.  The second paragraph of
ANSI C section 3.3 (which I think of as the ANSI C answer to Ada RM
section 11.6, at least in its ability to keep language lawyers busy
trying to interpret it) states: 

        Between the previous and next sequence point an object shall have
   its stored value modified at most once by the evaluation of an
   expression.  Furthermore, the prior value shall be accessed only to
   determine the value stored.[34]

   -------

   [Footnote 34] This paragraph renders undefined statement expressions
   such as

      i = ++i + 1;

   while allowing

      i = i + 1;

Sequence points are defined syntactically.  They include, for example,
the points after the evaluation of the left operand of the &&, ||, and
comma operators and the ends of statements.  The definition appears to me
to presume a single-threaded model of execution.

I suspect that a large portion of the C code in the field has technically
undefined semantics because it violates the quoted paragraph.

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

Re: Easily-Read C++?

[Robert Firth]

In article <37gnho$nbt@watnews1.watson.ibm.com> ncohen@watson.ibm.com writes:

>The runner up comes from an assembly-language program: 
>
>   xor R3,R4,R3    THIS IS TRICKY.

I forget the code, but the comment that I'll never forget is

	; DO A GOOD JOB ON THE SIGN BIT

However, my prize for all-time ingenuity in coding goes to the
programmer who was a great fan of Joni Mitchell.  The labels
in his program were the titles of her songs, broken up into
six-character chunks.  Ah, the joy of participating in a code
walkthrough, and coming out of it knowing only that Joni Mitchell
wrote "Song to a Seagull" - or, should I say, SONGTO ASEAGU LL...

In a similar spirit, I inserted into the proof copy of the Ada
Reference Manual the sentence

	The private type CHIPMUNK is predefined.

Alas, Jean noticed (he noticed everything).

Re: Easily-Read C++?

[John DiCamillo]

casper@fwi.uva.nl (Casper H.S. Dik) writes:
>firth@sei.cmu.edu (Robert Firth) writes:

>>The C code I've seen is absolutely littered with this stuff. I am
>>continually amazed that *anything* still works when people write
>>true multitasking code in C.

>Why?  The only think you need to take care of in C when writing
>multi-threaded code is using proper (explicit) locking of global
>data.  Most of the foo++ usages in C are of automatic variables.
>Those aren't shared between threads or even function invocations
>and consequently there is no problem with c++ kind of code.

>However, when incrementing a global variable one should do something
>like this:

>	set_write_lock(foo_lock);
>	foo++;
>	unlock_write_lock(foo_lock);

>The problem with C multi-threading is making the locking explicit.

>I really don't see what the difference between "foo = foo + 1"
>or foo++ is in this context.

Actually, in C++ there may be a big difference
in readability.  Since operator ++ is a function,
it can be overridden to include the locking:

	void f( Protected<Foo>& foo )
	{
		foo++;
	}

The class template Protected wraps the mutation
operators in lock()/unlock() pairs to guarantee
proper operation in the presence of threads.
(Other mutation functions on Foo can not be Pro-
tected quite so simply.)

-- 
    c'iao,
    milo
================================================================
    John DiCamillo                        Pinin' for the fjords?
    milod@netcom.com                  What kind of talk is that?

Re: Easily-Read C++?

[David Emery]

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
-------------------------------------------------------------------------

Re: Easily-Read C++?

[John DiCamillo]

perez@oldcolo.com (Carlos Perez) writes:

>John DiCamillo (milod@netcom.com) wrote:
>: perez@oldcolo.com (Carlos Perez) writes:

>: >i use 2 pgm n ada bt i chngd to oth pgm lang cuz ada usd 2 mny ltrs &
>: >evry1 thnx c s btr; i ms ada bt i cn wrt kwik now; 

>: You forgot to mention how much easier
>: it is for you to read vanity license
>: plates since you started using C.
>: All that practice with cryptically
>: abreviated variable names, you know.

>: Great post!

>In retrospect, I think I was a bit too cynical.  I apologize to the many
>competent and knowledgable C and C++ programers who do write readable
>code.

Apology accepted! ;-)

But this whole variable name length argument
is really beside the point.  (Reason: neither
language enforces or even encourages short
variable or type names.  People use certain
naming conventions because that's the way
they were taught, or because a standard is
enforced for a project.)

But there are many other aspects of program
readability.  Other people have jumped on
C++'s cryptic pure virtual notation (a wart
or at least a very bad pun) and its mostly
hideous declaration style (inherited from C).
Another place where readability suffers is
inside class templates (generics).  This
problem is partly due to templates being
hurried into the language without adequate
testing.

But even given all that, I still like C++
syntax because it is concise.  This allows
me to read unfamiliar code more quickly, and
to establish a mental schema for the abstrac-
tions more quickly.  Eiffel provides this
through 'short-flat' and Ada through package
specifications, but I think that C++ is more
effectively concise than those languages.

I'll readily admit it's not much of an argument,
but at least it's better than yammering away
about "mine's longer than yours".
-- 
    c'iao,
    milo
================================================================
    John DiCamillo                        Pinin' for the fjords?
    milod@netcom.com                  What kind of talk is that?

Re: "Tag" (Was: Easily-Read C++? (NOT))

[David Emery]

Ah, yes, a reading from the Gospel according to Tucker...
				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
-------------------------------------------------------------------------

Re: Easily-Read C++?

[Robert Dewar]

atomic is certainly listed in my LRM index (we *are* talking Ada 9X here, so
I am talking about the 9X 5.0 RM). If you want to talk Ada 83, then pragma
Shared serves the purpose of pragma Volatile and pragma Atomic rolled into
one (9X sensibly separates these concerns).

Obviously if you write:

   x = x + 1;

in either language, you know EXACTLY the meaning if x is atomic and
volatile. Sure some other thread can come in, but the exact range of
possible effects is well understood, and for example, you can easily
implement Djkstra's semaphore algorithm to get coordination of two
processes without any explicit system level communication or rendez-vous
etc. I am not particularly suggesting you want to do this, but you can.

Now if in C, we replace this with:

  ++x;

then we really are not quite sure what that means. No one thinks it means
that you can only reference x once, because unless you are on a specialized
machine with a fetch-and-add (like the x86), then there is no instruction
or instruction sequence that can achieve this in one reference.

So, is it the case (remembering that x is volatile and atomic) that there
can be at most two references? Well that seems a possible reasonable thing
to say, but there is nowhere in the C reference manual that you can deduce
such a rule.

I trust that makes this clear, or at least clearer.

Re: Easily-Read C++?

[Keith Thompson @pulsar]

In <124377@cup.portal.com> R_Tim_Coslet@cup.portal.com writes:
> In article: 36v90m$9r4@cmcl2.NYU.EDU> 
> 	kenner@lab.ultra.nyu.edu (Richard Kenner) wrote:
> >There are actually times when it can!  Consider the following fragment
> >of an assembler language program for the PDP-11 written by someone who
> >was told to write a comment on every line:
> >
> >	ADD	#1,R0		;Add one to R0.
> >
> >That actually *does* slow down reading!
> >
> >One company, either DEC (I think) or CDC (less likely) actively
> >discouraged this sort of thing in their coding standard.
> 
> Useless comments like that should be BANNED.

I agree, but only 99% of the time.

Comments should be designed for the enlightenment of the intended
audience.  In most cases, the intended audience is the person maintaining
the code (possibly the original author, possibly someone else), who
presumably is fluent in the language being used.  If the line appears
in chapter 1 of an introduction to PDP-11 assembly language, the comment
"Add one to R0" is perfectly appropriate.

-- 
Keith Thompson (The_Other_Keith)  kst@alsys.com
TeleSoft^H^H^H^H^H^H^H^H Alsys, Inc.
10251 Vista Sorrento Parkway, Suite 300, San Diego, CA, USA, 92121-2718
/user/kst/.signature: I/O error (core dumped)

Re: Attractive comments better?

[Michael Feldman]

In article <37du0k$ir2@gnat.cs.nyu.edu>, Robert Dewar <dewar@cs.nyu.edu> wrote:

>Note that I am perfectly aware that some C/C++ programmers fully understand
>the structural importance of headers, but a distressing amount of code, even
>on large systems, is written without this awareness, and the headers are
>an uncommented mess.

And an amazing number of C books do not even take cognizance of the
notion that a header file can be used for this purpose (equivalent
to an Ada spec). I went shopping for intro C books recently, to find
one I could use in my file structures course, in which I'm easing the
students from Ada to "C with an Ada accent".

I had 4 main criteria for a book, which narrowed the search from _hundreds_
(in the Computer Literacy Bookshop) to just a very few:

1. diskette of programs, and (better) a compiler shrink-wrapped;
2. suitable for self-teaching (I'm not going to teach C ab initio,
   because the students have had 2.5 semesters of Ada and some
   assembler already;
3. did justice to files, especially binary ones;
4. used headers adequately

It was _very_ tough to find one. In the end, 3 and 4 got lower priority
than 1 and 2. But looking at all the junk books on the market, one can
easily see where all the junk code comes from.

>Now of course people could write similar useless messy Ada specs, but both
>the language and the culture emphasize the importance of specs so
>energetically that this is relatively unusual in the Ada world.
>

And the C culture, in general, emphasizes it very little.

Mike Feldman
------------------------------------------------------------------------
Michael B. Feldman -  chair, SIGAda Education Working Group
Professor, Dept. of Electrical Engineering and Computer Science
The George Washington University -  Washington, DC 20052 USA
202-994-5919 (voice) - 202-994-0227 (fax) - mfeldman@seas.gwu.edu (Internet)
"Non illegitimi carborundum." (Don't let the bastards grind you down.)
------------------------------------------------------------------------

Re: Easily-Read C++?

[John D. Reading]

In article <37gnho$nbt@watnews1.watson.ibm.com> ncohen@watson.ibm.com writes:
>My favorite comment (for honesty, if nothing else) comes from a ksh
>profile: 
>
>   #the next two lines are copied from the korn shell paper
>   #i don't know why it works, but it seems to
>
>The runner up comes from an assembly-language program: 
>
>   xor R3,R4,R3    THIS IS TRICKY.
>
>--
>Norman H. Cohen    ncohen@watson.ibm.com

I am certainly liable to be flamed for wasting bandwidth, but one of
my favorite comments was one I penned myself.  After spending some
unreasonable amount of time to get a very convoluted line of LISP
code working I added the comment:

;; That's what I like about LISP - it's self documenting

Those were my innocent pre-Net days; I didn't know about smileys.

But to bring this back to the topic under discussion, in my experience
(which includes a lot of LISP, FORTRAN, and C, and a little Ada),
there are no "easily read" languages.  There is no substitute for
learning the language.  Comments, however, are always useful for
giving a more global view of *why* something was done the way it
was.  Perhaps it is worth adding that the above *bad* comment was
involved in the code for a compiler for a proprietary language
which was supposed to be perfectly readable.  Those unfamiliar
with tha language discovered they could read a program and
understand the sequence of steps it represented without being
able to tell why they were done.  Some well-written comments were
still necessary to add that understanding.

John Reading
readingj@cerf.net

Re: Easily-Read C++?

[Bob Wells #402]

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. (-:

Re: Easily-Read C++?

[Kevin Cline]

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

Re: Easily-Read C++?

[Thomas M. Breuel]

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.

Re: Easily-Read C++?

[Michael M. Bishop]

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.                  |

Re: Easily-Read C++?

[-mlc-+Schilling J.]

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

Re: Easily-Read C++?

[Bob Duff]

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.)

Re: Easily-Read C++?

[Richard Kenner]

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.

Re: Easily-Read C++?

[Robert Dewar]

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 ...)

Re: Easily-Read C++?

[Adam Beneschan]

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

Re: Easily-Read C++?

[Bob Duff]

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.)