Pointers - what am I missing?
Author |
Message |
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 |
|
|
Page 1 of 2
|
[ 25 post ] |
|
Go to page:
[1]
[2] |
|