Upgrading to Lazarus 1.0.7 with FPC 2.6.2 raised this error in a file I was compiling? What does it mean?

procedure TRxDBGrid.CheckNewCachedSizes(var AGCache: TGridDataCache);
begin
  if (rdgFooterRows in OptionsRx) and (FooterRowCount > 0) then
    Dec(GCache.ClientHeight, DefaultRowHeight * FooterRowCount + 2);
end;
M:\Lazarus\ThirdPartyLibs\rx20\rxdbgrid.pas(2492,9) Error: Can't take
the address of constant expressions

Is the fixes branch supposed to introduce new functionality that can break code that compiled in previous releases? I thought it excludes changes that break existing code, ie, it should fix buggy code generation, but not introduce changes that break existing code?

2013/3/13 Frank Church :

What fixes branch are you talking about? FPC 2.6 fixes or Lazarus 1.0 fixes?

Anyway, if you exploited a bug, then a fix for that bug might break your code.

Vincent

Is GCache.ClientHeight a property? If so, this was not changed in 2.6.0, but IIRC in the 2.4 series.
You can't pass a property in a 'var' parameter.

-Fl?vio

FPC 2.6 fixes, that code has been compiling since 2.2.4. Perhaps it is a bug which has been waiting to be caught.

Frank Church wrote

Is the fixes branch supposed to introduce new functionality that can break code that compiled in previous releases?

For FPC yes that is the case. As Flavio stated. You can't pass a property as a var parameter any more. Annoying, but I the FPC devel had good reason as far as I know. Can't remember the exact explanation.

Anyway, you have to change your code to the following.

  GCache.ClientHeight := GCache.ClientHeight - (DefaultRowHeight *
FooterRowCount + 2);

I also believe the new FPC changes also means that with properties you also can't use the short *= += -= etc syntax, which I loved to use. The above would have been written as

  GCache.ClientHeight -= (DefaultRowHeight * FooterRowCount + 2);

Regards,
- Graeme -

[...] What fixes branch are you talking about? FPC 2.6 fixes or Lazarus 1.0 fixes?

In the next release we should mention that it uses a newer compiler, which includes many bug fixes, but contains a few incompatibilities too and include a link to the fpc 2.6.2 changes.

Mattias

It's already this way in 2.6.0:
http://wiki.lazarus.freepascal.org/User_Changes_2.6.0#Taking_the_address_of_fields_of_record_properties

Regards,
Sven

Yes, but 2.6.2 contains a few incompatibilities as well and Frank is right that a 1.0.8 release is meant as a bug fix release, so it should not contain incompatibilities.

Mattias

Graeme Geldenhuys wrote

Anyway, you have to change your code to the following. GCache.ClientHeight := GCache.ClientHeight - (DefaultRowHeight * FooterRowCount + 2);

... which is sort of more readable than Dec() construct Frank was using, (but it is IMO&TMV only) ...

and this is indeed surprising (but since operator overloads are functions, and first one to this operator needs to be 'var', then I guess, not really) (what if the operator function was 'inline' if we have such a keyword?)

Regards, - Graeme -

L.

[personal opinion]
I agree fully. I don't really like Dec(), Prev() etc methods.

and this is indeed surprising (but since operator overloads are functions, and first one to this operator needs to be 'var', then I guess, not really)

Is that C-style operators (compiler parameter -Sc) translated to Free Pascal operator overloads?

(what if the operator function was 'inline' if we have such a keyword?)

No idea. Better try it and find out. :)

Regards,
- Graeme -

Is the error message the result of a bug in the implementation of FPC 2.6.0 or earlier versions (according to the specifications) which got fixed, or the result of new specifications which were backported to the 2.6 series?

Functions like Dec, Succ, Inc have a role because they may reflect the domain better. For instance if you are iterating over an array where elements are referenced by an integers, +1, +2 etc give the impression your program involves number arithmetic, where as Next and Prev, or even Another means your function is iterating over an as yet unprocessed element of your set. The fact that the element accessing constructs map onto numbers is wholly incidental.

Frank Church wrote

domain better. For instance if you are iterating over an array where elements are referenced by an integers, +1, +2 etc give the impression your program involves number arithmetic, where as Next and Prev, or

And why I created and use an Iterator unit, which defines a standard "iterator interface" for many data types. A factory method will return the correct iterator interface to me. That way my code looks consistent no matter what data I iterate. I also have more control (HasNext, HasPrev, Next, Prev, Reset, Skip etc), and I can even iterate certain data using regex, so only regex matches are returned.

Still doesn't change my mind about Inc(), Dec(), Pred(), Succ() etc. As I said, my personal opinion, and I think they make reading code harder. Your mileage my vary.

Regards,
- Graeme -

As I already wrote in another mail: this fix was introduced in 2.6.0 as you can see here:
http://wiki.lazarus.freepascal.org/User_Changes_2.6.0#Taking_the_address_of_fields_of_record_properties

Regards,
Sven

Huh? Operator overloads in FPC don't use "var" at all. Either you have a unary operator like "not", "inc" or ":=" then you have one parameter and one result or you have a binary operator like "+", "and", ">=" then you have two parameters and one result.

(what if the operator function was 'inline' if we have such a keyword?)

If an operator has an inline modifier then its code will be inlined if nothing (from the compiler's perspective) speaks against it (overloaded operators are simply converted to function calls).

Regards,
Sven

OP (and Graeme) talked about c-style binary operators... -=, +=, and so on.

Would this mean you can't do

Object.Property -= Something;
without the inline?

?

Regards, Sven

L.

That's a sliding slope. Strictly speaking, a new version of the compiler that predefines just one extra symbol (e.g. due to a new architectural issue) would then not be acceptable since an user could already use the symbol in its own code.

Things are not black and white. If there are incompatibilities, they are mostly there for a reason.

Yes, that's why 2.6.2 was used for 1.0.8. The incompatibilities are minor compared to the many bug fixes.
I just meant, that the release must note it prominently.

Mattias