pointer questions
in [ADA]
|
Prev: Survey on the Effects of Organizational Culture on Software Productivity
Next: Eclipse Ada Support - FYI
From: Martin Dowie on 27 Oct 2005 15:28 Marc A. Criley wrote: > Martin Dowie wrote: >> Embedded defence apps and I can't remember the last time I needed an >> access type! >> >> There's no need in this sort of app, as you know at compile time what >> the maximum number of anything your system is required to deal with, >> so you can always use a lookup table of some sort (even if it has an >> 'In_Use : Boolean' field/discriminant. > > > Now that is exactly the domain where I would expect to not see access > types, for the reasons you cite (as well as related reasons having to do > with predictability and the consequences of errors.) More error related than predictability I hope! Or is there some dangerous non-determinism associated with access types I haven't come across yet?! :-) Cheers -- Martin
From: Robert A Duff on 27 Oct 2005 20:12 Martin Dowie <martin.dowie(a)btopenworld.com> writes: > Marc A. Criley wrote: > > Martin Dowie wrote: > >> Embedded defence apps and I can't remember the last time I needed an > >> access type! > >> > >> There's no need in this sort of app, as you know at compile time what > >> the maximum number of anything your system is required to deal with, > >> so you can always use a lookup table of some sort (even if it has an > >> 'In_Use : Boolean' field/discriminant. > > Now that is exactly the domain where I would expect to not see access > > types, for the reasons you cite (as well as related reasons having to > > do with predictability and the consequences of errors.) > > More error related than predictability I hope! Or is there some > dangerous non-determinism associated with access types I haven't come > across yet?! :-) Not with access types per se, but if you do heap allocation using the default storage pool, it's hard to predict if/when you will run out of memory. But if you use user-defined storage pools, you can make them predictable (and then access types become pretty-much equivalent to your "lookup table of some sort"). - Bob
From: Robert A Duff on 27 Oct 2005 20:42 "Jeffrey R. Carter" <spam(a)spam.com> writes: > Robert A Duff wrote: > > Never? Well, these kinds of low-level hacks are _rarely_ a good idea. > > But you might need them when interfacing to some other language > > that uses such trickery. > > True, but then you're not using Ada, you're using Ada and X, which I > addressed later. For just Ada, you never need the kind of pointers the > OP was asking about. > > > Maybe the kinds of programs I write are different. Question for those > > who rarely use access types: what sort of application areas are you > > talking about? Mine are usually software development tools -- such as > > compilers. > > Maybe. I use unbounded data structures frequently, but I don't write a > new one every time. Instead, I reuse existing generic data structures, > so the code I write doesn't contain those access types. Yeah, me too. >... When you talk > about all the access types in your compiler code, are you talking about > frequent creation of new access types, reuse of existing but exposed > access types, or reuse of packages that hide the use of access types? > That will help decide if compilers are different. All of the above. ;-) I don't know how to create mutually recursive data types in Ada without access types, or something pretty-much equivalent to them (e.g. indices into an array can be used as "pointers"). In compilers, such data structures are common. Think of an abstract syntax tree. I want to say, an expression can be a function call, and a function call contains actual parameters, and actual parameters contain expressions. You can't say that directly in Ada -- you have to introduce access-to-expression, or some such thing. An abstract syntax tree for Ada will have upwards of a hundred different tagged types (or variants, if you go the variant record route). And you need access types all over the place, because these things are highly recursive. > For learning Ada, one should write some dynamic data structures, but to > use Ada, you should reuse existing dynamic data structures. I don't > count access types hidden in reused packages as using access types. Fair enough. > Recently, I've written a generic package for genetic algorithms, and a > TSP program that uses it, and a package to implement the Nicias > encryption algorithm, and a program that uses it. Nary an access type in > sight. > > > If I designed a language, I would go even further in that direction. > > I would allow mutually recursive types without intervening pointers. > > The only need for pointers in my language would be where > > reference semantics is desired -- e.g. when you want two pointers > > to the same object, such that updates to that object can be seen > > through both. > > We're still waiting to see an informal specification for Duff, or > whatever it's called :) ;-) You and I might have to wait a long time for that, given that I have to make a living. I can do so making compilers and other tools, but since the Ada 9X project, nobody seems interested in paying me to do language design. Sigh. For now, it's a hobby. I don't even know what to call it. Not "Duff", for sure. ;-) > > I don't really agree. A beginner to Ada who knows how to program > > (in some other language, such as C) might well want to make a > > linked list, for example, and that requires pointers of some > > sort -- usually access types. > > Again, for learning Ada, certainly. For using Ada, no. Part of learning > Ada is learning to reuse. Even after the beginner has crafted a generic, > unbounded list to learn about generics, access types, memory management, > and information hiding, it's still a good idea for him to use the > unbounded list component from <your favorite library here> (or > Ada.Containers in 0X) to learn to reuse others' packages, and to gain > the benefit of SW that has been much more thoroughly tested than his own > effort. I agree. > My comments that pointers are rarely needed in Ada are usually addressed > to beginners coming from C who think they must use pointers for > everything, from passing a parameter that can be modified to creating an > array with bounds known only at run time. I hope that my saying this > will cause them to stop, every time they think they need a pointer, and > see if perhaps Ada can do it without one. In that way, perhaps they will > gain a better understanding and appreciation of Ada. I see what you mean, but I think it might be more helpful to point out the specific cases where pointers are unnecessary in Ada: If you want to loop through an array, don't use pointers like you do in C. If you want to modify a parameter, use 'in out', instead of an explicit pointer, and trust the compiler to pass by-ref when appropriate. (Except that it's embarrassing that you can't say 'in out' in functions.) If you want a dynamic-sized thing, and you know the size at object-creation time, and the size doesn't change, you don't need pointers in Ada. If you want a dynamic-sized record component, discriminants may be in order. Etc. Just saying "You hardly ever need pointers in Ada" is misleading, IMHO. - Bob
From: Martin Dowie on 28 Oct 2005 01:58 Robert A Duff wrote: > I don't even know what to call it. Not "Duff", for sure. ;-) C$ ??? :-)
From: David on 28 Oct 2005 07:53
Robert A Duff wrote: > "Jeffrey R. Carter" <spam(a)spam.com> writes: > > >>Szymon Guz wrote: >> >> >>>I've got some maybe stupid questions but I don't understand some things: >>>1. Is there a pointer like (void *) from C that points to anything ? >>>2. Is there a universal (like above) pointer for procedure|function >>>that can point to any kind of procedure|funcion ? >> >>The short answer, as you've already heard, is No. > > > Well, type System.Address can be used in that fashion. > Or you can say "type Void_Star is access all Void;" > and use unchecked conversions. So I'd say the answer is > "Yes, but you don't usually want to do things this way." > > >>The long answer is that you'll never need these to use Ada. > > > Never? Well, these kinds of low-level hacks are _rarely_ a good idea. > But you might need them when interfacing to some other language > that uses such trickery. > > >>...In fact, >>you'll rarely need pointers at all. > > > I've heard that claim many times in this newsgroup. It doesn't match my > experience at all. I use pointers all the time. > > I just checked one project. About 500 named access types in about a > quarter million lines of code. That's about one named access type for > every 500 lines of code. Do you call that "rare"? (I didn't count > anonymous access types -- there are probably hundreds of those > in this project, too.) > > There are also about 500 packages in this project. > > You need pointers in Ada whenever you have complex (linked) data > structures. Also, whenever you don't know the size of an object > at the point it is created. Also, whenever the size of an object > changes wildly over time. > > And whenever you have recursive types. (E.g. in a compiler, an > expression contains subexpressions; in Ada you will need pointers > to accomplish that, since you can't do it directly.) > > And whenever you want to pass a composite type as a discriminant -- you > have to create a bogus pointer: > > type T(Some_Task: access Some_Task_Type) is ... > > (because "Some_Task: Some_Task_Type" is annoyngly illegal. > > Maybe the kinds of programs I write are different. Question for those > who rarely use access types: what sort of application areas are you > talking about? Mine are usually software development tools -- such as > compilers. > > It is true that C requires or encourages pointers in cases where Ada > does not. Two examples: (1) a common idiom in C is to loop through an > array using a pointer. In Ada, you would use an index instead > (which you can also do in C). (2) In C, you need to use heap > allocation if a struct contains a field whose size is not known > at compiler time. In Ada, you could use a discriminated record > instead. > > If I designed a language, I would go even further in that direction. > I would allow mutually recursive types without intervening pointers. > The only need for pointers in my language would be where > reference semantics is desired -- e.g. when you want two pointers > to the same object, such that updates to that object can be seen > through both. > > >>... If you think you do, especially for >>beginning Ada, then you're probably misunderstanding something. > > > I don't really agree. A beginner to Ada who knows how to program > (in some other language, such as C) might well want to make a > linked list, for example, and that requires pointers of some > sort -- usually access types. > > >>About the only time you'd need anything like these is when interfacing >>to C. Judging from your questions, I suspect your understanding of Ada >>is not yet at a level where you should be doing that. > > > Well, a programmer coming from C might well have some C code lying > around, and might well want to call it from Ada! > > - Bob I develop larg'ish mission-critical systems in Ada and cannot use pointers, dynamic memory allocation, tasks, variants, recursion, etc. etc. You can always find a way to not use pointers as long as you stick to Ada (not interfacing C/C++). Memory mapped hardware can be accessed using an expression like "for x'address use at <hardware address>". You can declare one variable on top of another the same way. Trying to get code safety-certified with pointers is very difficult to impossible. Code that doesn't use pointers is invariably simpler and more reliable but it may require more thought depending upon mind-set. regard ... David |