hii found that shm_open and shm_unlink in smmaph.inc are mapped as externals from libc, but they belong to librt.fpc 2.0.2debian linux 2.6.14-1-k7i tested with this and worked ok:const rt = 'rt';
function shm_open(__name: pchar; __oflag: longint; __mode: mode_t): longint; cdecl; external rt name '
Yes. Why should the interface life longer? There isn't any owneranymore? If you need a longer life time, you need to assign the
interface to something.i have many structures like this (yes, in delphi):function TXList.Lock: ILock;begin result := TLock.Create(self);end;procedure dostuff;begin
list
ok, but is this a correct behavior?i think it would be best to optimize with a compiler switch or to give a switch to turn it off.i have big porting problems :(
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/
hi people,there is a problem with functions returning interfaces:if nobody stores the result, the object decrements one reference despite turn off optimizations.sample:function getobj: IUnknown;
begin Result := TInterfacedObject.Create;end;procedure test;begin getobj; // here result of getobj ha
hi people,
i found a memory leak when calling Destroy explicitly.
the leak is in 1.9.8 and 2.0
has anyone seen this?
here is an example:
program mem3;
{$mode objfpc}{$H+}
type
TTest = class (TObject, IUnknown)
private
FRefCount: Integer;
public // IUnknown
function QueryInterface(
