> Am 30.12.2024 um 12:00 schrieb Mattias Gaertner via fpc-pascal
> :
>
> Hi,
>
> Are anonymous (aka local) pointer types allowed in procedure arguments in any
> mode?
I am not aware of.
>
> procedure Run(p: ^word);
> begin
> end;
>
> I found that the fcl-passrc parser has a test to allow
Hi,
Are anonymous (aka local) pointer types allowed in procedure arguments
in any mode?
procedure Run(p: ^word);
begin
end;
I found that the fcl-passrc parser has a test to allow it and I'm
wondering if this is by design or a bug.
Mattias
___
fpc
> On Aug 10, 2023, at 11:37 PM, Michael Van Canneyt via fpc-pascal
> wrote:
>
> This is a very dirty trick to get the offset of a field in a record.
>
> Note that you're not dereferencing a type but a variable of type TAlignCheck
> located
> at memory address zero. The address of w (this is
On 8/11/23 01:23, Hairy Pixels via fpc-pascal wrote:
On Aug 10, 2023, at 2:18 PM, Michael Van Canneyt via
fpc-pascal wrote:
https://www.freepascal.org/docs-html/current/ref/refse15.html#x42-620003.4
This document doesn't really do a great enumerating all the operators so I'm
not sure if t
On Thu, 10 Aug 2023, Hairy Pixels via fpc-pascal wrote:
On Aug 10, 2023, at 4:23 PM, Hairy Pixels wrote:
// 4) subscript (inc and dereference in one step)
v := i[1];
#4 was not in the list for example so I wonder what others exist.
I found another one in the typinfo.pp unit. What do
> On Aug 10, 2023, at 4:23 PM, Hairy Pixels wrote:
>
> // 4) subscript (inc and dereference in one step)
> v := i[1];
>
>
> #4 was not in the list for example so I wonder what others exist.
I found another one in the typinfo.pp unit. What does,
1) taking the address of a type (@TAlignChec
> On Aug 10, 2023, at 2:18 PM, Michael Van Canneyt via fpc-pascal
> wrote:
>
> https://www.freepascal.org/docs-html/current/ref/refse15.html#x42-620003.4
This document doesn't really do a great enumerating all the operators so I'm
not sure if the list is complete. I think the list is:
var
On Thu, 10 Aug 2023, Hairy Pixels via fpc-pascal wrote:
On Aug 10, 2023, at 10:49 AM, Sven Barth via fpc-pascal
wrote:
Then you simply aren't using them often enough. E.g. the RTTI internal code is
full of them and additional typecasts would simply muddle up otherwise
relatively clear
> On Aug 10, 2023, at 10:49 AM, Sven Barth via fpc-pascal
> wrote:
>
> Then you simply aren't using them often enough. E.g. the RTTI internal code
> is full of them and additional typecasts would simply muddle up otherwise
> relatively clear code.
>
Here's a question, what is the full li
Hairy Pixels via fpc-pascal schrieb am
Do., 10. Aug. 2023, 18:30:
>
>
> > On Aug 10, 2023, at 5:43 AM, Bernd Oppolzer via fpc-pascal <
> fpc-pascal@lists.freepascal.org> wrote:
> >
> > PTRADD (p, i) - p is type ANYPTR, i is integer, result is of type ANYPTR
> > PTRDIFF (p1, p2) - two pointers, th
> On Aug 10, 2023, at 5:43 AM, Bernd Oppolzer via fpc-pascal
> wrote:
>
> PTRADD (p, i) - p is type ANYPTR, i is integer, result is of type ANYPTR
> PTRDIFF (p1, p2) - two pointers, the result is integer
> ANYPTR is a predefined type, compatible with every (typed pointer)
> ADDR (x) is a fun
> On Aug 9, 2023, at 4:37 PM, Tomas Hajny via fpc-pascal
> wrote:
>
> No, the offset is not a memory address but just a number of bytes (which is
> also the reason why you cannot add the pointers together, but you can add a
> number to a pointer. As an example, you could use this operation
FWIW, when I added similar functionality to my Stanford Pascal compiler,
I chose not to allow arithmetic
of pointers, but instead I added some functions:
PTRADD (p, i) - p is type ANYPTR, i is integer, result is of type ANYPTR
PTRDIFF (p1, p2) - two pointers, the result is integer
ANYPTR is a pr
1) what does "i := x - x;" do and what is it's purpose and why doesn't "x + x"
work the same?
Subtracting pointers may be useful if they point to consecutive memory.
The Result is the number of bytes between both addresses.
Adding pointers is useless, you would get a pointer pointing to some
On August 10, 2023 at 0:06:57 +0200, Hairy Pixels via fpc-pascal
wrote:
>> On Aug 9, 2023, at 2:54 PM, Tomas Hajny via fpc-pascal
>> wrote:
>>
>>>
>>> 1) what does "i := x - x;" do and what is it's purpose and why doesn't "x +
>>> x" work the same?
>>
>> Pointer subtraction is a reverse ope
> On Aug 9, 2023, at 2:54 PM, Tomas Hajny via fpc-pascal
> wrote:
>
>>
>> 1) what does "i := x - x;" do and what is it's purpose and why doesn't "x +
>> x" work the same?
>
> Pointer subtraction is a reverse operation to adding a number to a pointer;
> the result of the subtraction is the
On August 9, 2023 at 22:14:17 +0200, Hairy Pixels via fpc-pascal
wrote:
>Playing around I had a more questions about pointer operations I've never used
>myself.
>
>1) what does "i := x - x;" do and what is it's purpose and why doesn't "x + x"
>work the same?
Pointer subtraction is a reverse op
Playing around I had a more questions about pointer operations I've never used
myself.
1) what does "i := x - x;" do and what is it's purpose and why doesn't "x + x"
work the same?
2) I've used pointer equality of course but what does "x > p" do and what is
its purpose?
===
var
> On Aug 8, 2023, at 11:53 PM, Sven Barth via fpc-pascal
> wrote:
>
> By default @ returns a *untyped* pointer that can be assigned to any pointer
> type. Thus is compatible with Delphi and can be controlled with the
> $TypedAddress directive (there's a slight exception to this when you ass
Hairy Pixels via fpc-pascal schrieb am
Mi., 9. Aug. 2023, 04:59:
> I just noticed this by accident and I don't understand. Why does " x :=
> @r; " compile? I would expect it to fail like the next line where I cast to
> the explicit type.
>
> type
> TMyRec = record end;
> PMyRec = ^TMyRec;
> v
I just noticed this by accident and I don't understand. Why does " x := @r; "
compile? I would expect it to fail like the next line where I cast to the
explicit type.
type
TMyRec = record end;
PMyRec = ^TMyRec;
var
x: PByte;
r: TMyRec;
begin
x := @r;// works
x := PMyR
Am 24.03.2023 um 15:04 schrieb Benito van der Zander via fpc-pascal:
why is a pointer to a char not a pchar (for type helpers)?
Because that's how helpers work in Delphi as well: The address operator
has as a result an expression that allows the use of a helper for the
raw Pointer type (no ma
On Fri, 24 Mar 2023, Peter B via fpc-pascal wrote:
On 24/03/2023 14:29, Martin Frb via fpc-pascal wrote:
On 24/03/2023 15:04, Benito van der Zander via fpc-pascal wrote:
why is a pointer to a char not a pchar (for type helpers)?
My guess: For the same reason that "p2" fails in the below.
On 24/03/2023 14:29, Martin Frb via fpc-pascal wrote:
On 24/03/2023 15:04, Benito van der Zander via fpc-pascal wrote:
why is a pointer to a char not a pchar (for type helpers)?
My guess: For the same reason that "p2" fails in the below. Distinct type.
May be assignment compatible, but a type
On 24/03/2023 15:04, Benito van der Zander via fpc-pascal wrote:
why is a pointer to a char not a pchar (for type helpers)?
My guess: For the same reason that "p2" fails in the below. Distinct type.
May be assignment compatible, but a type of it's own.
Imagine you had a different helper, with
Hallo,
why is a pointer to a char not a pchar (for type helpers)?
program Project1;
{$Mode objfpc}{$H+} {$ModeSwitch typehelpers}
type TPcharHelper = type helper for pchar
function toString(length: integer): string;
end;
function TPcharHelper.toString(length: integer): string;
begin
SetStr
On 31/01/17 15:30, Ryan Joseph wrote:
Thanks for answering guys. Yes José is right, hashing the pointer wasn’t even a
good solution so I used another hash. I had the pointers stored in another data
type and I wanted to quickly test for the their entry in the table but I found
another way.
On
Thanks for answering guys. Yes José is right, hashing the pointer wasn’t even a
good solution so I used another hash. I had the pointers stored in another data
type and I wanted to quickly test for the their entry in the table but I found
another way.
> On Jan 30, 2017, at 4:28 PM, José Mejuto
El 30/01/2017 a las 3:37, Ryan Joseph escribió:
I’m trying to hash a pointer value and found some example of hash function but
not sure about translations and the process in general.
Hello,
After addressing the ^ conversion showed by other people I have a
question. Why you need to hash a po
Hi,
On Mon, 30 Jan 2017, Ryan Joseph wrote:
> I?m trying to hash a pointer value and found some example of hash
> function but not sure about translations and the process in general.
>
> 1) Should I cast ?pointer? as PtrUInt to get an integer from a pointer?
> I?m looking for the memory address I
In our previous episode, Ryan Joseph said:
>
> unsigned int hash(unsigned int x) {
> x = ((x >> 16) ^ x) * 0x45d9f3b;
> x = ((x >> 16) ^ x) * 0x45d9f3b;
> x = (x >> 16) ^ x;
> return x;
> }
>
> function Hash (x: PtrUInt): PtrUInt;
> begin
> x := (Power((x shr 16), x)) * $45d9f3b
On Sun, January 29, 2017 7:37 pm, Ryan Joseph wrote:
> I'm trying to hash a pointer value and found some example of hash
> function but not sure about translations and the process in general.
...
> x := (Power((x shr 16), x)) * $45d9f3b; x := Power((x shr 16), x);
result :=
The math unit, is som
I’m trying to hash a pointer value and found some example of hash function but
not sure about translations and the process in general.
1) Should I cast “pointer” as PtrUInt to get an integer from a pointer? I’m
looking for the memory address I guess and casting seems to return a unique
value. B
On 05 Nov 2013, at 09:07, Antonio Fortuny wrote:
> I don't know a way to make the data pointed to, as being constant.
There is indeed no way to specify that in Pascal.
Jonas
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.fre
Le 04/11/2013 14:18, Alexander a
écrit :
How can I describe a "pointer to a constant char" in FreePascal?
For example this C function:
int some_func(const char *arg, ...);
... coulb be translated to
some_proc(const arg: PChar, ...
On 11/04/2013 02:18 PM, Alexander wrote:
How can I describe a "pointer to a constant char" in FreePascal?
For example this C function:
int some_func(const char *arg, ...);
My guess in FreePascal is this(with ctypes unit):
function some_func(const arg: pcchar): cint; cdecl; external;
A const
How can I describe a "pointer to a constant char" in FreePascal?
For example this C function:
int some_func(const char *arg, ...);
My guess in FreePascal is this(with ctypes unit):
function some_func(const arg: pcchar): cint; cdecl; external;
A constant argument to a function.
I'm not sure, i
On Thu, Jan 31, 2013 at 10:25 PM, Sven Barth
wrote:
> On 31.01.2013 19:55, ik wrote:
>>
>> Hello,
>>
>> What is the safest (no memory corruption etc...) way to use format
>> string, and by using '%P' pass a class memory address ?
>>
>> Does casting to Pointer good, or is it unsafe ?
>
>
> As Forma
On 31.01.2013 19:55, ik wrote:
Hello,
What is the safest (no memory corruption etc...) way to use format
string, and by using '%P' pass a class memory address ?
Does casting to Pointer good, or is it unsafe ?
As Format does not support objects being provided to it you MUST even
cast to Point
Hello,
What is the safest (no memory corruption etc...) way to use format
string, and by using '%P' pass a class memory address ?
Does casting to Pointer good, or is it unsafe ?
Thanks,
Ido
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
ht
OK. Thanks, Jonas. I'll save a link to this message this time.
--
cobines
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
On 11 Mar 2012, at 15:46, cobines wrote:
> Is storing and using pointers to temporary strings safe?
No.
> Like in the
> following program. I think I remember reading on the mailing list that
> it is not, but I cannot find it. How can I prove one way or the other?
The only thing you can prove i
Hello.
Is storing and using pointers to temporary strings safe? Like in the
following program. I think I remember reading on the mailing list that
it is not, but I cannot find it. How can I prove one way or the other?
I could not get the program to crash, even if I used 20 variables, it
didn't sho
...
In addition, when starting to use Pascal, don't use pointers, and don't
invent linked lists, it's been done so many times.
Go look up the source code in contnrs.pp to understand lists and
containers already available in FPC.
Most programming can be done without untyped pointers.
Best regar
2010/4/27 spir ☣ :
> -1- untyped pointer allocation
> In case of an untyped pointer, I read the compiler considers the target'size
> is 1 byte. There certainly is an operation to allocate memory for the target
> according to an existing piece of data. Something like
> data := something
> ne
Hello,
Two basic questions about pointer targets (I call target what is pointed to).
-1- untyped pointer allocation
In case of an untyped pointer, I read the compiler considers the target'size is
1 byte. There certainly is an operation to allocate memory for the target
according to an existing
On 23/04/2010 14:08, spir ☣ wrote:
On Fri, 23 Apr 2010 08:17:21 -0400
Doug Chamberlin wrote:
On 4/23/2010 3:33 AM, spir ☣ wrote:
Say I want to implement a kind of linked list which node data may be anything.
Thus I cannot store data on place (in nodes), indeed; so it should be
referenced.
1° Using the root class TObject might be a good alternative?
Storing any object within the structure is easy.
Getting the object back will need a type overwrite.
2° Concerning standard structures, you might want to look at TList, TObjectList,
TInterfacedList, TComponentList, TStringList which prov
On Fri, 23 Apr 2010 08:17:21 -0400
Doug Chamberlin wrote:
> On 4/23/2010 3:33 AM, spir ☣ wrote:
> > Say I want to implement a kind of linked list which node data may be
> > anything. Thus I cannot store data on place (in nodes), indeed; so it
> > should be referenced. But pointers themselves ar
On 4/23/2010 3:33 AM, spir ☣ wrote:
Say I want to implement a kind of linked list which node data may be anything.
Thus I cannot store data on place (in nodes), indeed; so it should be
referenced. But pointers themselves are supposed to be typed. So, how can I do
that?
The key to solving
Try the following:
type list = ^node;
node = record
data : Variant;
next : list;
end;
Variant can store a lot pf data types, however please note that it's very
slow type.
You also must remember that Pascal is Strong typed, unlike C or duck type
languages.
The Pointer type st
Hello,
Say I want to implement a kind of linked list which node data may be anything.
Thus I cannot store data on place (in nodes), indeed; so it should be
referenced. But pointers themselves are supposed to be typed. So, how can I do
that?
type list = ^node;
node = record
data : ?
2010/1/19 Marco van de Voort :
>
> where cfree is the free() corresponding to the malloc with which it was
> allocated in the lib. (usually libc's)
Thanks for the repy. In the end I found the library I was using was
old. The newer library has a function that does the free'ing of that
list for me.
In our previous episode, Graeme Geldenhuys said:
>
> I'm working with a C library that returns an array of strings. So that is
> type PPChar. I C library does the array allocation, but doesn't do the
> freeing of the array.
>
> How am I supposed to free an array of PChar strings? I think I need
Hi,
I'm working with a C library that returns an array of strings. So that is
type PPChar. I C library does the array allocation, but doesn't do the
freeing of the array.
How am I supposed to free an array of PChar strings? I think I need to
improve my iteration too, because I'm moving the point
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
Le May 5, 2008 à 5:10 PM, ik a écrit :
Look at the Format function, you can tell it to display the address of
a pointer in a string.
Thanks !
--
Damien Gerard
[EMAIL PROTECTED]
"Intelligence is 10 million rules."
-- Douglas Lenat
___
fp
Look at the Format function, you can tell it to display the address of
a pointer in a string.
Ido
On Sun, May 4, 2008 at 7:21 PM, Damien Gerard <[EMAIL PROTECTED]> wrote:
>
> Hi !
>
> I would like to display in a lazarus application the address of a pointer.
> For this, I use :
>
> var s: str
Hi !
I would like to display in a lazarus application the address of a
pointer.
For this, I use :
var s: string;
p:pointer;
[...]
s := IntToStr(PtrInt(p))
However, I've got a warning (hint) from the compiler :
Conversion between ordinals and pointers is not portable
What is the way to
Hi !
I would like to display in a lazarus application the address of a
pointer.
For this, I use :
var s: string;
p:pointer;
[...]
s := IntToStr(PtrInt(p))
However, I've got a warning (hint) from the compiler :
Conversion between ordinals and pointers is not portable
What is the way to
On 11/15/05, Luis Del Aguila <[EMAIL PROTECTED]> wrote:
>
> Somebody can help me.
> I do not understand, that I am making bad.
> The program is:
What were you trying to do? and what was the result you expected?
What does that program do?
By the way your program is leaking memory. You call Reallo
On 15 nov 2005, at 17:11, Luis Del Aguila wrote:
Somebody can help me.
I do not understand, that I am making bad.
The program is:
Program ProbandoMemoria;
{$R+}
Var
PLPunteros: ^Pointer;
NuevoTamanio : integer;
elementos : longint;
x,b : ^integer;
Begin
elementos := 3;
NuevoTamanio
Somebody can
help me.I do not understand, that I am making bad. The program is:
Program ProbandoMemoria;{$R+}Var PLPunteros:
^Pointer; NuevoTamanio : integer; elementos :
longint; x,b : ^integer;Begin
elementos := 3; NuevoTamanio:=Sizeof(Pointer)*elementos;
ReallocMem(PlPunter
On zondag, feb 9, 2003, at 15:06 Europe/Brussels, Anton Tichawa wrote:
That's exactly what I meant: I'm not sure if fpc is able to keep track
of the
destruction of the strings in case of AnsiString.
It is, as long as the type of the variable is clear when getmem/freemem
is called (getmem also
On Sun, Feb 09, 2003 at 03:42:29PM +0100, Anton Tichawa wrote:
> Hi,
>
> > But getMem and reAllocMem allocate a number of bytes on the heap,
> > wouldn't you have to free that number of bytes using freeMem(pointer, n)
> > ?
>
> No, Free Pascal keeps track of the allocated size for a pointer creat
Hi,
> But getMem and reAllocMem allocate a number of bytes on the heap,
> wouldn't you have to free that number of bytes using freeMem(pointer, n)
> ?
No, Free Pascal keeps track of the allocated size for a pointer created with
GetMem/ReallocMem. They need this information for heap management, s
On Sun, Feb 09, 2003 at 03:12:07PM +0100, Anton Tichawa wrote:
> On Sunday 09 February 2003 12:54, you wrote:
>
> > freeMem(tmpStrings, sizeOf(String) * (N));
>
> No, only:
>
> freeMem(tmpStrings);
But getMem and reAllocMem allocate a number of bytes on the heap,
wouldn't you have to free that
On Sunday 09 February 2003 12:54, you wrote:
> freeMem(tmpStrings, sizeOf(String) * (N));
No, only:
freeMem(tmpStrings);
Read the Manual - Free Pascal Programmer's Manual, Section 4.5, "Writing Your
Own Memory Manager" - because that's what you're actually doing.
HTH
Anton Tichawa.
--
Hello, James!
That's exactly what I meant: I'm not sure if fpc is able to keep track of the
destruction of the strings in case of AnsiString. You might check it by
displaying the total free memory before and after the deallocation of
tmpStrings. But one of the developers might answer this quest
On Sun, Feb 09, 2003 at 02:22:55PM +0100, Anton Tichawa wrote:
> Hello, James!
>
> I found an error at GetMem / ReAllocMem: Your code:
>
> getMem(tmpStrings, 100);
> {reAllocMem(tmpStrings, (I + 1));}
>
> reserves 100 or (I + 1) BYTES, but you need space for 100 or (I + 1)
> STRINGS, i. e.
On Sun, Feb 09, 2003 at 02:22:55PM +0100, Anton Tichawa wrote:
> Hello, James!
>
> I found an error at GetMem / ReAllocMem: Your code:
>
> getMem(tmpStrings, 100);
> {reAllocMem(tmpStrings, (I + 1));}
>
> reserves 100 or (I + 1) BYTES, but you need space for 100 or (I + 1)
> STRINGS, i. e.
Hello, James!
I found an error at GetMem / ReAllocMem: Your code:
getMem(tmpStrings, 100);
{reAllocMem(tmpStrings, (I + 1));}
reserves 100 or (I + 1) BYTES, but you need space for 100 or (I + 1)
STRINGS, i. e. the code should be:
getMem(tmpStrings, SizeOf(String) * 100);
{reAllocMem(tm
On Sun, Feb 09, 2003 at 08:30:57PM +1000, James Mills wrote:
> Hi all,
>
> Sorry if this is trivial, but I'm sick of it :)
> I'm using fpc to convert my (originally delphi) code to read and write
> ini style files, however writing will not work as I want, the data in
> the pointer keeps getting fi
Hi all,
Sorry if this is trivial, but I'm sick of it :)
I'm using fpc to convert my (originally delphi) code to read and write
ini style files, however writing will not work as I want, the data in
the pointer keeps getting filled with junk.
I'm using getMem, and reAllocMem functions to create dyn
80 matches
Mail list logo
