Am 20.10.2010 10:07, schrieb Michael Schnell:
but this would be a lot better than the
current situation where linking FPC and C++ is completely impossible due
to the different ABI.
Really? How does accessing Qt then work? Do you know more than me? Did I
dream that Lazarus has a Qt widget set?
In our previous episode, Florian Klaempfl said:
to the different ABI.
Really? How does accessing Qt then work? Do you know more than me? Did I
dream that Lazarus has a Qt widget set? Even more: who does the
compilation of e.g.
(euh, it doesn't link to C++, but to a C library that wraps the
Am 21.10.2010 09:14, schrieb Marco van de Voort:
In our previous episode, Florian Klaempfl said:
to the different ABI.
Really? How does accessing Qt then work? Do you know more than me? Did I
dream that Lazarus has a Qt widget set? Even more: who does the
compilation of e.g.
(euh, it
In our previous episode, Florian Klaempfl said:
Really? How does accessing Qt then work? Do you know more than me? Did I
dream that Lazarus has a Qt widget set? Even more: who does the
compilation of e.g.
(euh, it doesn't link to C++, but to a C library that wraps the C++ QT?)
So
Am 21.10.2010 09:22, schrieb Marco van de Voort:
In our previous episode, Florian Klaempfl said:
Really? How does accessing Qt then work? Do you know more than me? Did I
dream that Lazarus has a Qt widget set? Even more: who does the
compilation of e.g.
(euh, it doesn't link to C++, but to a
Am 21.10.2010 08:54, schrieb Florian Klaempfl:
Am 20.10.2010 10:07, schrieb Michael Schnell:
but this would be a lot better than the
current situation where linking FPC and C++ is completely impossible due
to the different ABI.
Really? How does accessing Qt then work? Do you know more than
Am 21.10.2010 09:51, schrieb Sven Barth:
Am 21.10.2010 08:54, schrieb Florian Klaempfl:
Am 20.10.2010 10:07, schrieb Michael Schnell:
but this would be a lot better than the
current situation where linking FPC and C++ is completely impossible due
to the different ABI.
Really? How does
Am 21.10.2010 09:57, schrieb Florian Klaempfl:
Am 21.10.2010 09:51, schrieb Sven Barth:
Am 21.10.2010 08:54, schrieb Florian Klaempfl:
Am 20.10.2010 10:07, schrieb Michael Schnell:
but this would be a lot better than the
current situation where linking FPC and C++ is completely impossible due
On Thu, Oct 21, 2010 at 8:54 AM, Florian Klaempfl
flor...@freepascal.org wrote:
The tests (which cover only part of the cppclass support in FPC) are one
of the reality checks for your hypotheses about the usefulness of a
crippled C++ front end. And they show: crippled C++ support is not
Am 21.10.2010 11:00, schrieb Felipe Monteiro de Carvalho:
On Thu, Oct 21, 2010 at 8:54 AM, Florian Klaempfl
flor...@freepascal.org wrote:
The tests (which cover only part of the cppclass support in FPC) are one
of the reality checks for your hypotheses about the usefulness of a
crippled C++
Marco van de Voort schrieb:
Still, C would be doable, for porting SOME existing code to co-operarate
directly with pascal code. If the C code uses lots of library calls it can't
be used directly. But, there is code for math and compression etc. which don't
call libraries much.
The
Marco van de Voort schrieb:
I personally think that fully automated C header conversion is not possible.
It is, but at the same cost of e.g. fully automated Delphi project
conversion. In an FPC project the related items (modes, targets, search
paths...) are configurable in several ways - the
Dimitri Smits schrieb:
as for the linking of C++/FPC:
good argument, but then your fpc-compiled c++ will be incompatible with
everything else. Come to think of it, no 2 C++ compilers mangle the same due to
VMT and other abi-stuff anyway.
+1
C++ is not only a different syntax, it also comes
Marco van de Voort schrieb:
PChars, on the other hand, require manual memory management
which is the source of bugs.
Point out the example of bugs. (ones that matter, not the stylistic ones)
The usage of PString essentially is using an crippled AnsiString,
without reference counting. I did
Hans-Peter Diettrich пишет:
Marco van de Voort schrieb:
PChars, on the other hand, require manual memory management
which is the source of bugs.
Point out the example of bugs. (ones that matter, not the stylistic ones)
The usage of PString essentially is using an crippled AnsiString,
Hi,
I updated my FPC (2.5.1) and Lazarus (0.9.29 rev 27706) and, now, I can't
compile the Zeos package (ver 6.6.6).
The error is:
[...]\zeos\6.6.6-stable\src\core\ZClasses.pas(84,22) Error: No matching
implementation for interface method IUnknown.QueryInterface(constref
TGuid,out Formal
On 21 Oct 2010, at 21:05, Marcos Douglas wrote:
There is, in objpash.inc, line 246:
function QueryInterface({$IFDEF
FPC_HAS_CONSTREF}constref{$ELSE}const{$ENDIF} iid : tguid;out obj) :
longint;{$IFNDEF WINDOWS}cdecl{$ELSE}stdcall{$ENDIF};
What is constref,
A const parameter that is
On Thu, Oct 21, 2010 at 4:17 PM, Jonas Maebe jonas.ma...@elis.ugent.be wrote:
On 21 Oct 2010, at 21:05, Marcos Douglas wrote:
There is, in objpash.inc, line 246:
function QueryInterface({$IFDEF
FPC_HAS_CONSTREF}constref{$ELSE}const{$ENDIF} iid : tguid;out obj) :
longint;{$IFNDEF
1.) Say you have a string of certain length 25
2.) And you have a memory block of 26.
3.) You move Pchar(s) into ar[i] but read beyond the length of the string
//GetMem(ar[i],length(s)+1);
//StrMove(PChar(ar[i]),Pchar(s),Length(S)+1);
iLen:=length(s);
On Thu, 21 Oct 2010, Andrew Brunner wrote:
1.) Say you have a string of certain length 25
2.) And you have a memory block of 26.
3.) You move Pchar(s) into ar[i] but read beyond the length of the string
//GetMem(ar[i],length(s)+1);
22.10.2010 1:19, Andrew Brunner:
As of right now the PostgreSQL component does not handle Int64
dataype and is crippling any use of the DBMS. If MySQL and PostgreSQL
are broken - I just don't see the point of supporting SQL DBMSes.
Just in case: also have a look at zeosdbo library. I'm not
Updated today one of the Ubuntu-Machines to Maverick x64.
Then started a svn up and tried to compile fpc.
The x64 version was compiled and installed without any problems, but
when I tried to compile the i386 crosscompiler with
make all CPU_TARGET=i386
the build script stops.
Output is:
make
Below is a very small sample program.
Compiling it using a recent trunk version of fpc (younger than 2 weeks)
does not give any hints.
If I uncomment the var block, there will be a hint, about TBar being
deprecated.
But the usage of TBar in the procedure declaration is not hinted at.
Is
23 matches
Mail list logo
