In our previous episode, Jonas Maebe said: > > > That is an symmetrical argument. I could argue exactly the same about > > correctness. I don't need it, so please don't force it on all users. > > I suppose you meant that what is correct and what not depends on the > specification, rather than than that correctness is an optional design > goal.
Well, one could argue that the specification is being delphi compatible here, and point at the large codebases that rely on this. But let's not go there, that was not the point I was trying to make. >It is possible to specify that the now() call from sysutils is only > guaranteed to be correct relative to the timezone settings when the > program was started. This would however be Delphi-incompatible > (performance differences between Delphi and FPC implementations exist in > many more places than just this one, so I'm mainly considering the > functionality aspect), and imho if you need "real time behaviour" then I love the quotes by the way :-) Realtime is a subjective matter. > using high level routines from the sysutils unit is the wrong way to go > since there are no implementation guarantees whatsoever there. It was a use case example. I could replace them within 5 minutes if I wanted to, _if_ I knew what was going on though. The point was just some encouragement to look further than the immediate need though, and keep the time call relatively cheap. That doesn't exclude being correct, it just means a more elaborate implementation. Each such issue individually doesn't matter much. Together they are an horrible dragon that porters have to fight. > Generally, if you need to time things at a high precision level with > minimal overhead, then timezones etc don't matter.0 They are not really used to time execution times btw, but more to rate limit certain events to xx per second. The events can die out for hours however (if the machine is stopping for maintenance) Strictly speaking that carries a monotonous time requirement, but these are of the kind where a trip once an year doesn't matter. But harddisk latency can easily be in the half a second to second magnitude (and then I don't even count spindowns, and am I accessing directories that I continously access). In Delphi, for timing of short intervals, typically queryperformance counter + family is used, but iirc these can't measure longer intervals and are very imprecise the too (since the CPU frequency might change) > If you are in a case where you do want a high precision timer that is only > adjusted once to the system's timezone (namely when the program was > started), then I think it is quite reasonable if the RTL does not provide > such functionality in a standard call. Not entirely related to the discussion, but I don't see that at all. There is a reason why libc has monotonous time functions. Anyway, there are other reasons to go for a plugin style for this, namely that you can't predict what libs a certain *nix might need to effectively monitor the mutation of files. (e.g. that allows to do it in a thread) But to avoid the chaos of umpteen plugin units, we should maybe just define a certain plugin unit (say "cdelphi" or so) that includes all plugins you typically need for bigger apps (cwstring,clocale,cthreads,cwhatevertime), and see if we can convince Lazarus to use it. It would save both projects quite some support issues. _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
