<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
On 18-11-2010 13:21, Žilvinas Ledas wrote:
<blockquote cite="mid:4CE51A3B.7030804@dict.lt" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<div class="moz-text-flowed" style="font-family: -moz-fixed;
font-size: 14px;" lang="x-unicode">
<blockquote type="cite" style="color: rgb(0, 0, 0);">But it
might be an advantage for some projects as the discussions
over the years implied. </blockquote>
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. <br>
Just a thought. <br>
<br>
Regards <br>
Zilvinas Ledas<br>
</div>
<br>
</blockquote>
It is not a very good idea to use a GC as a means to catch mistakes
made by a programmer.<br>
These kind of mistakes can still cause memory resource related
problems or violations.<br>
<br>
That's not why I (re)wrote my GC interface unit (again) anyway.<br>
<br>
But, there is no reason why it shouldn't work.<br>
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.)<br>
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.<br>
<br>
Regards,<br>
<br>
Thaddy<br>
<br>
</body>
</html>