Pascal, Pointers - what am I missing?

Robert AH Prin
#1 / 25

Pointers - what am I missing?

type
otherptr = ^whatever;
ptr = ^list;
list = record
nxt: ptr;
data: integer;
end;
var
mylist: ptr;
temp : otherptr;

1) temp:= otherptr(mylist^.nxt);
2) ptr(temp):= mylist^.nxt;

Are 1) and 2) the same?

Robert
--
Robert AH Prins

Sent via Deja.com http://www.*-*-*.com/
Before you buy.

Wed, 18 Jun 1902 08:00:00 GMT

Bob Scho
#2 / 25

Pointers - what am I missing?

From the standpoint of Standard Pascal, "something is wrong here" (I
realize that you are probably using a Borland extension, which I do not
understand). Generally,
pointers "point to" things, which must themselves be defined. So the
definition of "otherptr" is no good, since "whatever" is not defined.
Similarly, ptr(temp) is not a recognized Standard Pascal syntax.

If what you are trying to do is establish a pointer to an "internal"
member of a linked list, you can do that directly.

VAR
internalptr : ptr;

internalptr := mylist^.nxt;

Bob Schor
(Standard) Pascal Enthusiast

Quote:

> type
> otherptr = ^whatever;
> ptr = ^list;
> list = record
> nxt: ptr;
> data: integer;
> end;
> var
> mylist: ptr;
> temp : otherptr;

> 1) temp:= otherptr(mylist^.nxt);
> 2) ptr(temp):= mylist^.nxt;

> Are 1) and 2) the same?

> Robert
> --
> Robert AH Prins

> Sent via Deja.com http://www.deja.com/
> Before you buy.

Wed, 18 Jun 1902 08:00:00 GMT

rdts
#3 / 25

Pointers - what am I missing?

Quote:

>type
> otherptr = ^whatever;
> ptr = ^list;
> list = record
> nxt: ptr;
> data: integer;
> end;
>var
> mylist: ptr;
> temp : otherptr;

>1) temp:= otherptr(mylist^.nxt);
>2) ptr(temp):= mylist^.nxt;

>Are 1) and 2) the same?

Yes. They are the same.

Note: this is not always true for other dialects of Pascal.
Some dialects do not allow left-hand typecasts.

For some other Pascals, like Turbo Pascal 7.0,
left-hand typecast works on pointers (typed and untyped) only.

Another note:
Please do not re-define 'Ptr'
Ptr is an identifier in some Pascals. It is a function that
converts address to a pointer, eg:
ptr($40,$6c) refers to a pointer pointing to
memory location [64:108]
In other Pascals, it is a Reserved Word!

A third note:
If you really want to put this code into use,
be sure to check the type of pointer yourself!
It is better if the 'whatever' can be replaced
with the same type as nxt (ie. ^list)

Wed, 18 Jun 1902 08:00:00 GMT

Raimo Suoni
#4 / 25

Pointers - what am I missing?

Quote:

>A third note:
>If you really want to put this code into use,
>be sure to check the type of pointer yourself!
>It is better if the 'whatever' can be replaced
>with the same type as nxt (ie. ^list)

And if one wants to use a pointer that doesn't point to anything
specific (whatever) there is a predefined type "pointer" in Borland
Pascal. So one might write:

otherptr = pointer;

--
Raimo Suonio, Helsinki, Finland
Oikeinkirjoitusohjeita news- ja web-kirjoittajille:
http://www.dlc.fi/%7Eexp-1/oikeinkirjoitus.html
http://www.dlc.fi/%7Eexp-1/suonio/

Wed, 18 Jun 1902 08:00:00 GMT

Sebastian Koppeh
#5 / 25

Pointers - what am I missing?

Hi,

Quote:

> Generally,
> pointers "point to" things, which must themselves be defined. So the
> definition of "otherptr" is no good, since "whatever" is not defined.

I believe that "whatever" was meant to be a metasyntactic variable.
If you replace it by "integer", the code works.

Quote:

> Similarly, ptr(temp) is not a recognized Standard Pascal syntax.

