Shoot!  I hit the wrong key and sent my message before it was done!

As I was saying, you could have written this:

     type IntSubtypeAccessType is access IntSubtype;
     IntSubtypeAccess : IntSubtypeAccessType

     begin
        IntSubtypeAccess := new IntSubtype'(15);
        IntSubtypeAccess.all := 33;
     end;

and then, you *would* have gotten a Constraint_Error, because the expression
in the assignment is out of the range of the designated subtype of the
access type.  (In fact, in this program most compilers will give you a
warning that the exception will be raised at runtime).

> In my oppinion there
> has been a new IntSubType-Instance (doesn't fit really well better would
be
> container)

'Object' is the correct Ada term...

> and the address of the  Instance will be assigned to the access
> variable IntAccess.

Your opinion is wrong :-)

    new IntSubtype'(15)

does not "create a new IntSubtype instance".  This part _is_ a little bit
confusing, I'll grant you.  It creates a new object of the base type of
IntSubtype (i.e., Integer).  But if it were not this way, all kinds of other
things would end up being much _more_ confusing, trust me :-).  The point
is, you didn't know how to write it correctly, and now you do :-).  But I
think part of your confusion may arise from not really understanding
subtypes... I wonder if perhaps you are thinking of them as something like a
"subclass"?  One really must have a proper understanding of the relationship
between types and subtypes.  Once you do, the semantics of allocators makes
perfect sense.  Individual objects do not carry around little tags that say
what their subtype constraints are, which is what you are really asking for.

> When I assign 33 to the Instance it should be a constraint
> error. We went through the LRM and could only assume why this is a propper
Ada
> programm. Not a plus for the LRM!

Not a plus for you! :-)  The rule (3.10(10) as I said in my first post,
before I cut myself off :-) is not hard to find or understand, it's right
there in the section of the RM where access types are introduced.

But now you know how to write this correctly.  Declare the access type to
designate the subtype you want.

>
> Another thing is, that the variables should be initialized by default, or
it
> should be made necessary to initialize the variables with a value. Points
to
> make the language saver.
>
> The arbitrary order in evaluating operands for operations should be stated
clear
> as from left to r�ght. There is no point in still keeping those things up
that
> make sideeffects compiler dependend (sure I dont like sideeffects - it is
not a
> good programming style, but a language should fix the order - to give
everything
> a little more security how something is evaluated.)

Both of those things are very unlikely to be changed, for reasons having to
do with performance.

With regard to default initialization... you should know if you do not
already that all objects of an access type are default initialized to null.
For other types, default initialization does not actually make programs
_safer_; it just makes an erroneous program fail in a more consistent
manner.  Static analysis tools can be used to check for dependence on
uninitialized variables.

>
> If we compare different Languages, then we should check why another
language is
> more famous then Ada and think about getting those attributes into Ada
without
> damaging Adas safty, it is not easy for sure, but for Ada to become a more
> famous Language, it has to be done.

There are many reasons why languages vary in popularity, and technical
features are only one factor.

Best Regards,
mark

--
-------------
Reply by email to: Mark dot Lundquist at ACM dot org
Consulting services: http://home.attbi.com/~mlundquist2/consulting