For both FPC and Lazarus at about 8 days ago.
--
Alexander S. Klenin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Vincent Snijders schrieb:
> Ivo Steinmann schreef:
>> Most libraries are translated by a tool like h2pas from the original
>> headers and then rehashed manually. The best solution would be, if
>> there's a tool that generates the var procedures directly from all
>> external procedures.
>
> What do
Luiz Americo Pereira Camara schrieb:
> Ivo Steinmann escreveu:
>> Vincent Snijders schrieb:
>>> Maybe it is better to generate a foobar_dyn.inc based on the
>>> foobar.inc or generate both foobar.inc and foobar_dyn.inc from a
>>> common file format (maybe even the original header file)
>>
>>
> [
Luiz Americo Pereira Camara schreef:
Vincent Snijders escreveu:
Luiz Americo Pereira Camara schreef:
I think that creating a tool to translate a static header to a dyn
header should be easy to create (i'm not talking to convert c header
directly ;-)).
Should do the following right? Correct
Vincent Snijders escreveu:
Luiz Americo Pereira Camara schreef:
I think that creating a tool to translate a static header to a dyn
header should be easy to create (i'm not talking to convert c header
directly ;-)).
Should do the following right? Correct me if i'm wrong:
Static function:
f
Vincent Snijders wrote:
Should do the following right? Correct me if i'm wrong:
Static function:
function foobar_dosomething(a:cint; b:cdouble): cint; extdecl;external
foobarlib;
Becomes a dyn function:
var foobar_dosomething: function(a:cint; b:cdouble): cint; extdecl;
And a statement t
Luiz Americo Pereira Camara schreef:
Ivo Steinmann escreveu:
Vincent Snijders schrieb:
Maybe it is better to generate a foobar_dyn.inc based on the
foobar.inc or generate both foobar.inc and foobar_dyn.inc from a
common file format (maybe even the original header file)
[..]
Most librarie
Ivo Steinmann escreveu:
Vincent Snijders schrieb:
Maybe it is better to generate a foobar_dyn.inc based on the
foobar.inc or generate both foobar.inc and foobar_dyn.inc from a
common file format (maybe even the original header file)
[..]
Most libraries are translated by a tool like h2pas
Ivo Steinmann schreef:
Most libraries are translated by a tool like h2pas from the original
headers and then rehashed manually. The best solution would be, if
there's a tool that generates the var procedures directly from all
external procedures.
What do you exactly mean? A tool which takes for
Vincent Snijders schrieb:
> Ivo Steinmann schreef:
>> Hello all
>>
>> I started some wiki for dynamic loading libraries support discussion.
>>
>> http://wiki.freepascal.org/Dynamically_loading_headers
>>
>> I already added an experimental implementation. If you have got some
>> ideas, whises and cr
Vincent Snijders пишет:
I don't like the looks of lines like:
{$IFDEF S}function{$ELSE}var{$ENDIF}foobar_dosomething{$IFDEF D}:
function{$ENDIF}(a:cint; b:cdouble): cint; extdecl;{$IFDEF S}external
foobarlib;{$ENDIF}
They are hard to read. I understand that this way makes sure that both
st
> That should also be the current behaviour for FPC. So if you want to
> always use the full array, change your lower array bounds.
> Jonas
I will keep that in mind - thanks
Carsten
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lis
Ivo Steinmann schreef:
Hello all
I started some wiki for dynamic loading libraries support discussion.
http://wiki.freepascal.org/Dynamically_loading_headers
I already added an experimental implementation. If you have got some
ideas, whises and criticism, don't hesitate to write.
I don't li
Michael Schnell wrote on Mon, 02 Nov 2009:
Jonas Maebe wrote:
a) if the array is zero-based (i.e., lower bound is 0), then the array
of char is treated as a null-terminated string
b) if the array is non-zero-based, then the array of char is always
checked completely
The Delphi behavior sounds
Jonas Maebe wrote:
> a) if the array is zero-based (i.e., lower bound is 0), then the array
> of char is treated as a null-terminated string
> b) if the array is non-zero-based, then the array of char is always
> checked completely
The Delphi behavior sounds not very obvious :(.
Is this true as w
Carsten Bager wrote on Mon, 02 Nov 2009:
As far as I can see, the problem is the compiler does not differ between an
array of char and a null terminated string.
As a result of this, if the first byte/char are 0 in both arrays the compiler
stops checking and says that there are equal.
When I im
> In our previous episode, Carsten Bager said:
> > Here is output from my program p compiled with Delphi (5) and FPC.
> > I believe that FPC fails because the first byte is chr(0) when comparing
> > 70501033728 with
> > 0.
>
> Did you also try this on a PC? I haven't really tested, but it
> see
In our previous episode, Carsten Bager said:
> Here is output from my program p compiled with Delphi (5) and FPC.
> I believe that FPC fails because the first byte is chr(0) when comparing
> 70501033728 with
> 0.
Did you also try this on a PC? I haven't really tested, but it
seems that you are
Here is output from my program p compiled with Delphi (5) and FPC.
I believe that FPC fails because the first byte is chr(0) when comparing
70501033728 with
0.
I did run into this problem when moving code from a Pascal compiler that can
compare
records of the same type.
In Delphi I can come arou
Sven Barth schrieb:
> Florian Klaempfl schrieb:
>> Sven Barth schrieb:
>>> All in all I have the following goals for (my) future work on this:
>>> * make a cppclass an implicit pointer
>>
>> I don't like this idea because C++-classes aren't an implicit pointer
>> either.
>>
>
> At first I wanted t
Dimitrios Chr. Ioannidis schrieb:
>> * native x86_64 compiler (assuming your fpc.exe in the path is an
>> x86_64 version)
>> * 'native' i386 compiler
>> * ARM/wince cross-compiler
>
> In the above case i will end up with two dir's in fpc\bin. One
> i386-win32 and one x86_64-win64.
Just use a cro
21 matches
Mail list logo
