Op 9-11-2024 om 14:59 schreef Hairy Pixels via fpc-pascal:
The solution would be to be to use a different allocator but because
FPC only allows overriding NewInstance per class it would be mean you
would need a mutex anyway to control which allocator was used
depending on the thread.
Maybe
I diagnosed a threading performance problem down to merely calling GetMem.
I did a test and it was 4x slower to call GetMem on 8 threads (my computer
core count) than one thread. Due the large amount of allocations in the
program it was actually slower to multithread the task.
I assume the problem
Thanks.
El 26/05/2011 06:15 a.m., Felipe Monteiro de Carvalho escribió:
On Wed, May 25, 2011 at 7:58 PM, Luis Fernando Del Aguila Mejía
wrote:
a: = $ ABFE5689 / / Little endian $ 8956FEAB, it is ok
Writeln (Hi (a)) / / Show $ ABFE, it is ok
Writeln (Lo (a)) / / Show $ 5689, it is ok
In a Bi
El 26/05/2011 06:15 a.m., Felipe Monteiro de Carvalho escribió:
thanks
On Wed, May 25, 2011 at 7:58 PM, Luis Fernando Del Aguila Mejía
wrote:
a: = $ ABFE5689 / / Little endian $ 8956FEAB, it is ok
Writeln (Hi (a)) / / Show $ ABFE, it is ok
Writeln (Lo (a)) / / Show $ 5689, it is ok
In a Bi
On Wed, May 25, 2011 at 7:58 PM, Luis Fernando Del Aguila Mejía
wrote:
> a: = $ ABFE5689 / / Little endian $ 8956FEAB, it is ok
> Writeln (Hi (a)) / / Show $ ABFE, it is ok
> Writeln (Lo (a)) / / Show $ 5689, it is ok
>
> In a Big Endian computer. What shows Hi and Lo?
They show same. Language c
El 25/05/2011 01:35 a.m., fpc-pascal-requ...@lists.freepascal.org escribió:
Question out of curiosity:
Is there a reason why you allocate an array "by hand"?
Yes, getmem return NIL, when no more memory is available.
SetLength, no return NIL, It is work with Exceptions.
My intention was whether
El 24/05/2011 03:57 p.m., Luis Fernando Del Aguila Mejía escribió:
I'm surprised this compiles at all.
Ok, Does my program does not compile on your computer ?
You're mixing up manual allocation of memory on the heap for variables
such as arrays with compiler allocation of heap memory for ansi
On 24 May 2011, at 20:57, Luis Fernando Del Aguila Mejía wrote:
> Yes something like that. I'm trying to emulate something like this:
>
> VarLCad = array[0..2] of ansistring;
> Begin
> LCad[0]:='01234';
> LCad[1]:='56789';
> LCad[2]:='1';
> Writeln(LCad[2]);
> End.
>
> But using
On 24.05.2011 17:22, Luis Fernando Del Aguila Mejía wrote:
I know that you can use dynamic arrays (array of). Is better.
But this does not understand and confuse me.
Why to create an array of 3 elements (ANSIString) with GetMem, I have to
put a size of 15 bytes (5*3) and not 12 bytes (4*3).?
The
I'm surprised this compiles at all.
Ok, Does my program does not compile on your computer ?
You're mixing up manual allocation of memory on the heap for variables
such as arrays with compiler allocation of heap memory for ansistrings
(which are reference counted and deallocated automatically).
Luis Fernando Del Aguila Mejía schrieb:
Var LCad:^ansiString;
AnsiString is already a pointer. LCad is now a pointer to a pointer.
That should read
Var LCad: AnsiString;
getmem(LCad,5*3); //ansistring is a pointer 4 bytes
The memory allocation and freeing is done by the compiler automat
On 24/5/11 4:22, Luis Fernando Del Aguila Mejía wrote:
I know that you can use dynamic arrays (array of). Is better.
But this does not understand and confuse me.
Why to create an array of 3 elements (ANSIString) with GetMem, I have to
put a size of 15 bytes (5*3) and not 12 bytes (4*3).?
The prog
I know that you can use dynamic arrays (array of). Is better.
But this does not understand and confuse me.
Why to create an array of 3 elements (ANSIString) with GetMem, I have to
put a size of 15 bytes (5*3) and not 12 bytes (4*3).?
The program works with 15 bytes, but do not understand why not
In our previous episode, Guillermo Mart?nez Jim?nez said:
> fSize := aObject^.size;
> GetMem (fData, fSize);
> Move (aObject^.dat, fData, fSize);
>
> Both "fData" and "dat" are untyped POINTER but the program returns an
> "Segment violation" at the Move procedure. I've checked the pointers
>
Hello.
I'm using FPC 2.2.2 on Xubuntu 8.10.
I need to reserve dynamic memory to store raw binary data. I tried the
next code:
fSize := aObject^.size;
GetMem (fData, fSize);
Move (aObject^.dat, fData, fSize);
Both "fData" and "dat" are untyped POINTER but the program returns an
"Segment vi
Hello.
I'm using
I need to reserve dynamic memory to store raw binary data. I tried the
next code:
fSize := aObject^.size;
GetMem (fData, fSize);
Move (aObject^.dat, fData, fSize);
Both "fData" and "dat" are untyped POINTER but the program returns an
"Segment violation" at the Move procedu
Skybuck Flying a écrit :
Hello,
Does GetMem care about the memory contents of the pointer variable ?
If not the parameter should be out instead of var to prevent the
following hint message:
GetMem( node, sizeof(Tnode) );
Y:\Free Pascal\Units\Technical\TnodeList\version 0.08 port to free
p
On Wed, 22 Aug 2007, Skybuck Flying wrote:
> Hello,
>
> Does GetMem care about the memory contents of the pointer variable ?
No.
>
> If not the parameter should be out instead of var to prevent the following
> hint message:
>
> GetMem( node, sizeof(Tnode) );
>
> Y:\Free Pascal\Units\Techn
Never mind.
I see what the problem is.
GetMem is actually a kind of (probably magical) wrapper around a memory
manager.
The real GetMem is a function which returns a pointer.
As I already wrote, in Delphi an out of memory exception is raised.
The result value is thus never returned, which i
Hello,
Does GetMem care about the memory contents of the pointer variable ?
If not the parameter should be out instead of var to prevent the following
hint message:
GetMem( node, sizeof(Tnode) );
Y:\Free Pascal\Units\Technical\TnodeList\version 0.08 port to free
pascal\unit_TnodeList_versi
()
var
lList : PPropList;
begin
lList := nil; // <<== New line, I expect to fix a FPC warning
...
GetMem(lList, lSize);
But it's created a warning in BDS2006
Variable assigned to LList never used
-
Simply put: the parameter is always di
Op Fri, 1 Dec 2006, schreef Graeme Geldenhuys:
> I got this question from a Delphi 2006 user regarding a code change I
> made in the tiOPF project. tiOPF is compiled with FPC using the
> Delphi compiler mode. FPC 2.0.4 and FPC 2.1.1 is used.
>
> -
>
I got this question from a Delphi 2006 user regarding a code change I
made in the tiOPF project. tiOPF is compiled with FPC using the
Delphi compiler mode. FPC 2.0.4 and FPC 2.1.1 is used.
-
procedure tiGetPropertyNames(AClass : TtiBaseObjectClass;
On dinsdag, jun 10, 2003, at 23:20 Europe/Brussels, Eduardo Morras
wrote:
I just looked at this again. If you are really getting RTE 201 then
it (probably) has nothing to do with the GetMem's. It means you are
over-indexing your arrays or seomthing similar. Good luck.
That's what surprise me,
At 14:22 10/06/2003 -0700, you wrote:
Is 1.0.8 available? I just checked www.freepascal.org and it seems
like 1.06 is the current release. You might try that version and see
if the problem goes away.
-Alan
1.07 and 1.08 are updates to 1.06. You must download them and install by
hand. In a few
--- Eduardo Morras <[EMAIL PROTECTED]> wrote:
> At 12:46 10/06/2003 -0700, you wrote:
> >I just looked at this again. If you are really getting RTE 201
> then
> >it (probably) has nothing to do with the GetMem's. It means you
> are
> >over-indexing your arrays or seomthing similar. Good luck.
>
At 12:46 10/06/2003 -0700, you wrote:
I just looked at this again. If you are really getting RTE 201 then
it (probably) has nothing to do with the GetMem's. It means you are
over-indexing your arrays or seomthing similar. Good luck.
-Alan
That's what surprise me, so rechecked and yes, the rte
I just looked at this again. If you are really getting RTE 201 then
it (probably) has nothing to do with the GetMem's. It means you are
over-indexing your arrays or seomthing similar. Good luck.
-Alan
--- Alan Mead <[EMAIL PROTECTED]> wrote:
> Eduardo,
>
> I did not follow your example, but ar
Eduardo,
I did not follow your example, but are you aware of the "growing
heap" behavior of FreePascal and the ReturnNilGrowHeapFails variable?
http://www.freepascal.org/docs-html/prog/progsu113.html#x163-1680008.4
Also, I think this ReturnNilGrowHeapFails behavior is broken in 1.0.6
and fixed i
Hello:
I've got a weird problem with getmem. I have check everything (i
think) but i can't get it work. Heaptrc says it's all ok, but when i
de-comment the next three lines ( the freemem also ), all fails
GetMem(sDicc,sizeof(rtBusqBidimen));
GetMem(ppmv,sizeof(rtMotionVector))
30 matches
Mail list logo
