Now I know why vendors of newer languages (Dephi, Java etc) are trying
to hide pointers from programmers. They are very tricky to work with -
and give errors without warning!
Especially when compiler and programmer are both trying to outsmart each other.
:D
Yes. But I never needed pointer arit
Graeme Geldenhuys :
> Now I know why vendors of newer languages (Dephi, Java etc) are trying
> to hide pointers from programmers. They are very tricky to work with -
> and give errors without warning!
Especially when compiler and programmer are both trying to outsmart each other.
:D
Vinzent.
-
Martin wrote:
> Graeme Geldenhuys wrote:
>> By the way, I am reading in the Table of Contents data for an OS/2 INF file.
>>
>>
>>
// now increment pEntry to point to next data structure
// below, .Length is in bytes
inc( pEntry, pEntry^.Length);
>>> inc(P
Graeme Geldenhuys wrote:
By the way, I am reading in the Table of Contents data for an OS/2 INF file.
// now increment pEntry to point to next data structure
// below, .Length is in bytes
inc( pEntry, pEntry^.Length);
inc(PEntry, 1)
since it increments by the size of the t
By the way, I am reading in the Table of Contents data for an OS/2 INF file.
Martin wrote:
>>
> if pentry is
> TEntry = record .. end;
> pentry = ^ TEntry
Yes, pEntry is a pointer to a structured type.
pEntry: pTTOCEntryStart;
The actual structure is as follows...
-
Graeme Geldenhuys wrote:
_pContentsData = a generic Pointer type that points to a block of data
(containing multiples of various structures). XXX bytes of
information.
pEntry = this is a pointer to a specific starting structure type and
will increment in blocks of data to point to the various st
Hi,
Sorry, I suck at this pointers think. Currently I am reading one
record in correctly and from there is all corrupted data. :-(
Seeing that the first block of data (pEntry^ below) is correct, it
seems my problem is incrementing to the next block of data. Here are
the various variables I am wor
