Re: Side-effect arithmetic again [was: Ada ... in embedded systems]

[eachus@spectre.mitre.org (Robert I. Eachus)]

   Bob Duff (bobduff@world.std.com) said:

  > Using Increment instead of "++" isn't going to make the program horribly
  > verbose.  My complaint is that people are suggesting a generic
  > instantiation, which is a bunch of useless verbosity, to replace
  > something that's very simple in C...

  > If you try to convince a C programmer to change "foo[i]++;" to
  > "Increment(Foo(I));", that's fine.  But to require a generic
  > instantiation in addition would make the C programmer laugh, and rightly
  > so.  I think we'd be better off just admitting that there's no direct
  > replacement for ++ in Ada, and tell the programmer, "Sorry, but you have
  > to write "Foo(I) := Foo(I) + 1;".

    No, I think we are converging to the "right" solution...  You
object, and I think rightly, to asking programmers to instantiate a
generic to get Increment for integer types.  Would you settle for a
use clause?  I beginning to conclude that the right solution for
Integer is a non-generic package.  For enumeration types, you need a
generic, but then again, any enumeration type you want the operations
for will already require a declaration.  Adding another line seems
acceptable.

    The only question that now remains is does it make sense to have
an "extended" Integer type with additional operations that can be
derived from?  Possibly, but I don't think the major need for such a
type is to provide increment and decrement.  It is needed for mixed
mode operations found in some C programs that combine logical bitwise
operations, shifts, SIGNED arithmetic, and ignoring of overflow.  A
very special type, and in Ada 95, quite easy to build.

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...