On 22 Oct 2008, at 05:05, Guru Kathiresan wrote:
Thanks for the reply. That seems to work, but I think there is a bug
in the
FPC. When I do a {$linklib myfile.dylib} , it is not picking up the
myfile.dylib, the compiler is looking for libmyfile.so . I had to
rename the
library from
Hey. I just went inside the file and deleted all the -Opentium3 lines and
it worked. Not really sure about the reason but it worked =).
Cheers
Lude
Jonas Maebe-2 wrote:
On 15 Aug 2008, at 09:39, Michael Van Canneyt wrote:
On Fri, 15 Aug 2008, John Youngquist wrote:
I also routinely
I have an assembler procedure of about a 1500 lines of code. The problem is
the jumps are generated with absolute addresses only, even if I explicitly
specify
short postfix. Why is it? The code size is critical for me. I am using
lazarus with fpc 2.2.2. Example code:
sub eax,dword ptr [esp]
On 22 Oct 2008, at 10:46, Саша Иваненко wrote:
I have an assembler procedure of about a 1500 lines of code. The
problem is the jumps are generated with absolute addresses only,
even if I explicitly specify
short postfix. Why is it? The code size is critical for me. I am
using lazarus
In our previous episode, Jonas Maebe said:
There has been a lot of discussion about this problem. What happens is
that FPC wishes to always have ansistrings holding system locale
encoded strings, it's impossible to have strings which store utf-8
data as far as FPC is concerned.
And the
Then it's indeed much cleaner to simply introduce a new string type which does
not have to be compatible with the OS encoding.
Agree!. It's an illusion that it's possible to hide the complexitiy
of different string encodings from the programmer.
Instead, such tries always lead to a disaster
On Wednesday 22 October 2008 12.33:59 Marco van de Voort wrote:
The solution of Tiburon is the same as Florian's original solution for the
multi unicode string type TUnicodeString (that now is still UTF16 only):
add an encoding field to ansistring, and alter ansistring declaration with
an
In our previous episode, Martin Schreiber said:
The solution has Windows written all over it (including viewer UTF-8 as a
codepage), but it has merits IMHO.
Are you sure about the encoding field for every string instance?
Yes.
It could be done by compiler magic and an encoding field in
On Wednesday 22 October 2008 13.31:41 Marco van de Voort wrote:
In our previous episode, Martin Schreiber said:
The solution has Windows written all over it (including viewer UTF-8 as
a codepage), but it has merits IMHO.
Are you sure about the encoding field for every string instance?
In our previous episode, Martin Schreiber said:
No, since then the runtime routines must be overloaded again, for each
compiler magic'ed type (all codepages +UTF-8, and another two).
A runtime routine must be able to detect what kind of string type it
receives, or you need a runtime
Hi,
Im wondering if FPC Team have plans to support Record Methods/Operators
in future versions of FPC
I read the actual Future plans and the most closed item is RTL:: More
compatibility with later Delphi versions.
But it do not means that records can be changed.
I want to implement my
Cesar Romero schrieb:
Hi,
Im wondering if FPC Team have plans to support Record Methods/Operators
in future versions of FPC
I read the actual Future plans and the most closed item is RTL:: More
compatibility with later Delphi versions.
But it do not means that records can be changed.
I
Florian Klaempfl escreveu:
Cesar Romero schrieb:
Hi,
Im wondering if FPC Team have plans to support Record Methods/Operators
in future versions of FPC
I read the actual Future plans and the most closed item is RTL:: More
compatibility with later Delphi versions.
But it do not means that
Florian Klaempfl escreveu:
Cesar Romero schrieb:
Hi,
Im wondering if FPC Team have plans to support Record Methods/Operators
in future versions of FPC
I read the actual Future plans and the most closed item is RTL:: More
compatibility with later Delphi versions.
But it do not means that
Cesar Romero schrieb:
Florian Klaempfl escreveu:
Cesar Romero schrieb:
Hi,
Im wondering if FPC Team have plans to support Record Methods/Operators
in future versions of FPC
I read the actual Future plans and the most closed item is RTL:: More
compatibility with later Delphi versions.
Florian,
In which regard, quoting: The assignment operator is also used to
convert types from one type to another. The compiler will consider all
overloaded assignment operators till it finds one that matches the types
of the left hand and right hand expressions. If no such operator is
found, a
Cesar Romero schrieb:
Florian,
In which regard, quoting: The assignment operator is also used to
convert types from one type to another. The compiler will consider all
overloaded assignment operators till it finds one that matches the types
of the left hand and right hand expressions. If no
17 matches
Mail list logo
