Am 18.11.2010 15:27, schrieb Thaddy:
On 18-11-2010 13:21, Žilvinas Ledas wrote:
But it might be an advantage for some projects as the discussions
over the years implied.
What about using GC for fpc itself? If it is usable for fpc, then the
problem of fpc leaking memory when compilation
On Fri, 19 Nov 2010, Florian Klaempfl wrote:
Am 18.11.2010 15:27, schrieb Thaddy:
On 18-11-2010 13:21, Žilvinas Ledas wrote:
But it might be an advantage for some projects as the discussions
over the years implied.
What about using GC for fpc itself? If it is usable for fpc, then the
It works, but there is a small problem: the compiler itself is a
nightmare for any heap manager and it shows*THE* disadvantages of GC:
it is sloow.
Compiling the system unit with the default heap manager:
0.4 sec
with the BoehmGC port
98.9 sec (creates a ppu, but crashes on exit)
But it might be an advantage for some projects as the discussions over
the years implied.
What about using GC for fpc itself? If it is usable for fpc, then the
problem of fpc leaking memory when compilation fails with errors can be
solved using GC. As a result fpc can be integrated to some
On 11/18/2010 08:05 AM, Thaddy wrote:
To summarize: what you write/propose is already in there :)
OK, great, its there, but how to get it _here_ ?
To make it useful FPC would need some the appropriate keywords (such as
GarbageControlled) for creating this type of variables, and it would
On 18-11-2010 13:21, Z(ilvinas Ledas wrote:
But it might be an advantage for some projects as the discussions
over the years implied.
What about using GC for fpc itself? If it is usable for fpc, then the
problem of fpc leaking memory when compilation fails with errors can
be solved using GC.
On 11/15/2010 02:04 PM, Thaddy wrote: ...
If you want to extend a compiler to allow for garbage collection, would
it not be appropriate to have it manage an additional type of variables
that is supposed to be garbage collection enabled pointers and have it
always create double indirect
On 17-11-2010 10:01, Michael Schnell wrote:
On 11/15/2010 02:04 PM, Thaddy wrote: ...
If you want to extend a compiler to allow for garbage collection,
would it not be appropriate to have it manage an additional type of
variables that is supposed to be garbage collection enabled
pointers
The rants about finalizers versus destructors in the context of GC are a
many.
Let me make it clear that these discussions almost invariably presume
the context of the C(++) language.
The main thing being that C++ allocates objects/classes from the stack
by default. In Freepascal (in Delphi
Thaddy schrieb:
The rants about finalizers versus destructors in the context of GC are a
many.
Let me make it clear that these discussions almost invariably presume
the context of the C(++) language.
The main thing being that C++ allocates objects/classes from the stack
by default. In
As I promised Marco,
You can find boehm garbage collector bindings for freepascal, incl.
replacement memory manager at
http://freepascal.thaddy.co.uk/fpc_boehm_gc.zip
For win32 a prebuild dll is included
For other platforms you need to build the gc library from source (included)
Please test, I
In our previous episode, Thaddy said:
You can find boehm garbage collector bindings for freepascal, incl.
replacement memory manager at
http://freepascal.thaddy.co.uk/fpc_boehm_gc.zip
For win32 a prebuild dll is included
For other platforms you need to build the gc library from source
On Mon, 15 Nov 2010, Marco van de Voort wrote:
In our previous episode, Thaddy said:
You can find boehm garbage collector bindings for freepascal, incl.
replacement memory manager at
http://freepascal.thaddy.co.uk/fpc_boehm_gc.zip
For win32 a prebuild dll is included
For other platforms you
On 15-11-2010 14:50, Marco van de Voort wrote:
Oh. Am I supposed to do that? :-)
Yes, please :-) , but others are welcome...
(I just collect info about this subject because it is a recurring white
elephant. Regularly there is talk about it, but nobody has seen a working
implementation, and
On 15-11-2010 14:59, Michael Van Canneyt wrote:
You must finalize, because ref. counting of interfaces etc. need to be
taken
care of. Interfaces may live outside the FPC memory space, and are
therefor
not accessible to the GC. If you want to let the GC collector handle all
that, you're in
On 15-11-2010 14:59, Michael Van Canneyt wrote:
You must finalize, because ref. counting of interfaces etc. need to be
taken
care of. Interfaces may live outside the FPC memory space, and are
therefor
not accessible to the GC. If you want to let the GC collector handle all
that, you're in
Thaddy schrieb:
Actually, I am *calling* the destructor in the finalizer, not copying
it. AFAIK this should take care of it.
IMO destructors and finalizers are mutually exclusive, I remember a note
like Why a garbage collector never should call an destructor, that at
least applies to
17 matches
Mail list logo