It is quite a normal typecast, and yes, Borland dialect allows for
assignments to cast variables. The cast is fairly safe, since both
variables are pointers, and thus have the same size and semantics.

I think that Standard Pascal has the generic type Pointer, and the
following would be valid Standard Pascal (but I'm not sure):

(declarations as in the example)
var p : Pointer;
:
begin
p := mylist^.nxt;
temp := p;
end.

Hoowever, all this is trying to circumvent Pascal's strong typing, and
one should at least be careful when doing that.

- Sebastian

--
Add "NOSPAM" to my email to send me junk!

Wed, 18 Jun 1902 08:00:00 GMT

The Scarlet Manu
#6 / 25

Pointers - what am I missing?

Quote:

> I think that Standard Pascal has the generic type Pointer, and the
> following would be valid Standard Pascal (but I'm not sure):
> (declarations as in the example)
> var p : Pointer;
> :
> begin
> p := mylist^.nxt;
> temp := p;
> end.

That is correct. Pointer is compatible with any pointer type.

--
______________________________________________________________________
The Scarlet Manuka, | Nitpickers' Party motto:
Pratchett Quoter At Large, | "He who guards his lips guards his
First Prophet of Bonni, is: | soul, but he who speaks rashly will

______________________________|_______________________________________

Wed, 18 Jun 1902 08:00:00 GMT

Robert AH Prin
#7 / 25

Pointers - what am I missing?

Quote:

> type
> otherptr = ^whatever;
> ptr = ^list;
> list = record
> nxt: ptr;
> data: integer;
> end;
> var
> mylist: ptr;
> temp : otherptr;

> 1) temp:= otherptr(mylist^.nxt);
> 2) ptr(temp):= mylist^.nxt;

> Are 1) and 2) the same?

As everyone helpfully told me, 1) & 2) are the same.

Obviously, this is the correct answer, but sadly, I've found an
occurance in TP6 where 1) <> 2)...

As for the other remarks, I know that type-casting isn't exactly overly
clean, but if you're, like me, using a number of linked lists, all with
the "next" pointer as the first element in the record and with "next"
followed by a bit of same-format data, type-casting allows you to
eliminate a hell of a lot of "if" statements.

Robert
--
Robert AH Prins

Sent via Deja.com http://www.deja.com/
Before you buy.

Wed, 18 Jun 1902 08:00:00 GMT

Frank Peel
#8 / 25

Pointers - what am I missing?

Quote:

> > type
> > otherptr = ^whatever;
> > ptr = ^list;
> > list = record
> > nxt: ptr;
> > data: integer;
> > end;
> > var
> > mylist: ptr;
> > temp : otherptr;

> > 1) temp:= otherptr(mylist^.nxt);
> > 2) ptr(temp):= mylist^.nxt;

> > Are 1) and 2) the same?

> As everyone helpfully told me, 1) & 2) are the same.

> Obviously, this is the correct answer, but sadly, I've found an
> occurance in TP6 where 1) <> 2)...

Could you give a demo please? Just to show what to avoid doing.

FP

Wed, 18 Jun 1902 08:00:00 GMT

Osmo Ronkan
#9 / 25

Pointers - what am I missing?

Quote:

>> I think that Standard Pascal has the generic type Pointer, and the
>> following would be valid Standard Pascal (but I'm not sure):

>> (declarations as in the example)
>> var p : Pointer;
>> :
>> begin
>> p := mylist^.nxt;
>> temp := p;
>> end.

>That is correct. Pointer is compatible with any pointer type.

However it is not Standard Pascal (which to me means the original
standard)

Osmo

Wed, 18 Jun 1902 08:00:00 GMT

Raimo Suoni
#10 / 25

Pointers - what am I missing?

Quote:

>As everyone helpfully told me, 1) & 2) are the same.

>Obviously, this is the correct answer, but sadly, I've found an
>occurance in TP6 where 1) <> 2)...

>As for the other remarks, I know that type-casting isn't exactly
overly
>clean, but if you're, like me, using a number of linked lists, all
with
>the "next" pointer as the first element in the record and with "next"
>followed by a bit of same-format data, type-casting allows you to
>eliminate a hell of a lot of "if" statements.

