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. As a result fpc can be integrated to some IDEs
without a fear or memleaks.
Just a thought.
Regards
Zilvinas Ledas
It is not a very good idea to use a GC as a means to catch mistakes made
by a programmer.
These kind of mistakes can still cause memory resource related problems
or violations.
That's not why I (re)wrote my GC interface unit (again) anyway.
But, there is no reason why it shouldn't work.
The Lazarus IDE for example is a different proposal and more difficult
to implement: You have to get rid of the suballocator mm to have it
working properly and efficently (The Lazarus IDE uses a memory manager
on top, not in place, of the default memory manager.)
At least the Boehm GC would have a performance penalty in this case
(large blocks) - being the lower level one -, but the reason it - the
sub allocator - is there is because of performance in the first place
and I would not be surprised at all if the Boehm GC would perform equal
or better after the removal of this sub allocator.
Regards,
Thaddy
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
