Re: [fpc-pascal] Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)
Am 24.02.2016 16:44 schrieb "Mark Morgan Lloyd" < markmll.fpc-pas...@telemetry.co.uk>: > > Bo Berglund wrote: >> >> On Tue, 23 Feb 2016 23:58:37 +0100, Sven Barth >> wrote: >>> >>> What would really help here would be the warning that Jonas mentioned... >>> For the above you could just use a local variable and be done with it. No >>> need to try to "fix" the with-statement. >> >> >> I really fully agree! > > > Perhaps a hint when a single WITH is used and a warning if they're nested. After all, it /is/ a standard part of the language. A warning when another identifier is shadowed might be more useful as Jonas said. Cause then one could find all problematic identifiers and not just all withs... Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)
Am 24.02.2016 12:30 schrieb "Bo Berglund" : > > On Tue, 23 Feb 2016 23:58:37 +0100, Sven Barth > wrote: > > > >What would really help here would be the warning that Jonas mentioned... > >For the above you could just use a local variable and be done with it. No > >need to try to "fix" the with-statement. > > I really fully agree! > When working a few years back I had to trace through a piece of code > where the original author had done something like: > > with My.Stuff.something do > with My.Other.Stuff.somethingelse do > with myyetanother do > begin > someproperty := xxx; > > > end; > It was totally impossible to make sense of anything while debugging! Just as a sidenote: Lazarus handles withs correctly while debugging ;) Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)
Bo Berglund wrote: On Tue, 23 Feb 2016 23:58:37 +0100, Sven Barth wrote: What would really help here would be the warning that Jonas mentioned... For the above you could just use a local variable and be done with it. No need to try to "fix" the with-statement. I really fully agree! Perhaps a hint when a single WITH is used and a warning if they're nested. After all, it /is/ a standard part of the language. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)
etrusco wrote > I loved 'with' while I was learning Delphi/Pascal and hated after the > first few months since using it professionaly. I truly believe it > warrants/deserves some advice in the documentation, for the beginners. > With the code completion in Lazarus there's even less reason to use it > - besides any possibly missing compiler optimization... Indeed, there are no big differences between "uses" and "with" in Object Pascal, "using namespace" in C++ or "using" in C#. For example, my short article "Crack C# namespaces in 30 seconds" http://arbinada.com/main/en/node/1416 - -- Regards, Serguei -- View this message in context: http://free-pascal-general.1045716.n5.nabble.com/Bug-in-FPC-3-0-0-was-Bug-in-FPC-3-0-0-tp5724274p5724311.html Sent from the Free Pascal - General mailing list archive at Nabble.com. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)
On Wed, Feb 24, 2016 at 9:00 AM, Michael Van Canneyt wrote: > > > On Wed, 24 Feb 2016, Flávio Etrusco wrote: > >> On Wed, Feb 24, 2016 at 8:39 AM, Marco van de Voort >> wrote: >>> >>> In our previous episode, Mark Morgan Lloyd said: > (remember recent discussion about IfThen pseudo-function). More relevant to your situation, I remember discussion about adding an identifier to WITH to use as an explicit shortcut, i.e. something like with foo= bar do foo.someField := ... >>> >>> >>> Not relevant since the With code in this case must remain delphi >>> compatible. >> >> >> I, for one, would vote in favor making the documentation discourage >> the use of 'with' and adding a warning in compiler... > > > I don't see why. > > I use "with" extensively. I see nothing wrong with this useful construct. > > The problem of the 'new identifier inserted in scope' exists, but is rare > enough for me to tip the balance in favour of using "with". It has maybe > happened once or twice in 25 years that I got bitten by it. > > I find that perfectly acceptable. > > For people that worry about this, the solution of Jonas should be ample to > detect/avoid mistakes. > > Michael. I loved 'with' while I was learning Delphi/Pascal and hated after the first few months since using it professionaly. I truly believe it warrants/deserves some advice in the documentation, for the beginners. With the code completion in Lazarus there's even less reason to use it - besides any possibly missing compiler optimization... Best regards, Flávio ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)
Good, I see yours points. Not so impressed, don't really share. The community spirit does not inspire confidence. I stay with FPC/Lazarus for some fun projects like FBProfiler (https://sourceforge.net/projects/fbprofiler/) but for "real world programs" the migration is canceled until better times. - -- Regards, Serguei -- View this message in context: http://free-pascal-general.1045716.n5.nabble.com/Bug-in-FPC-3-0-0-was-Bug-in-FPC-3-0-0-tp5724274p5724309.html Sent from the Free Pascal - General mailing list archive at Nabble.com. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)
On Wed, 24 Feb 2016, Flávio Etrusco wrote: On Wed, Feb 24, 2016 at 8:39 AM, Marco van de Voort wrote: In our previous episode, Mark Morgan Lloyd said: > (remember recent discussion about IfThen pseudo-function). More relevant to your situation, I remember discussion about adding an identifier to WITH to use as an explicit shortcut, i.e. something like with foo= bar do foo.someField := ... Not relevant since the With code in this case must remain delphi compatible. I, for one, would vote in favor making the documentation discourage the use of 'with' and adding a warning in compiler... I don't see why. I use "with" extensively. I see nothing wrong with this useful construct. The problem of the 'new identifier inserted in scope' exists, but is rare enough for me to tip the balance in favour of using "with". It has maybe happened once or twice in 25 years that I got bitten by it. I find that perfectly acceptable. For people that worry about this, the solution of Jonas should be ample to detect/avoid mistakes. Michael.___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)
On Wed, Feb 24, 2016 at 8:39 AM, Marco van de Voort wrote: > In our previous episode, Mark Morgan Lloyd said: >> > (remember recent discussion about IfThen pseudo-function). >> >> More relevant to your situation, I remember discussion about adding an >> identifier to WITH to use as an explicit shortcut, i.e. something like >> >> with foo= bar do >>foo.someField := ... > > Not relevant since the With code in this case must remain delphi compatible. I, for one, would vote in favor making the documentation discourage the use of 'with' and adding a warning in compiler... Best regards, Flávio ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)
In our previous episode, Mark Morgan Lloyd said: > > (remember recent discussion about IfThen pseudo-function). > > More relevant to your situation, I remember discussion about adding an > identifier to WITH to use as an explicit shortcut, i.e. something like > > with foo= bar do >foo.someField := ... Not relevant since the With code in this case must remain delphi compatible. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)
On Tue, 23 Feb 2016 23:58:37 +0100, Sven Barth wrote: > >What would really help here would be the warning that Jonas mentioned... >For the above you could just use a local variable and be done with it. No >need to try to "fix" the with-statement. I really fully agree! When working a few years back I had to trace through a piece of code where the original author had done something like: with My.Stuff.something do with My.Other.Stuff.somethingelse do with myyetanother do begin someproperty := xxx; end; It was totally impossible to make sense of anything while debugging! WITH should be abolished in my view! I had to make local variables to shorten down the length of the identifiers and then put the correct variable in front like: MS.someproperty := xxx; Only then was it possible to inspect the values while debugging. Further: I see every other day in the Embarcadero forum comments by Remy Lebeau where he strongly advices against using WITH. Only goes to show that it plagues Delphi as well. Join the crusade against WITH!!! -- Bo Berglund Developer in Sweden ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)
Am 23.02.2016 23:28 schrieb "Mark Morgan Lloyd" < markmll.fpc-pas...@telemetry.co.uk>: > > Serguei TARASSOV wrote: > >> There is no perfect way so why the language extension is the safest >> (remember recent discussion about IfThen pseudo-function). > > > More relevant to your situation, I remember discussion about adding an identifier to WITH to use as an explicit shortcut, i.e. something like > > with foo= bar do > foo.someField := ... > What would really help here would be the warning that Jonas mentioned... For the above you could just use a local variable and be done with it. No need to try to "fix" the with-statement. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)
Serguei TARASSOV wrote: There is no perfect way so why the language extension is the safest (remember recent discussion about IfThen pseudo-function). More relevant to your situation, I remember discussion about adding an identifier to WITH to use as an explicit shortcut, i.e. something like with foo= bar do foo.someField := ... -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)
On 23.02.2016 17:21, Serguei TARASSOV wrote: > Michael Van Canneyt wrote >> I hope you will send the same mail to embarcadero/Idera. >> When they added methods to TPoint, they broke have the VCL code ? >> >> To avoid this, we would need to freeze the code as soon as it is released. > > Compared with Unicode migration, introducing the methods into records is not > breaking :) Adding methods to the TPoint or TRect record is *exactly* like adding a method/property to TField. If you use "with" you might find yourself in a dangerous/problematic situation. That *did* happen with various code after we introduced the new methods to TPoint and TRect. > The code is not frozen but for the core level units the modifications are > rare and very risky without vast codebase and testing. > DB is a vary mature unit, almost all DACs based on it so 100% compatibility > with Delphi does matter. And the DB code is Delphi compatible. But if you (as in "general you") are using a feature that is *known* to lead to problems if fields and properties are added then that's your own problem. From great power comes great responsibility. We take backwards compatibility very serious, but there has to be a line drawn somewhere. > However, there are some useful methods to extend: > - subclassing (the safest) > - class helpers > - property/method's attributes (need to be introduced at compiler level) > - interfaces (when creating new interface for every extension) And to burden everyone else with the need to e.g. include a unit with a helper restricting them from adding their own if they don't derive from the original helper? No thank you. We are no slaves to Delphi. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)
Michael Van Canneyt wrote > I hope you will send the same mail to embarcadero/Idera. > When they added methods to TPoint, they broke have the VCL code ? > > To avoid this, we would need to freeze the code as soon as it is released. Compared with Unicode migration, introducing the methods into records is not breaking :) The code is not frozen but for the core level units the modifications are rare and very risky without vast codebase and testing. DB is a vary mature unit, almost all DACs based on it so 100% compatibility with Delphi does matter. However, there are some useful methods to extend: - subclassing (the safest) - class helpers - property/method's attributes (need to be introduced at compiler level) - interfaces (when creating new interface for every extension) I.e. adding attribute "new" to property/method the compiler will generate the error when conflicting to resolve names in existing code. There is no perfect way so why the language extension is the safest (remember recent discussion about IfThen pseudo-function). - -- Regards, Serguei -- View this message in context: http://free-pascal-general.1045716.n5.nabble.com/Bug-in-FPC-3-0-0-was-Bug-in-FPC-3-0-0-tp5724274p5724291.html Sent from the Free Pascal - General mailing list archive at Nabble.com. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)
On 2016-02-23 14:13, Mark Morgan Lloyd wrote: > And the extra typechecks etc. mean that FPC is a bit better than most > language implementations at catching things like that. Exactly. I prefer getting an error so I can fix my code and know it will work as intended - instead of the compiler silently working around the problem and possibly producing incorrect result (only noticed months down the line). Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)
Graeme Geldenhuys wrote: On 2016-02-23 10:54, Serguei TARASSOV wrote: I see, but *it's not my code*, its a code of the big third-party framework that is working well with all version of Delphi/C++ builder and Lazarus 1.x with FPC 2.6.4. Well, now it doesn't work with FPC 3.0. ;-) You cannot recommend them to change code. Why not. Many 3rd party libraries need to update there code for newer Delphi and FPC releases. This is just one of those cases. This is not ever limited to the Object Pascal language, it affects any programming language. And the extra typechecks etc. mean that FPC is a bit better than most language implementations at catching things like that. -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)
I have the latest version of Devart pgdac and virtualtable.pas compiles
fine.
On Feb 23, 2016 3:33 AM, "Serguei TARASSOV" wrote:
> Hello,
>
> Sorry, my previous example was not complete.
> Here is a problem detected when compiling UniDAC 6.2.8.
> Taken from real code in VirtualTable.pas
>
> program Project1;
>
> {$MODE DELPHI}
>
> uses
> SysUtils, Classes, DB;
>
> procedure InternalCreateFieldDefs(Fields: TFields; FieldDefs: TFieldDefs);
> var
> F: TField;
> FieldDef: TFieldDef;
> begin
> begin
> with F do
> begin
> FieldDef := FieldDefs.AddFieldDef;
> // in FPC 3.0.0 Error: No member is provided to access property
> // in FPC 2.6.4 compiles OK
> end;
> end;
> end;
>
> begin
> end.
>
>
>
>
> -
> --
> Regards,
> Serguei
> --
> View this message in context:
> http://free-pascal-general.1045716.n5.nabble.com/Bug-in-FPC-3-0-0-was-Bug-in-FPC-3-0-0-tp5724274.html
> Sent from the Free Pascal - General mailing list archive at Nabble.com.
> ___
> 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] Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)
Henry Vermaak wrote on Tue, 23 Feb 2016: On Tue, Feb 23, 2016 at 02:13:52PM +0100, Jonas Maebe wrote: It would probably be useful if we added support to the compiler to generate a warning (or even error) in case a with statement hides an existing symbol in scope though. Yes, please. Something like -Wshadow would be very useful. That already exists and is enabled by default for local variables and parameter names hiding fields. It even gives errors in FPC and ObjFPC modes, rather than warnings. It's just not (yet) implemented for with-statements (and local variables or fields hiding global variables, but that's a different matter). Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)
On Tue, Feb 23, 2016 at 02:13:52PM +0100, Jonas Maebe wrote: > It would probably be useful if we added support to the compiler to > generate a warning (or even error) in case a with statement hides an > existing symbol in scope though. Yes, please. Something like -Wshadow would be very useful. Henry ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)
On Tue, 23 Feb 2016, Serguei TARASSOV wrote: Okay, okay, I see. For info, the indicated error is not critical because of its visibility at compile-time. All other codes inside "with" statement like x := FieldDef; will be compiled without errors and should be checked. Thank you, guys, for a good compatibility support and adding the features to the principal units that break the existing code of "real world programs". I hope you will send the same mail to embarcadero/Idera. When they added methods to TPoint, they broke have the VCL code ? To avoid this, we would need to freeze the code as soon as it is released. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)
Serguei TARASSOV wrote on Tue, 23 Feb 2016: Thank you, guys, for a good compatibility support Come on. The only way this kind of problems can be avoided is by us never adding any new field or property to any class, ever. It would probably be useful if we added support to the compiler to generate a warning (or even error) in case a with statement hides an existing symbol in scope though. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)
Okay, okay, I see. For info, the indicated error is not critical because of its visibility at compile-time. All other codes inside "with" statement like x := FieldDef; will be compiled without errors and should be checked. Thank you, guys, for a good compatibility support and adding the features to the principal units that break the existing code of "real world programs". - -- Regards, Serguei -- View this message in context: http://free-pascal-general.1045716.n5.nabble.com/Bug-in-FPC-3-0-0-was-Bug-in-FPC-3-0-0-tp5724274p5724281.html Sent from the Free Pascal - General mailing list archive at Nabble.com. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)
On Tue, 23 Feb 2016, Graeme Geldenhuys wrote: On 2016-02-23 10:54, Serguei TARASSOV wrote: I see, but *it's not my code*, its a code of the big third-party framework that is working well with all version of Delphi/C++ builder and Lazarus 1.x with FPC 2.6.4. Well, now it doesn't work with FPC 3.0. ;-) You cannot recommend them to change code. Why not. Many 3rd party libraries need to update there code for newer Delphi and FPC releases. This is just one of those cases. This is not ever limited to the Object Pascal language, it affects any programming language. Exactly. See e.g. the recent changes in TPoint, which necessitated a lot of changes in the LCL, because "with" was used a lot. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)
On 2016-02-23 10:54, Serguei TARASSOV wrote: > I see, but *it's not my code*, its a code of the big third-party framework > that is working well with all version of Delphi/C++ builder and Lazarus 1.x > with FPC 2.6.4. Well, now it doesn't work with FPC 3.0. ;-) > You cannot recommend them to change code. Why not. Many 3rd party libraries need to update there code for newer Delphi and FPC releases. This is just one of those cases. This is not ever limited to the Object Pascal language, it affects any programming language. Plus, it's another excellent example of why you shouldn't use WITH. I don't care how many disagree with me, I always thought it a bad language design. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)
On Tue, 23 Feb 2016, Serguei TARASSOV wrote: Michael Van Canneyt wrote The problem is in your code and the use of WITH, as I surmised in my previous mail. In 2.6.4, FieldDef is resolved to the LOCAL VARIABLE FieldDef. The code compiles ok. In 3.0.0, FieldDef is a NEW READ-ONLY property in TField. Because of the WITH, the compiler resolves FieldDef to this property, but it is read-only, an so it gives an error. I see, but *it's not my code*, its a code of the big third-party framework that is working well with all version of Delphi/C++ builder and Lazarus 1.x with FPC 2.6.4. You cannot recommend them to change code. If course I can, I just did. The mode Delphi is declared. The mode is entirely irrelevant. It should be compatible. We introduced the FieldDef property in TField. This was a conscious decision. They chose to use "with", and then this kind of thing can happen at any point. So, they must adapt their code. Don't use "with" if you're not prepared to deal with such issues. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)
Michael Van Canneyt wrote > The problem is in your code and the use of WITH, as I surmised in my > previous mail. > > In 2.6.4, FieldDef is resolved to the LOCAL VARIABLE FieldDef. > The code compiles ok. > > In 3.0.0, FieldDef is a NEW READ-ONLY property in TField. > Because of the WITH, the compiler resolves FieldDef to this property, but > it > is read-only, an so it gives an error. I see, but *it's not my code*, its a code of the big third-party framework that is working well with all version of Delphi/C++ builder and Lazarus 1.x with FPC 2.6.4. You cannot recommend them to change code. There are many other errors during compile, if someone is interesting I can provide the list. So the problem is in DB unit. The mode Delphi is declared. It should be compatible. - -- Regards, Serguei -- View this message in context: http://free-pascal-general.1045716.n5.nabble.com/Bug-in-FPC-3-0-0-was-Bug-in-FPC-3-0-0-tp5724274p5724276.html Sent from the Free Pascal - General mailing list archive at Nabble.com. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)
On Tue, 23 Feb 2016, Serguei TARASSOV wrote:
Hello,
Sorry, my previous example was not complete.
Here is a problem detected when compiling UniDAC 6.2.8.
Taken from real code in VirtualTable.pas
program Project1;
{$MODE DELPHI}
uses
SysUtils, Classes, DB;
procedure InternalCreateFieldDefs(Fields: TFields; FieldDefs: TFieldDefs);
var
F: TField;
FieldDef: TFieldDef;
begin
begin
with F do
begin
FieldDef := FieldDefs.AddFieldDef;
// in FPC 3.0.0 Error: No member is provided to access property
// in FPC 2.6.4 compiles OK
The problem is in your code and the use of WITH, as I surmised in my
previous mail.
In 2.6.4, FieldDef is resolved to the LOCAL VARIABLE FieldDef.
The code compiles ok.
In 3.0.0, FieldDef is a NEW READ-ONLY property in TField.
Because of the WITH, the compiler resolves FieldDef to this property, but it
is read-only, an so it gives an error.
Change your code to
Var
AFieldDef: TFieldDef;
and
AFieldDef := FieldDefs.AddFieldDef;
and all will be well.
Michael.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)
Hello,
Sorry, my previous example was not complete.
Here is a problem detected when compiling UniDAC 6.2.8.
Taken from real code in VirtualTable.pas
program Project1;
{$MODE DELPHI}
uses
SysUtils, Classes, DB;
procedure InternalCreateFieldDefs(Fields: TFields; FieldDefs: TFieldDefs);
var
F: TField;
FieldDef: TFieldDef;
begin
begin
with F do
begin
FieldDef := FieldDefs.AddFieldDef;
// in FPC 3.0.0 Error: No member is provided to access property
// in FPC 2.6.4 compiles OK
end;
end;
end;
begin
end.
-
--
Regards,
Serguei
--
View this message in context:
http://free-pascal-general.1045716.n5.nabble.com/Bug-in-FPC-3-0-0-was-Bug-in-FPC-3-0-0-tp5724274.html
Sent from the Free Pascal - General mailing list archive at Nabble.com.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