That is just where the objects step on the stage. Instead of a record
you define an object. And you define first an abstract object which
only contains the link structure, that is, the next fields (and
methods to use them). Then you create all kind of linked lists, which
inherit the abstract structure. That's how you don't need typecasting
and the if statements. They will all behave the same way and be
compatible whith each other.

--
Raimo Suonio, Helsinki, Finland
http://www.dlc.fi/%7Eexp-1/suonio/
Oikeinkirjoitusohjeita news- ja web-kirjoittajille:
http://www.dlc.fi/%7Eexp-1/oikeinkirjoitus.html

Wed, 18 Jun 1902 08:00:00 GMT

Frank Peel
#11 / 25

Pointers - what am I missing?

Quote:

> >As everyone helpfully told me, 1) & 2) are the same.

> >Obviously, this is the correct answer, but sadly, I've found an
> >occurance in TP6 where 1) <> 2)...

> >As for the other remarks, I know that type-casting isn't exactly
> overly
> >clean, but if you're, like me, using a number of linked lists, all
> with
> >the "next" pointer as the first element in the record and with "next"
> >followed by a bit of same-format data, type-casting allows you to
> >eliminate a hell of a lot of "if" statements.

> That is just where the objects step on the stage. Instead of a record
> you define an object. And you define first an abstract object which
> only contains the link structure, that is, the next fields (and
> methods to use them). Then you create all kind of linked lists, which
> inherit the abstract structure. That's how you don't need typecasting
> and the if statements. They will all behave the same way and be
> compatible whith each other.

That's fine for inserting in the list and removing an item, since the
relevant methods can deal with the items as the ancestral type. You don't
need casts until you need to find an object in the list and access its
fields. The Next pointer will be of the ancestral type, which only knows
about Next. To access other fields you need a cast. Or is there a neat way
around this?

FP

Wed, 18 Jun 1902 08:00:00 GMT

Raimo Suoni
#12 / 25

Pointers - what am I missing?

Quote:

>That's fine for inserting in the list and removing an item, since the
>relevant methods can deal with the items as the ancestral type. You
don't
>need casts until you need to find an object in the list and access
its
>fields. The Next pointer will be of the ancestral type, which only
knows
>about Next. To access other fields you need a cast. Or is there a
neat way
>around this?

It depends on the situation, or should I say, the preferences of the
programmer. One can write or reserve abstract methods in the abstract
object and redefine them for each different object type. That way one
can call the method for any of the object types and they will act as
programmed, each one in its own way.

This is of course rather stupid example but clarifies the idea. If
you have objects of which some contain a numerical value and some a
string value. You may have defined an abstract method "Square". The
abstract method does nothing. But for numerical objects you may
redefine it to square the numerical value. Now you can always call
the method "Square" without knowing, which type of object it really
is, that is, without typecasting or if statements.

--
Raimo Suonio, Helsinki, Finland
http://www.dlc.fi/%7Eexp-1/suonio/
Oikeinkirjoitusohjeita news- ja web-kirjoittajille:
http://www.dlc.fi/%7Eexp-1/oikeinkirjoitus.html

Wed, 18 Jun 1902 08:00:00 GMT

Robert AH Prin
#13 / 25

Pointers - what am I missing?

Quote:

> >As everyone helpfully told me, 1) & 2) are the same.

> >Obviously, this is the correct answer, but sadly, I've found an
> >occurance in TP6 where 1) <> 2)...

> >As for the other remarks, I know that type-casting isn't exactly
> >overly
> >clean, but if you're, like me, using a number of linked lists, all
> >with
> >the "next" pointer as the first element in the record and with "next"
> >followed by a bit of same-format data, type-casting allows you to
> >eliminate a hell of a lot of "if" statements.

> That is just where the objects step on the stage. Instead of a record
> you define an object. And you define first an abstract object which
> only contains the link structure, that is, the next fields (and
> methods to use them). Then you create all kind of linked lists, which
> inherit the abstract structure. That's how you don't need typecasting
> and the if statements. They will all behave the same way and be
> compatible whith each other.

