[fpc-pascal] Implicit conversion problem with TDate type
Hi All,
I use MWA's IBX for Firebird connection and have problem with date
parameters. Tony provided to me a test program a suggested write to the
FPC list. The simple test program is:
program Project1;
uses Variants, Sysutils;
var V: variant;
D: TDate;
begin
D := EncodeDate(2016,10,20);
V := D;
writeln('date is ',VarType(D));
end.
The result is: "date is 5" (varDouble)
If modify D: TDate; to D: TDateTime; the result is "date is 7" (varDate)
I (We) missed something or is this a bug?
Gabor
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Implicit conversion problem with TDate type
On Wed, 2 Nov 2016, Gabor Boros wrote:
Hi All,
I use MWA's IBX for Firebird connection and have problem with date
parameters. Tony provided to me a test program a suggested write to the FPC
list. The simple test program is:
program Project1;
uses Variants, Sysutils;
var V: variant;
D: TDate;
begin
D := EncodeDate(2016,10,20);
V := D;
writeln('date is ',VarType(D));
end.
The result is: "date is 5" (varDouble)
If modify D: TDate; to D: TDateTime; the result is "date is 7" (varDate)
I (We) missed something or is this a bug?
Only TDateTime is automatically converted correctly to Variant.
TDate and TTime are distinct types and not automatically converted.
They are seen as doubles (the original type of TDateTime).
If Delphi prints another result, then we can look at fixing the implementation.
Michael.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Implicit conversion problem with TDate type
Dňa 2.11.2016 o 11:38 Michael Van Canneyt napísal(a):
On Wed, 2 Nov 2016, Gabor Boros wrote:
Hi All,
I use MWA's IBX for Firebird connection and have problem with date
parameters. Tony provided to me a test program a suggested write to
the FPC list. The simple test program is:
program Project1;
uses Variants, Sysutils;
var V: variant;
D: TDate;
begin
D := EncodeDate(2016,10,20);
V := D;
writeln('date is ',VarType(D));
end.
The result is: "date is 5" (varDouble)
If modify D: TDate; to D: TDateTime; the result is "date is 7" (varDate)
I (We) missed something or is this a bug?
Only TDateTime is automatically converted correctly to Variant.
TDate and TTime are distinct types and not automatically converted.
They are seen as doubles (the original type of TDateTime).
If Delphi prints another result, then we can look at fixing the
implementation.
Delphi7 prints 5
Of course you can use V := TDateTime(D); then prints 7
-Laco.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Implicit conversion problem with TDate type
2016. 11. 02. 11:38 keltezéssel, Michael Van Canneyt írta: If Delphi prints another result, then we can look at fixing the implementation. With Delphi 10.1 and "D: TDate;" the result is "date is 5" and with "D: TDateTime;" the result is "date is 7". So, the results are same with FPC and Delphi. Gabor ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Implicit conversion problem with TDate type
It's an interesting concept i.e. if a bug exists in Delphi then it must also exist in FPC. Perhaps a better alternative is to fix these sort of bugs in FPC and to introduce a "full Dephi compatibility mode" i.e. mode Delphi plus the bugs. On 02/11/16 11:04, Gabor Boros wrote: 2016. 11. 02. 11:38 keltezéssel, Michael Van Canneyt írta: If Delphi prints another result, then we can look at fixing the implementation. With Delphi 10.1 and "D: TDate;" the result is "date is 5" and with "D: TDateTime;" the result is "date is 7". So, the results are same with FPC and Delphi. Gabor ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Implicit conversion problem with TDate type
On 2016-11-02 11:09, Tony Whyman wrote: > It's an interesting concept i.e. if a bug exists in Delphi then it must > also exist in FPC. Yes I agree. FPC's Interfaces support suffer the same fate. eg: FPC's CORBA style interfaces which Delphi doesn't have, implements the same bugs as Delphi COM Interfaces??? I would prefer FPC to be bug free, no matter the compiler mode. If you want bugs (and don't mind paying for them), stay with Delphi. If you want a better compiler which is bug free, move to Free Pascal. Regards, Graeme ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Implicit conversion problem with TDate type
It's an interesting concept i.e. if a bug exists in Delphi then it must
also exist in FPC.
Yes I agree. FPC's Interfaces support suffer the same fate. eg: FPC's
CORBA style interfaces which Delphi doesn't have, implements the same
bugs as Delphi COM Interfaces???
I would prefer FPC to be bug free, no matter the compiler mode. If you
want bugs (and don't mind paying for them), stay with Delphi. If you
want a better compiler which is bug free, move to Free Pascal.
Regards,
Graeme
Probably handling TDate as TDateTime in FPC is adding:
operator :=(const source : TDate) dest : variant;{$ifdef
SYSTEMINLINE}inline;{$endif}
begin
VariantManager.VarFromTDateTime(Dest, TDateTime(Source));
end;
in case of Delphi (at least 7) TDate is defined in Controls, so Variants
cann't depend on Controls.TDate ...
-Laco.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Does FPC has anything like TCriticalSection.Acquire with timeout?
If a CriticalSection can acquire (but with a timeout), it can avoid any gridlock. I googled and Delphi seems to have function which does time out function MonitorEnter(const AObject: TObject; Timeout: Cardinal = INFINITE): Boolean; How can I do the same in FPC? Dennis ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Does FPC has anything like TCriticalSection.Acquire with timeout?
On 2016-11-02 11:32, Dennis wrote: > How can I do the same in FPC? You can take a look at tiOPF's tiSemaphore.pas unit in the 'tiopf2' branch. tiOPF source code is hosted on SourceForge.net Regards, Graeme ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Implicit conversion problem with TDate type
On 02/11/16 12:09, Tony Whyman wrote:
It's an interesting concept i.e. if a bug exists in Delphi then it must
also exist in FPC. Perhaps a better alternative is to fix these sort of
bugs in FPC and to introduce a "full Dephi compatibility mode" i.e.
mode Delphi plus the bugs.
There is a difference between having a code construct that can be
compiled in one mode and not in another, and code that has different
behaviour in different modes. The former can be easily recognised, the
latter is much harder. In particular, it complicates reading code,
because you constantly have to be aware of the mode to know what the
code means. The same goes for changing behaviour across compiler
versions, and we have to do this way more often than I like.
Both of those things are symptoms of the worst possible situation you
can have in terms of code readability, while it is supposed to be one of
the focus points of Pascal.
We already have a few cases of code that compiles both in FPC and in
Delphi mode, such as this:
function func: longint;
begin
func:=1;
if func<>2 then
writeln('ok');
end;
In FPC mode this writes 'ok'. In Delphi mode this causes endless
recursion. These are the worst kinds of gotchas, and most of them were
introduced in the early days of FPC when we indeed thought we would fix
everything that is wrong with TP. In the end, in many cases we just
introduced our own set of idiosyncrasies that you have to know about to
avoid getting bitten.
As Lacak mentioned, you can change the behaviour of this particular case
yourself if you want, without having to go over all existing code
written in FPC/ObjFPC mode to ensure that none of it relies on the
existing behaviour (assuming that this would be changed by adding the
extra operator Laco mentioned in a unit that would only be included in
programs compiled in FPC/ObjFPC mode).
Jonas
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Implicit conversion problem with TDate type
On 02/11/16 11:29, Jonas Maebe wrote: On 02/11/16 12:09, Tony Whyman wrote: It's an interesting concept i.e. if a bug exists in Delphi then it must also exist in FPC. Perhaps a better alternative is to fix these sort of bugs in FPC and to introduce a "full Dephi compatibility mode" i.e. mode Delphi plus the bugs. There is a difference between having a code construct that can be compiled in one mode and not in another, and code that has different behaviour in different modes. The former can be easily recognised, the latter is much harder. In particular, it complicates reading code, because you constantly have to be aware of the mode to know what the code means. The same goes for changing behaviour across compiler versions, and we have to do this way more often than I like. There was a certain amount of sarcasm in my comment that perhaps got lost in translation. I suggested introducing a "delphi with bugs" mode to illustrate the absurdity of the idea. My point is that why should FPC still feel constrained by Delphi? Let's get on and fix the bugs/features that Delphi should have fixed long ago. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Implicit conversion problem with TDate type
On 02/11/16 12:53, Tony Whyman wrote: There was a certain amount of sarcasm in my comment that perhaps got lost in translation. I suggested introducing a "delphi with bugs" mode to illustrate the absurdity of the idea. My point is that why should FPC still feel constrained by Delphi? Let's get on and fix the bugs/features that Delphi should have fixed long ago. Please read my reply again. I was not talking about the downsides of a hypothetical "delphi with bugs" mode. I was talking about the downsides of changing the FPC/ObjFPC modes. I explained what the downsides would be of doing so, even if the collective "us" would have the ability to know in advance all of these changes' unintended consequences. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
