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,b47b15fda2aeb0b2 X-Google-Attributes: gid103376,public From: jsa@alexandria (Jon S Anthony) Subject: Re: Two ideas for the next Ada Standard Date: 1996/09/04 Message-ID: #1/1 X-Deja-AN: 178331247 sender: news@organon.com (news) references: <50aao3$3r88@news-s01.ny.us.ibm.net> organization: Organon Motives, Inc. newsgroups: comp.lang.ada Date: 1996-09-04T00:00:00+00:00 List-Id: In article <322C40B1.534A@ehs.ericsson.se> Jonas Nygren writes: > I just state a fact of my own Ada code, it could be that I have > not yet learnt how to write good Ada code. I think that is getting at it. > In Ada, pointers are > distinct types which differs from C/C++, eg: > > type X1A is access X; > type X2A is access X; > X1P : X1A; > X2P : X2A; > To use X1P and X2P together often requires conversions. > > X *x1p, *x2p; Well, why would you declare TWO access types to the same designated type, unless you really DID want tow DIFFERENT types that were in fact distinct???? If you just want to rename for some reason then use the renaming for types - subtype: subtype X2A is X1A; X1P : X1A := ... X2P : X2A := X1P; -- No problem or conversion... > In C/C++ there is only one pointer type for each object type. > (if we disregard const, typedefs are just syntactical sugar). Well, if this is what you want - just do it. Nothing prevents you from either A) only declaring the ONE access type or B) using subtype renamings. The C/C++ case is just a simple subset of what you can do. > In Ada you have to carry around both object and pointer type > everywhere you might want to use it - if you don't you will > often need to do some conversion. Not if you just do what you really seem to want. > If you write code using tagged types you often want to use dynamically > allocated objects and hence use access values in function/procedure > calls. When one pass 'the object' as an access argument the 'object' > will always have mode 'in out' , it is not possible to pass the > object with only 'in' mode. If you are really this concerned about this why not just make the type limited private? Clients can't access the state (except through the interface) and they can't assign the things. For _clients_, it is strictly _in_ mode. In the body of the primitive operations defined in the interface, you can update the individual fields (if they are not limited) of the object designated by the parameter, but you can't assign it. This is rather more secure than the analog C++ where you get a small piece of this with const T* arguments. > So if you want to provide functions or procedures which restricts > the update of 'the object' then you have to provide an interface > with a mix of 'access' and 'in' modes with the following confusion > for the user of the interaface who will need to use a mix of P1(XA) > and P2(XA.all). It is very ugly and confusing to use such > interfaces. I don't understand this at all. You're correct - it is very confusing... > (one could ask why one ever would use 'access constant' and I > would reply: for the very same reasons as we have for the 'in' mode) > > I want the 'access constant' feature for practical reasons, not out of > C++ notsalgia. That sounds correct as you never had what you really seem to want in in C++ either. /Jon -- Jon Anthony Organon Motives, Inc. 1 Williston Road, Suite 4 Belmont, MA 02178 617.484.3383 jsa@organon.com