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,9a7e0c43216f4def X-Google-Attributes: gid103376,public From: Matthew Heaney Subject: Re: "out" or "access" Date: 1998/11/01 Message-ID: #1/1 X-Deja-AN: 407153176 Sender: matt@mheaney.ni.net References: <908956499.754394@dedale.pandemonium.fr> <70mo3h$gll$1@cf01.edf.fr> <71cjab$ka8$1@nnrp1.dejanews.com> NNTP-Posting-Date: Sat, 31 Oct 1998 19:04:21 PDT Newsgroups: comp.lang.ada Date: 1998-11-01T00:00:00+00:00 List-Id: Robert A Duff writes: > Perhaps you should have two different sorts of iterators, one that can > modify, and one that can't. Yes, I thought of that too, but I was trying to keep things simple. > > So perhaps I'm going beyond what even access constant params buy you. > > Maybe my real problem is how to "cast away const." > > Sounds dangerous. "const" in the sense of in param: function Set_Top (Stack : Stack_Type) return Item_Access is SA : constant Object_Pointer := To_Pointer (Stack'Address); begin pragma Assert (Stack.Length > 0); return SA.Items (Stack.Top)'Access; end Set_Top; So the client can: Set_Top (Stack).all := 10; Of course, here it's not strictly necessary, since I can declare Set_Top to take an access parameter. The "const" thing is the entity passed as the in-param of the function call. In my case, the entities are always tagged, and so are aliased, and so taking the address is well-defined. The behavior I'm thinking of is analogous to what happens when you call function Random of the random number generator. Essentially, I'm trying to get around Ada's lack of in out params for functions. How does the Ada programmer implement his own abstractions whose functions have state-changing behavior -- like Random does? Yes, yes, I know you can implement the abstraction as a controlled record containing a pointer to the "real" data, but I was investigating cheaper alternatives. Why is the RM so silent on intended uses of package System.Address_To_Access_Conversions? If the designers don't intend for you to use it as in my example above, then why doesn't the RM just come right out and say that? > > BTW: does the language define --or give implementation advice-- on what > > the effect of unchecked conversion from access-to-constant to > > access-to-variable is? Or is it the intention of the designers that you > > never try to do that? > > I think you should not do that. What should it mean? I mean, if you > modify a constant? An Ada compiler is within it's rights to put > constant stuff in read-only memory -- and if you modify it, you get a > core dump or some such nasty thing. Or share memory for the same > constant data -- you better not change it. I should have asked, How do the language designers intend Ada programmers to implement a side-effect producing function, whose param (of mode in) is a tagged type? When I do this: function Set_Top (Stack : Stack_Type) return Item_Access is begin ... Stack'Access ... this gives me an access-to-constant view. I want an access-to-variable view. I wasn't trying to change a "constant," in the sense of a constant object declaration (which isn't possible for limited types anyway), but rather I was trying to turn a constant view --of an otherwise modifiable object-- into a variable view. > Perhaps you should give an example. It seems like cast-away-const is > even worse than any type-cheating one might want to do. > > Oh yes, but this doesn't meet my needs, because you need to call a > > dispatching operation ("factory method") that returns an iterator of a > > class-wide type. Class-wide types are indefinate, and therefore require > > initialization during object declaration, which isn't possible if the > > type is limited. > > I wish we could initialize limited things, but still not copy them > around. Sigh. I would be really swell if we had constructors too, not just functions trying to do the job. The latter technique doesn't work for limited types.