Re: [fpc-devel] Invalid floating point operation - roundto
I don't Get It. Right parameter is TRoundToRange not single,double or extended. In that case howto get roundto with extended precision ? function RoundTo(const AVAlue: Extended; const Digits: TRoundToRange): Extended; 2013/3/6 Jonas Maebe jonas.ma...@elis.ugent.be: On 22 Feb 2013, at 13:30, to...@ump.edu.pl wrote: s1,s2: extended; s1:=291.022; s2:=roundto(s1,-30); //TRoundToRange = -37..37; give me Invalid floating point operation. I see that roundto goes to single instead of extended. But why ? Because overload selection is based on parameter matching from right to left, and -30 can be exactly represented using single and hence is converted to that type by the compiler when it has to turn it into a floating point constant. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Delphi anonymous methods
03.03.2013 2:22, Sven Barth пишет:
On 02.03.2013 20:55, Sven Barth wrote:
Also there are open questions which require brainstorm:
1. Does Pascal needs other implementation of closures which is different
from anonymous methods implementation?
I would say no. After all the method implementation itself stays the
same, but the captured variables should be different. Or what does this
print:
I've now read through your PDF and somehow I'd like to have a better
implementation in FPC. Let's consider the following code (Note: I've
never used anonymous methods yet, so this is what I naively would expect):
=== code begin ===
var
i: LongInt;
SomeProc1, SomeProc2: reference to procedure;
begin
i := 42;
SomeProc1 := procedure
begin
Writeln('Proc1: ' + i);
end;
i := 21;
SomeProc2 := procedure
begin
Writeln('Proc2: ' + i);
end;
SomeProc1;
SomeProc2;
end;
=== code end ===
The output I'd expect here is the following:
=== output begin ===
42
21
=== output end ===
But if I've understood you correctly I'll get the following instead:
=== output begin ===
21
21
BTW closurs in c++ support both cases (capture by value and by reference).
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
On 06.03.2013 14:36, Sven Barth wrote:
Am 06.03.2013 14:29, schrieb Michael Schnell:
On 03/06/2013 01:43 PM, Sven Barth wrote:
And how does one the current TThread?
Since a few weeks: TThread.CurrentThread ;)
This does in fact use a threadvar:
threadvar
{ the instance of the current thread; in case of an external thread
this is
Nil until TThread.GetCurrentThread was called once (the RTLs need
to ensure
that threadvars are initialized with 0!) }
CurrentThreadVar: TThread;
and (unless the compiler optimizes this out) even accesses it twice:
if not Assigned(CurrentThreadVar) then
CurrentThreadVar := TExternalThread.Create;
Result := CurrentThreadVar;
From within the TThread object, simply using Self seems more
appropriate unless there is a chance that the same TThread instance is
used for multiple OS-Threads. I don't know if/how this is possible.
From outside I feel that AnyThread.GetCurrentThread does not make
much senses.
When doing TThread.GetCurrentThread as a class function I think I
should get self of same when I am in the code that is called from
Execute of some TThread instance. I don't see what I want to see
when I'm not.
The code seems to try to avoid the case that a no TThread instance
when GetCurrentThread is called as a a class function. I don't know
if/how this is sensible.
Using CurrentThread only seems sensible within the the code of a
component that has been called by the code of a TThread instance. But
here using an appropriate back-link property can easily be used to
avoid accessing the threadvar. (or using CurrentThread once to set a
property and then just accessing same.) But this of course needs to
be done in user code and the RTL can't force it.
The TThread.CurrentThread is mainly for access in functions that don't
get passed a TThread instance and to also get a TThread instance for
threads not created by the RTL (the TExternalThread.Create line
above). Don't forget that TThread.CurrentThread is a class
property/function, so you can't access Self.
We could optimize it like this:
=== code begin ===
Result := CurrentThreadVar;
if not Assigned(Result) then begin
Result := TExternalThread.Create;
CurrentThreadVar := Result;
end;
=== code end ===
So that in the normal case only one access to the threadvar is used.
I've implemented this optimization in r23706. So in the normal case the
threadvar is only read once and in the worst case it's read once and
written once.
Regards,
Sven
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
Nice... In your last message: 69 lines of quotes, 4 levels deep, and 3 lines for the actual message. Keep up the good work. Netiquette? G. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
Am 08.03.2013 00:43 schrieb Graeme Geldenhuys gra...@geldenhuys.co.uk: Nice... In your last message: 69 lines of quotes, 4 levels deep, and 3 lines for the actual message. Keep up the good work. Netiquette? This should have been shortened indeed... To my defense: I wanted to get this mail out, fix another problem (see fpc-pascal list) and hop into bed... You should also take into consideration that I normally *do* shorten my mails. Regards, Sven ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
2013/3/8 Graeme Geldenhuys gra...@geldenhuys.co.uk: Nice... In your last message: 69 lines of quotes, 4 levels deep, and 3 lines for the actual message. Keep up the good work. Good quoting, it just read that message and got a comprehensive story, especially because my autofilter deletes mails from Michael Schnelll. Netiquette? Spoilt by gmail. Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