Probably true, but this is a program that has its origins in TP3 and is
mostly for my personal use. Besides that, the program does most of its
work in assembler, this problem only appeared when I added some new
code and retrofitted this to the original Pascal version.

Robert
--
Robert AH Prins

Sent via Deja.com http://www.deja.com/
Before you buy.

Wed, 18 Jun 1902 08:00:00 GMT

Dr John Stockto
#14 / 25

Pointers - what am I missing?

Quote:

>type
> otherptr = ^whatever;
> ptr = ^list;
> list = record
> nxt: ptr;
> data: integer;
> end;
>var
> mylist: ptr;
> temp : otherptr;

>1) temp:= otherptr(mylist^.nxt);
>2) ptr(temp):= mylist^.nxt;

>Are 1) and 2) the same?

AIUI, in BP/TP, yes, at run time. Though at compile time the first
checks that temp is an otherptr and the second that mylist^.nxt is a
ptr; and in more complex code one of these checks may be of more value
than the other.

If you have sufficient Debug facilities, just examine the code produced.
Agreement in one case is rather convincing; disagreement in any case is
definitive!

Casting of the subject of an assignment is ill-known and occasionally
useful; for example, assuming a program needs to write/read variables in
human-readable form :

type TC = (red, blue, green)
var C : TC ; X : integer ; Z : single ;
...
Writeln(OutF, X:7, byte(C):2), Z:13:6) ;
...
Readln(InF, X, byte(C), Z) ;
^^^^^^^

It can also improve legibility; something like "byte(C) := 1 + 2" might
be preferred to "C := TC(1 + 2)" in a more complicated case.

--

<URL: http://www.merlyn.demon.co.uk/> TP/BP/Delphi/&c., FAQqy topics & links;
<URL: ftp://garbo.uwasa.fi/pc/link/tsfaqp.zip> Timo Salmi's Turbo Pascal FAQ;
<URL: http://www.merlyn.demon.co.uk/clpb-faq.txt> Pedt Scragg: c.l.p.b. mFAQ.

Wed, 18 Jun 1902 08:00:00 GMT

Jason Burgo
#15 / 25

Pointers - what am I missing?

Quote:

> > That is just where the objects step on the stage. Instead of a record
> > you define an object. And you define first an abstract object which
> > only contains the link structure, that is, the next fields (and
> > methods to use them). Then you create all kind of linked lists, which
> > inherit the abstract structure. That's how you don't need typecasting
> > and the if statements. They will all behave the same way and be
> > compatible whith each other.

> That's fine for inserting in the list and removing an item, since the
> relevant methods can deal with the items as the ancestral type. You don't
> need casts until you need to find an object in the list and access its
> fields. The Next pointer will be of the ancestral type, which only knows
> about Next. To access other fields you need a cast. Or is there a neat way
> around this?

If a descandant object introduces a field, then only that object (and that
object's own descendants) should access that field. Quite often the
ancestral object is given "abstract" virtual methods that its descendants
override to provide code that does something useful. Often this involves the
accessing of new fields that that descendant introduced. In this way an
ancestor method can call a (virtual) descendant method to get a job done
that the ancestor doesn't actually know how to do (only when to do it).

In the real world, there are occasions when the best solution involves a
descendant object "overriding" an ancestor field; using it to store a
different (often descendant (but related) type. Some type-casting is then
required in the descendants methods. It's a pity Turbo Pascal doesn't allow
you to override field types. This would be handy sometimes for pointer
fields. Having said that, TP objects are still very powerful, and anyone
who's writing TP code but never uses them is missing a very big trick.

The key to good OOP design is knowing how to design an object tree. It's not
easy because you're often trying to build-in some future proofing - as well
as designing what you want the object/object tree to do now, you're also
trying to think about what you might want it to do later. It can do your
head in!

--
Jay

Jason Burgon - Author of "Graphic Vision"
Professional Win95-style GUI for DOS/DPMI
Graphic Vision evaluation (version 2.04) available from:
http://www.jayman.demon.co.uk

Wed, 18 Jun 1902 08:00:00 GMT