From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,a187c77b231bfca6
X-Google-Attributes: gid103376,public
From: eachus@spectre.mitre.org (Robert I. Eachus)
Subject: Re: access to subprogram disciminants
Date: 1996/04/26
Message-ID: <EACHUS.96Apr26135437@spectre.mitre.org>#1/1
X-Deja-AN: 151569097
references: <4lp3sc$glg@news1.delphi.com>
organization: The Mitre Corp., Bedford, MA.
newsgroups: comp.lang.ada
Date: 1996-04-26T00:00:00+00:00
List-Id: <comp.lang.ada>


In article <4lp3sc$glg@news1.delphi.com> tmoran@bix.com writes:

 >    I had thought that 'constructor' in C++ was close to 'procedure
 > initialize' for an Ada 95 Controlled type.  I also thought that the
 > only parameters available to procedure 'initialize' were discriminants
 > or other members of the record structure being initialized.  Further,
 > the compiler will insist that values be supplied for (non-default
 > valued) discriminants, whereas I can't get the compiler to enforce a
 > requirement for *any* values for the rest of the record components.
 > Am I mistaken?

   Yes.  If a record component has a default initial value, you can
never create a record object where it's value is undefined.

   If you want to change a record discriminant, you are required to
assign an aggregate value so that any components which depend on the
discriminant have valid values.  This is nice for preserving the
principle above, but makes changing discriminants that do not
determine the other record components a lot more error prone.

   (Notice that it is possible in Ada to have discriminants on
subcomponents which are records that are not discriminants of the
parent type, and in fact the parent type may have no discriminants.
Take advantage of this to keep necessary discriminants as closely to
the components they control as you can.)

  > >Don't try to make all of these "parameters" into discriminants.
  > >Just declare them as components of the data type.  Then, a user would
  > >declare a simple "Frame_Window" or whatever, and initialize it from the
  > >result of a function call, or by a subsequent procedure call.
  >   But that function or procedure call might be left out, causing
  > a run time error.

   Yep, could be.  If you are that paranoid--and sometimes it is
correct to be--what I usually do is define a default initial value
that raises an exception.  Do it right, and your compiler will tell
you about it for every object which does not explicitly call an
constructor.

   type T is record...

     S: String(1..4) := (-3..0 => ' ');
   end record;

  >   I try to think of an Ada compiler not just as a tool to do scut
  > work like converting code in an HLL to binary, but as a somewhat
  > intelligent helper guiding me away from error.  Sort of like the
  > difference between a rod and hangers keeping my clothes off the
  > floor, vs a gentleman's valet suggesting that a particular tie
  > might not be the best choice with a particular suit.  So I'm
  > trying to arrange things so the language and compiler will be as
  > helpful as possible.

    I try to do the same, but you have to be willing to listen to the
valet.  Get a compiler that issues good warning messages and never
turn them off.

    I had an example yesterday.  Recompiled some (GNAT compiled) code
that looked to be pure Ada 83 in VADS and got two warning messages.
Looked at the source and realized that Ada 83 did not allow sliding in
that context.  Modified the code and everything worked when finally
executed.  Much better than using the debugger.
--

					Robert I. Eachus

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