pointer questions

pointer questions

[Szymon Guz]

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

Re: pointer questions

[Gene]

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.

Re: pointer questions

[tmoran]

> 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."

Re: pointer questions

[Stephen Leake]

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

Re: pointer questions

[Steve]

"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) 

Re: pointer questions

[Jeffrey R. Carter]

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

Re: pointer questions

[Szymon Guz]

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

Re: pointer questions

[Robert A Duff]

"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

Re: pointer questions

[Robert A Duff]

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

Re: pointer questions

[Marc A. Criley]

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

Re: pointer questions

[Martin Krischik]

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

Re: pointer questions

[Martin Dowie]

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

Re: pointer questions

[Marc A. Criley]

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

Re: pointer questions

[Jeffrey R. Carter]

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

Re: pointer questions

[Jeffrey R. Carter]

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

Re: pointer questions

[Martin Dowie]

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

Re: pointer questions

[Robert A Duff]

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

Re: pointer questions

[Robert A Duff]

"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

Re: pointer questions

[Martin Dowie]

Robert A Duff wrote:
> I don't even know what to call it.  Not "Duff", for sure.  ;-)

C$ ??? :-)

Re: pointer questions

[David]

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

Re: pointer questions

[Dr. Adrian Wrigley]

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)."

Re: pointer questions

[Jeffrey R. Carter]

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

Re: pointer questions

[Jeffrey R. Carter]

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

Re: pointer questions

[Simon Wright]

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!

Re: pointer questions

[Robert A Duff]

"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

Re: pointer questions

[Jeffrey R. Carter]

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

Re: pointer questions

[Dr. Adrian Wrigley]

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

Re: pointer questions

[Jeffrey R. Carter]

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

Re: pointer questions

[Dr. Adrian Wrigley]

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

Re: pointer questions

[Robert A Duff]

"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

Re: pointer questions

[Bob Spooner]

"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

Re: pointer questions

[Björn Persson]

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

Re: pointer questions

[Dave Thompson]

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

Re: pointer questions

[Dave Thompson]

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