Jamie McCracken wrote:
> A GC needs to trace an object's references to see if anything still
> points to it. How else can it decide whether an object is no longer in use?
GC starts from known alive object references, in static or local
variables, and follows the references in these objects to fur
Jamie McCracken wrote:
> A GC needs to trace an object's references to see if anything still
> points to it. How else can it decide whether an object is no longer in use?
GC starts from known alive object references, in static or local
variables, and follows the references in these objects to fur
Hi
So here they are. Initially I was making my changes versus gtk2forpascal
from sourceforge, but now I made them versus FPC sources, since I can't
connect to gtk2forpascal cvs on sourceforge. I also noticed that version
from FPC tree already contains some of the fixes I was going to send...
ex
On Mon, 28 Feb 2005 20:55:54 +0100
Michalis Kamburelis <[EMAIL PROTECTED]> wrote:
> Hi
>
> I have a couple of corrections to gtk 2 bindings, gtk2forpascal. I also
> made gtkglext bindings that could be incorporated into gtk 2 bindings,
> if it feels appropriate (since, as far as I know, initial
Hi
I have a couple of corrections to gtk 2 bindings, gtk2forpascal. I also
made gtkglext bindings that could be incorporated into gtk 2 bindings,
if it feels appropriate (since, as far as I know, initial goal of
gtk2forpascal was to include gtkglext bindings, but they were not
implemented becau
>>> But it could be used on platforms that have a "fairly" stable and
>>> standardised C++ ABI (windows and Linux mainly). Other platforms can
>>> use the current FPC generic method as a fallback.
>>
>>
>> FPC could use that trick on (pretty much?) any platform. It doesn't have
>> to be compatible
On 28 feb 2005, at 13:14, Jamie McCracken wrote:
FPC could use that trick on (pretty much?) any platform. It doesn't
have to be compatible with the official C++ abi of that platform
(just like the current technique isn't either). It just isn't
implemented yet.
Yes thats right which is why I thin
Jonas Maebe wrote:
On 28 feb 2005, at 12:26, Jamie McCracken wrote:
FPC uses an platform independent method. The C++ ABI isn't used.
But it could be used on platforms that have a "fairly" stable and
standardised C++ ABI (windows and Linux mainly). Other platforms can
use the current FPC generic
On 28 feb 2005, at 12:26, Jamie McCracken wrote:
FPC uses an platform independent method. The C++ ABI isn't used.
But it could be used on platforms that have a "fairly" stable and
standardised C++ ABI (windows and Linux mainly). Other platforms can
use the current FPC generic method as a fallback
Peter Vreman wrote:
Why are you looking at GC/Refcounting when the problem is the
try..finally?
It is better to rewrite the try..finally code using the C++ ABI for
exception handling.
Where do you see improvements in the C++ ABI? Or even differences?
Windows implements this ABI, and every language
For your information:
Make cycle using fpc 1.0.10 as starting compiler fails:
d:/fpc/bin/ppc386-release.exe -Ur -Xs -OG2p3 -n -Fi../inc -Fi../i386 -FE.
-FUD:/lazarus/source/fpc-1.9/rtl/units/i386-win32 -gl -di386 -dRELEASE -Us -Sg
syswin32.pp
system.pp(924,18) Error: call by var parameters have t
11 matches
Mail list logo
