Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
2013/3/8 Graeme Geldenhuys : > 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
Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7
Am 08.03.2013 00:43 schrieb "Graeme Geldenhuys" : > > 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
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
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] 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] 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 : > > 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