* pointer questions @ 2005-10-26 23:01 Szymon Guz 2005-10-26 23:51 ` Gene ` (5 more replies) 0 siblings, 6 replies; 34+ messages in thread From: Szymon Guz @ 2005-10-26 23:01 UTC (permalink / raw) Hi, 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 ? regards Szymon Guz ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: pointer questions 2005-10-26 23:01 pointer questions Szymon Guz @ 2005-10-26 23:51 ` Gene 2005-10-26 23:58 ` tmoran ` (4 subsequent siblings) 5 siblings, 0 replies; 34+ messages in thread From: Gene @ 2005-10-26 23:51 UTC (permalink / raw) The package System has an Address type with comparison operations defined, and the package Address_To_Access_Conversions supports conversions between addresses and pointers. With the loss of some portability, you can also use Unchecked_Conversion to turn one kind of pointer to another, so you can set up your own "void*" equivalent type and convert to/from specific pointers. A universal pointer to function/procedure pointer is a marginally useful and very dangerous idea. But on most architectures you can use unchecked conversions to implement this kind of thing and get away with it. ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: pointer questions 2005-10-26 23:01 pointer questions Szymon Guz 2005-10-26 23:51 ` Gene @ 2005-10-26 23:58 ` tmoran 2005-10-27 1:12 ` Stephen Leake ` (3 subsequent siblings) 5 siblings, 0 replies; 34+ messages in thread From: tmoran @ 2005-10-26 23:58 UTC (permalink / raw) > 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 ? No. But in both cases you can do an explicit Unchecked_Conversion to convert a pointer to one thing into a pointer to something else. You are then explicitly telling the compiler, and future maintainers of your program, something like "yes, I know I'm calling a function that expects two Floats with just a single Character, but I've thought about it and it's correct in this case." ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: pointer questions 2005-10-26 23:01 pointer questions Szymon Guz 2005-10-26 23:51 ` Gene 2005-10-26 23:58 ` tmoran @ 2005-10-27 1:12 ` Stephen Leake 2005-10-27 2:30 ` Steve ` (2 subsequent siblings) 5 siblings, 0 replies; 34+ messages in thread From: Stephen Leake @ 2005-10-27 1:12 UTC (permalink / raw) Szymon Guz <alpha@skynet.org.pl_WITHOUT> writes: > Hi, > 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 ? As others have said, the short answer is "no". However, depending on what you really want to do, there are ways to define one pointer that can point to different functions at different times. One way is a simple 'access subprogram type. Another is class wide programming on an inheritance type heirarchy. Can you say something about what you are trying to do (assuming it's more than "make Ada look like C")? -- -- Stephe ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: pointer questions 2005-10-26 23:01 pointer questions Szymon Guz ` (2 preceding siblings ...) 2005-10-27 1:12 ` Stephen Leake @ 2005-10-27 2:30 ` Steve 2005-10-27 5:56 ` Jeffrey R. Carter 2005-10-27 17:19 ` Martin Krischik 5 siblings, 0 replies; 34+ messages in thread From: Steve @ 2005-10-27 2:30 UTC (permalink / raw) "Szymon Guz" <alpha@skynet.org.pl_WITHOUT> wrote in message news:djp1tm$186k$1@node3.news.atman.pl... > Hi, > 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 ? > > regards > Szymon Guz There are ways of doing both. If you're programming in Ada you rarely (if ever) need to use them. The only cases I have used them is in interfacing with other languages. Your question is indicative of a C way of thinking. Tell us a little more about what you're trying to do, and perhaps we can suggest an approach using an Ada way of thinking. Steve (The Duck) ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: pointer questions 2005-10-26 23:01 pointer questions Szymon Guz ` (3 preceding siblings ...) 2005-10-27 2:30 ` Steve @ 2005-10-27 5:56 ` Jeffrey R. Carter 2005-10-27 10:19 ` Szymon Guz 2005-10-27 14:11 ` Robert A Duff 2005-10-27 17:19 ` Martin Krischik 5 siblings, 2 replies; 34+ messages in thread From: Jeffrey R. Carter @ 2005-10-27 5:56 UTC (permalink / raw) 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. The long answer is that you'll never need these to use Ada. In fact, you'll rarely need pointers at all. If you think you do, especially for beginning Ada, then you're probably misunderstanding something. 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. -- Jeff Carter "From this day on, the official language of San Marcos will be Swedish." Bananas 28 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: pointer questions 2005-10-27 5:56 ` Jeffrey R. Carter @ 2005-10-27 10:19 ` Szymon Guz 2005-10-27 14:14 ` Robert A Duff 2005-10-27 14:11 ` Robert A Duff 1 sibling, 1 reply; 34+ messages in thread From: Szymon Guz @ 2005-10-27 10:19 UTC (permalink / raw) Jeffrey R. Carter napisał(a): > 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. > > The long answer is that you'll never need these to use Ada. In fact, > you'll rarely need pointers at all. If you think you do, especially for > beginning Ada, then you're probably misunderstanding something. > > 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, that's how I thought but I wanted to ask. The problem that I want to solve is how to create a property in type like that ones in Delphi|Builder, so I have defined the property name, value, read and write functions. I thought that it could be done by defining a generic structure like this: Name Value Get_Function Set_Function when Value is a pointer to value, Get and Set are pointers to function for setting and getting the value. That's why I thought about universal variable pointer. ......................... Well, now I sought that it ca easily be done without any pointer, sorry regards szymon guz ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: pointer questions 2005-10-27 10:19 ` Szymon Guz @ 2005-10-27 14:14 ` Robert A Duff 2005-11-07 4:21 ` Dave Thompson 0 siblings, 1 reply; 34+ messages in thread From: Robert A Duff @ 2005-10-27 14:14 UTC (permalink / raw) Szymon Guz <alpha@skynet.org.pl_WITHOUT> writes: > Well, that's how I thought but I wanted to ask. The problem that I want > to solve is how to create a property in type like that ones in > Delphi|Builder, so I have defined the property name, value, read and > write functions. I thought that it could be done by defining a generic > structure like this: > > Name > Value > Get_Function > Set_Function > > when Value is a pointer to value, Get and Set are pointers to function > for setting and getting the value. That's why I thought about universal > variable pointer. I'm not sure I fully understand what you're trying to do, but I suspect you can do it with a hierarchy of tagged types. You will have an access-to-class-wide type, which is sort of like "void *", but it's safe. Alternatively, a generic package might do what you want. You would have one instance for each type of Value you want to store. This method might be safer, but less flexible. - Bob ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: pointer questions 2005-10-27 14:14 ` Robert A Duff @ 2005-11-07 4:21 ` Dave Thompson 0 siblings, 0 replies; 34+ messages in thread From: Dave Thompson @ 2005-11-07 4:21 UTC (permalink / raw) On 27 Oct 2005 10:14:40 -0400, Robert A Duff <bobduff@shell01.TheWorld.com> wrote: > Szymon Guz <alpha@skynet.org.pl_WITHOUT> writes: > > > Well, that's how I thought but I wanted to ask. The problem that I want > > to solve is how to create a property in type like that ones in > > Delphi|Builder, so I have defined the property name, value, read and > > write functions. I thought that it could be done by defining a generic > > structure like this: <snip> > > I'm not sure I fully understand what you're trying to do, but I suspect > you can do it with a hierarchy of tagged types. You will have an > access-to-class-wide type, which is sort of like "void *", but it's > safe. > Actually Ada access to classwide is much more like C++ pointer to baseclass, or possibly reference to baseclass, which are similarly typesafe (at least in themselves; of course in C++ you are more likely to have passed them through other unsafe constructs elsewhere). > Alternatively, a generic package might do what you want. > You would have one instance for each type of Value you > want to store. This method might be safer, but less flexible. > That said, in this case I think generic probably is better. - David.Thompson1 at worldnet.att.net ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: pointer questions 2005-10-27 5:56 ` Jeffrey R. Carter 2005-10-27 10:19 ` Szymon Guz @ 2005-10-27 14:11 ` Robert A Duff 2005-10-27 15:13 ` Marc A. Criley ` (3 more replies) 1 sibling, 4 replies; 34+ messages in thread From: Robert A Duff @ 2005-10-27 14:11 UTC (permalink / raw) "Jeffrey R. Carter" <spam@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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: pointer questions 2005-10-27 14:11 ` Robert A Duff @ 2005-10-27 15:13 ` Marc A. Criley 2005-10-27 18:53 ` Jeffrey R. Carter 2005-10-27 17:29 ` Martin Dowie ` (2 subsequent siblings) 3 siblings, 1 reply; 34+ messages in thread From: Marc A. Criley @ 2005-10-27 15:13 UTC (permalink / raw) Robert A Duff wrote: > "Jeffrey R. Carter" <spam@spam.com> writes: > >>...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 agree. The Ada projects I've worked on, from flight simulators, to command and control systems, to data analysis tools, to software development tools, have all made use of pointers, some more than others. There's so much dynamic activity going on, often with no way to know in advance just what to expect in terms of configuration, ordering, etc. In some thread that once touched on this subject, I vaguely recall someone saying one shouldn't use pointers, instead an appropriate container should be used. Okay, so the pointers are being wrapped in a container. That's not what I'd call "not needing pointers", they're just not out in plain sight. -- Marc A. Criley -- McKae Technologies -- www.mckae.com -- DTraq - XPath In Ada - XML EZ Out ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: pointer questions 2005-10-27 15:13 ` Marc A. Criley @ 2005-10-27 18:53 ` Jeffrey R. Carter 0 siblings, 0 replies; 34+ messages in thread From: Jeffrey R. Carter @ 2005-10-27 18:53 UTC (permalink / raw) Marc A. Criley wrote: > I agree. The Ada projects I've worked on, from flight simulators, to command > and control systems, to data analysis tools, to software development tools, > have all made use of pointers, some more than others. There's so much > dynamic activity going on, often with no way to know in advance just what to > expect in terms of configuration, ordering, etc. For $2500/day or part thereof, with a minimum charge of 5 days, I'm sure I could tell you how to eliminate many of those pointers :) > In some thread that once touched on this subject, I vaguely recall someone > saying one shouldn't use pointers, instead an appropriate container should be > used. Okay, so the pointers are being wrapped in a container. That's not > what I'd call "not needing pointers", they're just not out in plain sight. Perhaps it would be more accurate to say that one will rarely need to declare or manipulate pointers directly, but saying one will rarely need pointers is more succinct, and more in line with what things look like to someone who is reusing a dynamic data structure package. Of course, "rarely" is not "never". -- Jeff Carter "My mind is aglow with whirling, transient nodes of thought, careening through a cosmic vapor of invention." Blazing Saddles 85 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: pointer questions 2005-10-27 14:11 ` Robert A Duff 2005-10-27 15:13 ` Marc A. Criley @ 2005-10-27 17:29 ` Martin Dowie 2005-10-27 18:28 ` Marc A. Criley 2005-10-27 18:43 ` Jeffrey R. Carter 2005-10-28 11:53 ` David 3 siblings, 1 reply; 34+ messages in thread From: Martin Dowie @ 2005-10-27 17:29 UTC (permalink / raw) Robert A Duff wrote: > 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. 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. Cheers -- Martin ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: pointer questions 2005-10-27 17:29 ` Martin Dowie @ 2005-10-27 18:28 ` Marc A. Criley 2005-10-27 19:28 ` Martin Dowie 0 siblings, 1 reply; 34+ messages in thread From: Marc A. Criley @ 2005-10-27 18:28 UTC (permalink / raw) Martin Dowie wrote: > Robert A Duff wrote: > >> 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. > > > 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.) -- Marc A. Criley -- McKae Technologies -- www.mckae.com -- DTraq - XPath in Ada - XML EZ Out ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: pointer questions 2005-10-27 18:28 ` Marc A. Criley @ 2005-10-27 19:28 ` Martin Dowie 2005-10-28 0:12 ` Robert A Duff 2005-10-28 11:57 ` Dr. Adrian Wrigley 0 siblings, 2 replies; 34+ messages in thread From: Martin Dowie @ 2005-10-27 19:28 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: pointer questions 2005-10-27 19:28 ` Martin Dowie @ 2005-10-28 0:12 ` Robert A Duff 2005-10-28 11:57 ` Dr. Adrian Wrigley 1 sibling, 0 replies; 34+ messages in thread From: Robert A Duff @ 2005-10-28 0:12 UTC (permalink / raw) Martin Dowie <martin.dowie@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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: pointer questions 2005-10-27 19:28 ` Martin Dowie 2005-10-28 0:12 ` Robert A Duff @ 2005-10-28 11:57 ` Dr. Adrian Wrigley 2005-10-28 21:26 ` Jeffrey R. Carter 1 sibling, 1 reply; 34+ messages in thread From: Dr. Adrian Wrigley @ 2005-10-28 11:57 UTC (permalink / raw) On Thu, 27 Oct 2005 19:28:36 +0000, Martin Dowie wrote: > More error related than predictability I hope! Or is there some > dangerous non-determinism associated with access types I haven't come > across yet?! :-) I did meet a case of non-determinism exposed through access types... My stock trading software originally used very large arrays of pricing data (around 1GB of data). This worked fine for many months. One day, I decided to add a level of redirection, using a large array of access values. After that, the program would fail mysteriously every few months. But why? It slowly became apparent that the memory was getting single-bit errors. I remember from the early days of DRAM that alpha particles in packaging could cause soft errors, and researched the current reliability of DRAM. It seems that packaging radiation is now negligable, but cosmic ray strikes are still an issue (depending on altitude). Calculating the rate of soft errors expected, I found that with a gigabyte of non-ECC memory, soft errors might occur about every week. I immediately switched to ECC and the problem vanished. Anyone with a well specced PC should be aware that memory bits will be flipping spontaneously every few days, unless ECC is used. This means that large linked data structures are highly susceptible to failure. Of course non-linked data also gets errors, but these will often disappear, and are slightly less sensitive. It becomes a question of how errors show up. With copious use of access types, failures are often catastophic. Without, they tend to be more insideous. Make your choice! Or get ECC! -- Adrian Quote: "IBM has performed the most comprehensive characterization of soft error rates in DRAM subsystems, collecting data on roughly 800 memory devices over a 10-year period. These studies were performed at various altitudes, including below sea level in underground caves, since the cosmic ray flux increases with altitude. Using this data, a senior engineer for IBM Microelectronics predicted that 256 Mbytes of memory would average one soft error per month due to cosmic rays (EE Times, 6/22/98)." ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: pointer questions 2005-10-28 11:57 ` Dr. Adrian Wrigley @ 2005-10-28 21:26 ` Jeffrey R. Carter 2005-10-30 22:26 ` Robert A Duff 0 siblings, 1 reply; 34+ messages in thread From: Jeffrey R. Carter @ 2005-10-28 21:26 UTC (permalink / raw) Dr. Adrian Wrigley wrote: > My stock trading software originally used very large arrays > of pricing data (around 1GB of data). This worked fine for many > months. One day, I decided to add a level of redirection, using > a large array of access values. After that, the program would > fail mysteriously every few months. But why? So your stack was ECC memory, but your heap was not? -- Jeff Carter "Blessed are they who convert their neighbors' oxen, for they shall inhibit their girth." Monty Python's Life of Brian 83 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: pointer questions 2005-10-28 21:26 ` Jeffrey R. Carter @ 2005-10-30 22:26 ` Robert A Duff 2005-10-31 6:21 ` Jeffrey R. Carter 0 siblings, 1 reply; 34+ messages in thread From: Robert A Duff @ 2005-10-30 22:26 UTC (permalink / raw) "Jeffrey R. Carter" <spam@spam.com> writes: > Dr. Adrian Wrigley wrote: > > > My stock trading software originally used very large arrays > > of pricing data (around 1GB of data). This worked fine for many > > months. One day, I decided to add a level of redirection, using > > a large array of access values. After that, the program would > > fail mysteriously every few months. But why? > > So your stack was ECC memory, but your heap was not? That's hard to believe. Dr. Wrigley said the hardware failures turned from "insideous" to "catastophic" when he changed some sort of Things to pointers-to-Things. I take that to mean, he got wrong answers before, and crashes after. Is that right, Dr. Wrigley? Either way, the lesson should be "use reliable hardware"! - Bob ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: pointer questions 2005-10-30 22:26 ` Robert A Duff @ 2005-10-31 6:21 ` Jeffrey R. Carter 2005-11-02 0:52 ` Dr. Adrian Wrigley 0 siblings, 1 reply; 34+ messages in thread From: Jeffrey R. Carter @ 2005-10-31 6:21 UTC (permalink / raw) Robert A Duff wrote: > That's hard to believe. Dr. Wrigley said the hardware failures turned > from "insideous" to "catastophic" when he changed some sort of Things to > pointers-to-Things. I take that to mean, he got wrong answers before, > and crashes after. Is that right, Dr. Wrigley? Thinking about it a little more, I get the idea that before he had 1 pointer to a 1 GB data structure on the heap. Then he changed to a large number of pointers to smaller data structures on the heap, equivalent to the previous 1 GB structure. With more pointers, there's a greater chance that one of the pointers might have a bit flip, resulting in the occasional crash (1 crash every few months, IIRC). Of course, this is sheer speculation. -- Jeff Carter "There's no messiah here. There's a mess all right, but no messiah." Monty Python's Life of Brian 84 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: pointer questions 2005-10-31 6:21 ` Jeffrey R. Carter @ 2005-11-02 0:52 ` Dr. Adrian Wrigley 2005-11-02 3:46 ` Jeffrey R. Carter ` (3 more replies) 0 siblings, 4 replies; 34+ messages in thread From: Dr. Adrian Wrigley @ 2005-11-02 0:52 UTC (permalink / raw) On Mon, 31 Oct 2005 06:21:37 +0000, Jeffrey R. Carter wrote: > Robert A Duff wrote: > >> That's hard to believe. Dr. Wrigley said the hardware failures turned >> from "insideous" to "catastophic" when he changed some sort of Things to >> pointers-to-Things. I take that to mean, he got wrong answers before, >> and crashes after. Is that right, Dr. Wrigley? I Thinks so, but the error rate was very low, so it is hard to tell. > Thinking about it a little more, I get the idea that before he had 1 pointer to > a 1 GB data structure on the heap. Then he changed to a large number of pointers > to smaller data structures on the heap, equivalent to the previous 1 GB structure. This is exactly the situation. The "Things" were about 36 bytes each and I changed to having around 20 million pointers to things. Single bit errors in pointers had a much more significant effect than single bit errors in "Things" (which tended to be ignored for various reasons). > With more pointers, there's a greater chance that one of the pointers might have > a bit flip, resulting in the occasional crash (1 crash every few months, IIRC). Yes. > Of course, this is sheer speculation. well speculated! (was it so unclear?) Another "feature" I observed was that files could stay cached by the OS for months, and accumulate the occasional single-bit error. But when you evict the cached pages and read the data again, the errors disappear. Plenty of scope for very rare Heisenbugs. The warning I give is that these error rates are "normal" for modern SDRAM, but aren't usually noticed because they usually only show up if you have several GB of memory and care about every bit 24/7. Operating a financial business, I care about this! -- Adrian ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: pointer questions 2005-11-02 0:52 ` Dr. Adrian Wrigley @ 2005-11-02 3:46 ` Jeffrey R. Carter 2005-11-02 11:16 ` Dr. Adrian Wrigley 2005-11-02 13:39 ` Robert A Duff ` (2 subsequent siblings) 3 siblings, 1 reply; 34+ messages in thread From: Jeffrey R. Carter @ 2005-11-02 3:46 UTC (permalink / raw) Dr. Adrian Wrigley wrote: > This is exactly the situation. The "Things" were about 36 bytes each > and I changed to having around 20 million pointers to things. > Single bit errors in pointers had a much more significant effect > than single bit errors in "Things" (which tended to be ignored > for various reasons). Right. I don't think I'd ever want to consider a continually running program with 20 million pointers. What did that buy you over the single-pointer version? > well speculated! (was it so unclear?) Thanks. I wasn't clear what was causing the crashes at 1st. With a little more thought, it seemed likely it was dereferencing a pointer with a flipped bit. > Another "feature" I observed was that files could stay cached by the OS > for months, and accumulate the occasional single-bit error. But when you > evict the cached pages and read the data again, the errors disappear. > Plenty of scope for very rare Heisenbugs. Interesting. It's not something you normally have to think about; most programs don't run for that long. I remember a noticeable # of bit errors during a solar maximum about 1980, but don't recall it repeating in 1991 or 2002. -- Jeff Carter "In the frozen land of Nador they were forced to eat Robin's minstrels, and there was much rejoicing." Monty Python & the Holy Grail 70 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: pointer questions 2005-11-02 3:46 ` Jeffrey R. Carter @ 2005-11-02 11:16 ` Dr. Adrian Wrigley 0 siblings, 0 replies; 34+ messages in thread From: Dr. Adrian Wrigley @ 2005-11-02 11:16 UTC (permalink / raw) On Wed, 02 Nov 2005 03:46:41 +0000, Jeffrey R. Carter wrote: > Dr. Adrian Wrigley wrote: > >> This is exactly the situation. The "Things" were about 36 bytes each >> and I changed to having around 20 million pointers to things. >> Single bit errors in pointers had a much more significant effect >> than single bit errors in "Things" (which tended to be ignored >> for various reasons). > > Right. I don't think I'd ever want to consider a continually running program > with 20 million pointers. What did that buy you over the single-pointer version? It was a simple 2-D array of stock data (time/date, ticker). But some tickers had large gaps (no data for long periods). I had been hitting various memory limits. Adding a level of indirection allowed only the valid data to consume memory, keeping the program within those limits. It's still a rather simple architecture, compared to a more traditional SQL database system for this application. But it is *very* fast and (now) very robust. -- Adrian ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: pointer questions 2005-11-02 0:52 ` Dr. Adrian Wrigley 2005-11-02 3:46 ` Jeffrey R. Carter @ 2005-11-02 13:39 ` Robert A Duff 2005-11-02 15:34 ` Bob Spooner 2005-11-02 18:59 ` Björn Persson 3 siblings, 0 replies; 34+ messages in thread From: Robert A Duff @ 2005-11-02 13:39 UTC (permalink / raw) "Dr. Adrian Wrigley" <amtw@linuxchip.demon.co.uk.uk.uk> writes: > On Mon, 31 Oct 2005 06:21:37 +0000, Jeffrey R. Carter wrote: > > > Robert A Duff wrote: > > > >> That's hard to believe. Dr. Wrigley said the hardware failures turned > >> from "insideous" to "catastophic" when he changed some sort of Things to > >> pointers-to-Things. I take that to mean, he got wrong answers before, > >> and crashes after. Is that right, Dr. Wrigley? > > I Thinks so, but the error rate was very low, so it is hard to tell. Interesting. Some years ago I used a computer that developed a hardware problem. It would randomly flip the fifth bit of some bytes, once in a while. It took a long time to even notice the problem, because that changes letters to/from upper/lower case, in ASCII. So we would look at a text file, and fix some "typos" -- change "hEllo" to "hello". Until it started happening more and more. - Bob ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: pointer questions 2005-11-02 0:52 ` Dr. Adrian Wrigley 2005-11-02 3:46 ` Jeffrey R. Carter 2005-11-02 13:39 ` Robert A Duff @ 2005-11-02 15:34 ` Bob Spooner 2005-11-02 18:59 ` Björn Persson 3 siblings, 0 replies; 34+ messages in thread From: Bob Spooner @ 2005-11-02 15:34 UTC (permalink / raw) "Dr. Adrian Wrigley" <amtw@linuxchip.demon.co.uk.uk.uk> wrote in message news:pan.2005.11.02.00.51.10.448346@linuxchip.demon.co.uk.uk.uk... > On Mon, 31 Oct 2005 06:21:37 +0000, Jeffrey R. Carter wrote: > > > Robert A Duff wrote: > > > >> That's hard to believe. Dr. Wrigley said the hardware failures turned > >> from "insideous" to "catastophic" when he changed some sort of Things to > >> pointers-to-Things. I take that to mean, he got wrong answers before, > >> and crashes after. Is that right, Dr. Wrigley? > > I Thinks so, but the error rate was very low, so it is hard to tell. > Wow! That would mean that if you want your software to be reliable, you should use as many pointers as you can so that you notice the errors - then you can fix them! :) Bob ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: pointer questions 2005-11-02 0:52 ` Dr. Adrian Wrigley ` (2 preceding siblings ...) 2005-11-02 15:34 ` Bob Spooner @ 2005-11-02 18:59 ` Björn Persson 3 siblings, 0 replies; 34+ messages in thread From: Björn Persson @ 2005-11-02 18:59 UTC (permalink / raw) Dr. Adrian Wrigley wrote: > (was it so unclear?) I didn't find it unclear. -- Bj�rn Persson PGP key A88682FD omb jor ers @sv ge. r o.b n.p son eri nu ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: pointer questions 2005-10-27 14:11 ` Robert A Duff 2005-10-27 15:13 ` Marc A. Criley 2005-10-27 17:29 ` Martin Dowie @ 2005-10-27 18:43 ` Jeffrey R. Carter 2005-10-28 0:42 ` Robert A Duff 2005-10-28 11:53 ` David 3 siblings, 1 reply; 34+ messages in thread From: Jeffrey R. Carter @ 2005-10-27 18:43 UTC (permalink / raw) 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. 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. 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. 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 :) > 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. 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. -- Jeff Carter "My mind is aglow with whirling, transient nodes of thought, careening through a cosmic vapor of invention." Blazing Saddles 85 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: pointer questions 2005-10-27 18:43 ` Jeffrey R. Carter @ 2005-10-28 0:42 ` Robert A Duff 2005-10-28 5:58 ` Martin Dowie 2005-10-28 21:24 ` Jeffrey R. Carter 0 siblings, 2 replies; 34+ messages in thread From: Robert A Duff @ 2005-10-28 0:42 UTC (permalink / raw) "Jeffrey R. Carter" <spam@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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: pointer questions 2005-10-28 0:42 ` Robert A Duff @ 2005-10-28 5:58 ` Martin Dowie 2005-10-28 21:24 ` Jeffrey R. Carter 1 sibling, 0 replies; 34+ messages in thread From: Martin Dowie @ 2005-10-28 5:58 UTC (permalink / raw) Robert A Duff wrote: > I don't even know what to call it. Not "Duff", for sure. ;-) C$ ??? :-) ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: pointer questions 2005-10-28 0:42 ` Robert A Duff 2005-10-28 5:58 ` Martin Dowie @ 2005-10-28 21:24 ` Jeffrey R. Carter 1 sibling, 0 replies; 34+ messages in thread From: Jeffrey R. Carter @ 2005-10-28 21:24 UTC (permalink / raw) Robert A Duff wrote: > 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. Sounds as if compilers need access types much more than many other kinds of programs. > 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. Sounds like a fun hobby. I've thought about trying to design a language (which I would call NINA: NINA Is Not Ada), but every time someone posts a "why not add this feature" question and I think about what it would entail, LLs like you come up with several factors I hadn't thought of. So it seems I shouldn't be in the language design business anytime soon. > I don't even know what to call it. Not "Duff", for sure. ;-) OK. I'll look forward to hearing more about Not "Duff" :) > Just saying "You hardly ever need pointers in Ada" is misleading, > IMHO. Perhaps. To a certain extent, I intend it to provoke, so the person thinks about the possibility that Ada is significantly different from C, and he's not going to learn Ada by trying to do things the same way as in C. -- Jeff Carter "Blessed are they who convert their neighbors' oxen, for they shall inhibit their girth." Monty Python's Life of Brian 83 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: pointer questions 2005-10-27 14:11 ` Robert A Duff ` (2 preceding siblings ...) 2005-10-27 18:43 ` Jeffrey R. Carter @ 2005-10-28 11:53 ` David 2005-10-29 12:25 ` Simon Wright 3 siblings, 1 reply; 34+ messages in thread From: David @ 2005-10-28 11:53 UTC (permalink / raw) Robert A Duff wrote: > "Jeffrey R. Carter" <spam@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 ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: pointer questions 2005-10-28 11:53 ` David @ 2005-10-29 12:25 ` Simon Wright 0 siblings, 0 replies; 34+ messages in thread From: Simon Wright @ 2005-10-29 12:25 UTC (permalink / raw) David <kdgreen@fastmail.fm.au> writes: > 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. Do the rules allow unchecked conversion? Using "for x'address use" to "declare one variable on top of another" is a way of trying to pretend to the auditor that you aren't doing unchecked conversion ... much safer to do UC, at least the compiler has a chance to tell you that (for instance) the things concerned aren't the same size! ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: pointer questions 2005-10-26 23:01 pointer questions Szymon Guz ` (4 preceding siblings ...) 2005-10-27 5:56 ` Jeffrey R. Carter @ 2005-10-27 17:19 ` Martin Krischik 2005-11-07 4:21 ` Dave Thompson 5 siblings, 1 reply; 34+ messages in thread From: Martin Krischik @ 2005-10-27 17:19 UTC (permalink / raw) Am 27.10.2005, 02:01 Uhr, schrieb Szymon Guz <alpha@skynet.org.pl_WITHOUT>: > Hi, > 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 ? Read: http://en.wikibooks.org/wiki/Ada_Programming/Types/access#Where_is_void.2A.3F And all the text above that sub-chapter. > 2. Is there a universal (like above) pointer for procedure|function that > can point to any kind of procedure|funcion ? How is that supposed to work? Any function - how then are you going to pass any parameters? You don't even have that in C. Martin ^ permalink raw reply [flat|nested] 34+ messages in thread
* Re: pointer questions 2005-10-27 17:19 ` Martin Krischik @ 2005-11-07 4:21 ` Dave Thompson 0 siblings, 0 replies; 34+ messages in thread From: Dave Thompson @ 2005-11-07 4:21 UTC (permalink / raw) On Thu, 27 Oct 2005 20:19:51 +0300, "Martin Krischik" <krischik@users.sourceforge.net> wrote: > Am 27.10.2005, 02:01 Uhr, schrieb Szymon Guz <alpha@skynet.org.pl_WITHOUT>: <snip> > > 2. Is there a universal (like above) pointer for procedure|function that > > can point to any kind of procedure|funcion ? > > How is that supposed to work? Any function - how then are you going to > pass any parameters? You don't even have that in C. > Yes and no. In C (and C++) you can convert a pointer to any function type (= subprogram signature) to any other -- as long as you don't use the result to make a call. In C++ you must convert back to the correct signature (prototype) to make the call. In C only you can also use the original, pre-ANSI-89 aka K&R1, syntax to specify pointer to function of _unspecified_ argument types but a specified return type (including, now, void = procedure). This has the 'advantage'(?) that you can convert any pointer-to-function type to it and vice versa _implicitly_ (without a cast). If you call through such a pointer the arguments are passed using (only) the fixed K&R1 rules, now called the 'default argument promotions', and you the programmer are responsible for making sure they agree. (Which you can't if the called function wants formals of types 'widened' by the default promotions, namely integers below int or s-p float. Though if you define = implement the function also using K&R1 syntax, declaring a formal parameter of such a narrow type actually uses the widened one, compatible with the calls.) This allows you to create a data structure, such as a table, which has pointers to functions of different signatures, along with some data which allows you to determine (select) the correct signature for each in progam logic, but not automatically checked by the compiler. - David.Thompson1 at worldnet.att.net ^ permalink raw reply [flat|nested] 34+ messages in thread
end of thread, other threads:[~2005-11-07 4:21 UTC | newest] Thread overview: 34+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2005-10-26 23:01 pointer questions Szymon Guz 2005-10-26 23:51 ` Gene 2005-10-26 23:58 ` tmoran 2005-10-27 1:12 ` Stephen Leake 2005-10-27 2:30 ` Steve 2005-10-27 5:56 ` Jeffrey R. Carter 2005-10-27 10:19 ` Szymon Guz 2005-10-27 14:14 ` Robert A Duff 2005-11-07 4:21 ` Dave Thompson 2005-10-27 14:11 ` Robert A Duff 2005-10-27 15:13 ` Marc A. Criley 2005-10-27 18:53 ` Jeffrey R. Carter 2005-10-27 17:29 ` Martin Dowie 2005-10-27 18:28 ` Marc A. Criley 2005-10-27 19:28 ` Martin Dowie 2005-10-28 0:12 ` Robert A Duff 2005-10-28 11:57 ` Dr. Adrian Wrigley 2005-10-28 21:26 ` Jeffrey R. Carter 2005-10-30 22:26 ` Robert A Duff 2005-10-31 6:21 ` Jeffrey R. Carter 2005-11-02 0:52 ` Dr. Adrian Wrigley 2005-11-02 3:46 ` Jeffrey R. Carter 2005-11-02 11:16 ` Dr. Adrian Wrigley 2005-11-02 13:39 ` Robert A Duff 2005-11-02 15:34 ` Bob Spooner 2005-11-02 18:59 ` Björn Persson 2005-10-27 18:43 ` Jeffrey R. Carter 2005-10-28 0:42 ` Robert A Duff 2005-10-28 5:58 ` Martin Dowie 2005-10-28 21:24 ` Jeffrey R. Carter 2005-10-28 11:53 ` David 2005-10-29 12:25 ` Simon Wright 2005-10-27 17:19 ` Martin Krischik 2005-11-07 4:21 ` Dave Thompson
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox