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
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 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
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:
> 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 chan
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 Val
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 run
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 i
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 fiel
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
> a
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.
>
>
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 w
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 wi
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
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
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 myfile.
17 matches
Mail list logo
