QuadSingle
QuadInteger
DoubleDouble
DoubleInt64
etc...
TVector = QuaterSingle;
function addv(a, b: TVector): TVector;
begin
Result := a + b;
// this is done with one single instruction (multiple data)
end;
-Ivo Steinmann
___
fpc-devel maillist - fpc
Joost van der Sluis schrieb:
> On Mon, 2009-11-09 at 09:14 +0100, Florian Klaempfl wrote:
>
>> Ivo Steinmann schrieb:
>>
>>> Delphi have got also a solution:
>>>
>>> http://docwiki.embarcadero.com/RADStudio/en/Libraries_and_Packages#Delayed_Lo
Delphi have got also a solution:
http://docwiki.embarcadero.com/RADStudio/en/Libraries_and_Packages#Delayed_Loading
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Luiz Americo Pereira Camara schrieb:
> Ivo Steinmann escreveu:
>> are you also on irc in #fpc @freenode? I'm often online there with nick
>> Aison
>>
>
> I don't use irc often, but should do if necessary.
>
> I will try to do the tool this weekend
Jonas Maebe schrieb:
>
> On 04 Nov 2009, at 02:37, Ivo Steinmann wrote:
>
>> The more important question is: should we do it this way or should I
>> also write a 2nd implementation by modifying the compiler (branched)?
>> Then we don't need an external tool at all.
The more important question is: should we do it this way or should I
also write a 2nd implementation by modifying the compiler (branched)?
Then we don't need an external tool at all.
-Ivo ;)
Luiz Americo Pereira Camara schrieb:
> Joost van der Sluis escreveu:
>> On Mon, 2009-11-02 at 17:13 -0300
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
>>
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
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 implementati
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.
-Ivo Steinmann
<http://www
pe size_t
was used. csize_t is now available for all platforms over ctypes.
-Ivo Steinmann
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Florian Klaempfl schrieb:
Ivo Steinmann schrieb:
1. Using =nil or Assigned should result in the same.
Afaik not, this was one of the reasons for assigned.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org
Mattias Gärtner schrieb:
Zitat von Vincent Snijders :
Jonas Maebe schreef:
On 10 Sep 2009, at 14:01, Mattias Gärtner wrote:
Mattias Gärtner wrote:
Can someone explain why in mode objfpc comparing methods only
compares
the address, but not the instance?
Seems perfectly logical to me (@
it was an accident removing it (or better uncomment it)
My Answer to the core liste:
This function wasn't actually to change in TComponent, I simply forgot
to uncomment it again. Did some testings, and because it was nowhere
used I didn't got an error and so I forgot to reenable it.
But th
Michael Schnell schrieb:
>
>> The encoding can be important for speed:
>> For example the widestring xml parser is up to 10 times slower than
>> the ansistring xml parser.
>>
> That obviously is the reason why Turbo - Delphi uses UCS-2 (16 bit)
> instead of OF UTF-8 or UTF-16 for WideStrings (an
S1 := 'foobar';
S2 := S1;
SetEncoding(S2, UTF16); <<< exception
for fast string processing, it's easy to convert a string to UCS32
S1: UTF8String;
S2: UCS32String;
P: PUCS32Char;
S2 := S1;
for i := 0 to length(S2) - 1 do
S2[i] := 'X';
S1 := S2;
or
P := PUCS32Cha
Ivo Steinmann schrieb:
>
> In the core of all windows nt systems, there's the NT API. The normal
> WinAPI is on the top of the NTAPI. the NT API itself uses UTF-16 as
> stringtype!
>
> type
> UNICODE_STRING = record
> Length: USHORT;
> MaximumLength: USHO
:= 0;
attr.Attributes := 0;
attr.ObjectName := @str;
attr.SecurityDescriptor := nil;
attr.SecurityQualityOfService := nil;
NtOpenFile(@Handle, ntmode, @attr, @io, FileShareMode,
FILE_NON_DIRECTORY_FILE or FILE_SYNCHRONOUS_IO_NONALERT)
end;
So in core, winnt is working with UTF16. All ANSI Winapi functions map
to these winnt calls.
-Ivo Steinmann
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Graeme Geldenhuys schrieb:
> Hi,
>
> I was following a discussion in the delphi.non-technical newsgroup.
> They raised an issue about distinct types. I tried the following
> example under FPC and unexpectedly, FPC doesn't raise any errors!
>
> If you declare a distinct type as follows:
> type TMy
Marco van de Voort schrieb:
I didn't change anything in the trunk, so this is quit strange. I only
worked in the branch. But I will check
> Probably for Ivo:
>
> Suddenly a lot of units give warnings/hints like:
>
> Compiling ../inc/ctypes.pp
> aliasctp.inc(19,28) Hint: Type "cint8" redefiniti
Anton Kavalenka schrieb:
> Florian Klaempfl wrote:
>> I've continued to work on support of an unicodestring type in fpc.
>> It's currently in an svn branch at:
>> http://svn.freepascal.org/svn/fpc/branches/unicodestring
>> and will be merged later to trunk. The unicodestring type is a ref.
>> count
Marco van de Voort schrieb:
In our previous episode, Luiz Americo Pereira Camara said:
And use TNativeString for encoding agnostic purposes.
Well, really agnostic code should simply use "string" :)
Delphi is introducing the RawByteString type, that skips the auto
encoding c
t
- additional flag required
+ allways the optimal encoding is used
+ the dont have to care about encoding (except if he read from sources
with different encodings, like textfiles)
- maybe some extra encode/decode work required
-Ivo Steinmann
Florian Klaempfl schrieb:
I've continued
tfrom dependant code.
Just stay on...
-Ivo Steinmann
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Marc Weustink wrote:
program TypeTest;
{$mode objfpc}{$h+}
type
TMyA = type String;
TMyB = type String;
var
A: TMyA;
B: TMyB;
S: String;
begin
S := 'Some value';
A := S;
B := S;
S := A;
S := B;
A := B;
B := A;
end.
Well, assign works, but if you use them as var Pa
c mode are also treated as pointer to an array of that type, that
means P[...] is allways allowed also.
greets
Ivo Steinmann (Aison)
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Ivo Steinmann wrote:
Hello all
I tried to link libmodplug.so but get this error:
/usr/lib/libmodplug.so: undefined reference to `operator
new[](unsigned int)'
/usr/lib/libmodplug.so: undefined reference to `operator delete(void*)'
/usr/lib/libmodplug.so: undefined reference to
Hello all
I tried to link libmodplug.so but get this error:
/usr/lib/libmodplug.so: undefined reference to `operator new[](unsigned
int)'
/usr/lib/libmodplug.so: undefined reference to `operator delete(void*)'
/usr/lib/libmodplug.so: undefined reference to `operator delete[](void*)'
/usr/lib/l
tested that with inline assembler, and it's working ;)
greetings
Ivo Steinmann
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Ivo Steinmann wrote:
Jonas Maebe wrote:
This is revision 4648, so I doubt you meant this one:
oh, sorry, it's 2649, 2648 is the last that worked
damn it, it's 4649! lol, im tired
___
fpc-devel maillist - fpc-devel@lists.free
Jonas Maebe wrote:
This is revision 4648, so I doubt you meant this one:
oh, sorry, it's 2649, 2648 is the last that worked
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Hello all
since revision 4648, the cycle build fails on i386-linux (as it did on
amd64, but that's fixed)
regards
Ivo Steinmann (Aison/ivost)
make -C ../rtl 'OPT=' all
make[4]: Entering directory `/usr/src/fpc/rtl'
make -C linux all
make[5]: Entering directory `/usr/s
32 matches
Mail list logo
