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.9 required=5.0 tests=BAYES_00 autolearn=ham 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: ok@goanna.cs.rmit.edu.au (Richard A. O'Keefe) Subject: Re: Two ideas for the next Ada Standard Date: 1996/09/04 Message-ID: <50jitv$j4a@goanna.cs.rmit.edu.au> X-Deja-AN: 178406650 references: <50aao3$3r88@news-s01.ny.us.ibm.net> <322B5BB0.422E@joy.ericsson.se> <50gelc$2le@goanna.cs.rmit.edu.au> <322C40B1.534A@ehs.ericsson.se> organization: Comp Sci, RMIT, Melbourne, Australia nntp-posting-user: ok newsgroups: comp.lang.ada Date: 1996-09-04T00:00:00+00:00 List-Id: 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. 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. But this is entirely a problem of your own creation. If you *want* X1P and X2P to be compatible, use the same type for them. >X *x1p, *x2p; You can accomplish this by doing type X_Ptr is access X; X1P, X2P: X_Ptr; >In C/C++ there is only one pointer type for each object type. >(if we disregard const, typedefs are just syntactical sugar). Well, there are actually 'const' and 'volatile' (which _does_ change the semantics) and it looks as though 'restrict' will make it into the next revision (C9X); the SPARCompiler C 4.0 compiler already supports it. So C89 has 4 incompatible flavours of pointer-to-X and C9X will probably have 8 of them. >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. Bear with me. I am having real trouble understanding the problem. Somewhere there is a package: package X is type T is something or other; type Ptr is access T; ... end X; So I don't "carry around" _either_ an object or a pointer type. Whenever I want either type, I ask the package. Object: X.T; Pointer: X.Ptr; The issue here is that if it makes _sense_ for the rest of the program to manipulate both objects and pointers, then the package that exports the object type should export both types. >And dispatching on return values from functions. But I still like >X.P better than P(X) because I immediately can see what object I am >operating on. With P(X,Y) one would have to go back to the definition >of P to know if it dispatches on X or Y. But this is something one >have to adopt to - Ada will never change to X.P notation. Um, in C++ you _don't_ know which argument the operation is really dispatching on. If you write X.P(Y) X.P can often be resolved at compile time (so no dispatch takes place) while calls _inside_ P may dispatch on Y, and this may be important. Consider for example Stream << Thing; in C++. What does _that_ dispatch on? There is a combination of overloading and dispatching going on, which are similar. In fact there can be both overloading and dispatching in any C++ method call, so it really isn't as obvious as it looks. In your own code, there is nothing to stop you adopting a convention that you will only dispatch on the first argument. Me, I _like_ being able to write both Add_Element(Set, Element) Is_Member(Element, Set) >> >E.g. I can not understand why one cannot have an anonymous access >> >argument which refers to a constant, e.g P(X : access CONSTANT XT). >> >Why not? What ever could have been said against this? Premature? >> >> What exactly does this buy you that an "in" argument doesn't buy you? >> It looks _awfully_ like a demand that Ada look like C++ (const ref). >If you write code using tagged types you often want to use dynamically >allocated objects and hence use access values in function/procedure calls. Ah *hah*! Now I understand. Simple answer: you *really* don't want to do that. If Stroustrup has his way, C++ will become like Ada already is: garbage collection is allowed, but not required. The only way you can be *sure* that storage for a dynamically allocated object will be released is to do something to that access value. So what's happening here is that Ada is preventing you adopting a coding style that guarantees massive storage leaks. I can't regret that! Either that or I have misunderstood again. What stops you writing package X is type T is type Ptr is access T; type Const_Ptr is access constant T; function P(X: Const_Ptr, ... >who will need to use a mix of P1(XA) and P2(XA.all). It is very ugly >and confusing to use such interfaces. Yes, but it is very ugly and confusing to use interfaces which require the client to deal with both objects and pointers _anyway_. Q: What do Simula 67, Smalltalk, Common Lisp Object System, YASOS, Java, NewtonScript, Self, Cecil, all have in common? A: Clients always deal with *pointers* to objects, never with "bare" objects. I note, for example, that the draft ANSI document "Object Oriented Extensions to Pascal" (that's extensions to _modern_ Pascal, which already has modules and type schemes) envisages a model in which programs *cannot* access objects directly; so ANSI Object Pascal (when it comes out) will join the list of OOP languages above. It might be interesting to see a larger example. I expect that I would learn a lot from it. -- Australian citizen since 14 August 1996. *Now* I can vote the xxxs out! Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.