Thaddy ha scritto:
Giuliano Colla wrote:
I've never found the C++ way (Button->Click) more telling than FPC way
(Button.Click), on the contrary I find it cumbersome, but of course
you're free to think otherwise.
Huh? Button.Click is perfectly legal in C++...
Not if Button is a pointer. C++
This is a reminder that the testwindow for RC1 will close the next weekend.
Which means that there are only a few days left to check releases for
regressions and packaging bugs.
You can help improve the upcoming 2.4.0 release by downloading and
testing this release. If you want you can report wha
Jonas Maebe wrote:
Delphi compatibility. And Delphi does that because COM requires this
behaviour.
Yes, but.. As I hinted before that is because COM is reference counted
on an intermediate level by a certain OS. A simple (but performance
cost) change of the memorymanager can fix that for th
On 17 Nov 2009, at 13:43, Thaddy wrote:
Jonas Maebe wrote:
No, that is not possible. I once tried to change move and fillchar
to use "out" parameters instead of "var" parameters, and the result
was all sorts of crashes. The reason is that "out" has special
semantics for reference count
Giuliano Colla wrote:
I've never found the C++ way (Button->Click) more telling than FPC way
(Button.Click), on the contrary I find it cumbersome, but of course
you're free to think otherwise.
Huh? Button.Click is perfectly legal in C++... Although it does not mean
a dereference, but a dire
Micha Nelissen ha scritto:
Giuliano Colla wrote:
Micha Nelissen ha scritto:
Giuliano Colla wrote:
With "absolute" you need a) to declare an extra type (PByte, or
"Declaring an extra type" is one of those things that make Pascal
what it is; declaring before use.
You mean that declaring "tw
In our previous episode, Matej Spiller-Muys said:
[ Charset ISO-8859-1 unsupported, converting... ]
> > You also get breaking backwards compatibility with a lot of existing
> Delphi code for free. I repeat: you really cannot underestimate the amount
> of
> > implementation details that existing Del
Jonas Maebe wrote:
On 17 Nov 2009, at 12:04, Graeme Geldenhuys wrote:
I asked a question about a compiler hint in the fpc-users mailing list.
As JoshyFun suggested, is it not maybe better to change FillChar()
definition so first parameter is a out parameter - to prevent
unnecessary compiler
On 17 Nov 2009, at 12:04, Graeme Geldenhuys wrote:
> I asked a question about a compiler hint in the fpc-users mailing list.
> As JoshyFun suggested, is it not maybe better to change FillChar()
> definition so first parameter is a out parameter - to prevent
> unnecessary compiler hint in code?
N
Hi,
I asked a question about a compiler hint in the fpc-users mailing list.
As JoshyFun suggested, is it not maybe better to change FillChar()
definition so first parameter is a out parameter - to prevent
unnecessary compiler hint in code?
Original Message
Subject: Re: [fpc-pa
On 17 Nov 2009, at 09:30, Micha Nelissen wrote:
> Jonas Maebe wrote:
>> On 17 Nov 2009, at 08:18, Vincent Snijders wrote:
>>> If you look at CPU secs, then the factor is 3 at most. What helps the C++
>>> programs most is that they use 4 cores more, the fpc programs are mostly
>>> singlethreaded
Jonas Maebe wrote:
On 17 Nov 2009, at 08:18, Vincent Snijders wrote:
If you look at CPU secs, then the factor is 3 at most. What helps the C++
programs most is that they use 4 cores more, the fpc programs are mostly
singlethreaded. LLVM doesn't help to solve this (AFAIK).
Anyway, the above i
12 matches
Mail list logo
