Free Pascal Compiler 2.4.0 Released!

[marcov]

We have placed a new major release of the Free Pascal Compiler,
version 2.4.0 on our ftp-servers.

Changes that may break backwards compatibility are documented at:
http://wiki.freepascal.org/User_Changes_2.4.0

Downloads are available at:

the main FTP server at

ftp://ftp.freepascal.org/pub/fpc/dist/2.4.0/

and

ftp://freepascal.stack.nl/pub/fpc/dist/2.4.0/

Enjoy!

The Free Pascal Compiler Team



                            Free Pascal Compiler

                                Version 2.4.0

******************************************************************************
                              What's New in 2.4.0
******************************************************************************

Free Pascal 2.4.0 contains many fixes and new features. While we did not
manage to incorporate all planned additions, we believe this release offers a
nice collection of new functionality and bug fixes.


Please also see http://wiki.freepascal.org/User_Changes_2.4.0 for a list
of changes which may affect the behaviour of previously working code, and
how to cope with these changes.

Some highlights are:

Platforms:
  * New platform: Mac OS X/PowerPC64
  * New platform: Mac OS X/x86_64
  * New platform: Mac OS X/ARM (iPhone)
  * New platform: Haiku/i386

Compiler:
  * Support for Delphi-style resource handling
  * Whole-program optimization infrastructure, which initially supports
    program devirtualization and unused virtual method removal
  * Much faster compilation of units containing many type-sections
  * The ability to suppress individual hints/warnings/notes
  * Several improvements to the DWARF debug information generation
  * Fixes to the generics support
  * Fixes to the interface delegation (implements) support
  * Improved cpu register allocation
  * Improved ARM/EABI support
  
RTL:
  * Linearly scaling multi-threaded memory manager
  * Support for (advisory) file locking on Unix-based platforms
    when using the SysUtils file creation/opening routines
  * Support for ANSI ISO Extended Pascal ReadStr/WriteStr
  * A UnicodeString type that, while not yet equivalent to Delphi 2009's
    UnicodeString type, offers reference counted UnicodeString support on
    the Windows, Linux, Mac OS X, FreeBSD and Beos/Haiku platforms.

Packages:
  * Many improvements to the XML units
  * Many improvements to the database units
  * Updated the common Mac OS X Pascal interfaces to r241, including
    header a translation of the CFNetwork framework
  * The zipper unit now works correctly on big endian platforms

See http://bugs.freepascal.org/changelog_page.php for the list of reported
bugs which have been fixed in this release.

[alter]

I've noticed that there are no provided binaries for arm-linux. Do you plan to add them at some point or is there some issue with that?

[stocki]

Hi,
under ftp://ftp.freepascal.org/pub/lazarus we have following versions:

2.2.4
2.3.1
2.4.0
2.4.1
2.5.1

Would you please explain what all these version are for?
Why 2.2.4 & 2.3.1 ??? I think, not needed anymore.
Why 2.4.0 and 2.4.1. ????
Why 2.5.1 ???

[marcov]

Hi,
under ftp://ftp.freepascal.org/pub/lazarus we have following versions:

2.2.4
2.3.1
2.4.0
2.4.1
2.5.1

Would you please explain what all these version are for?
Why 2.2.4 & 2.3.1 ??? I think, not needed anymore.
Why 2.4.0 and 2.4.1. ????
Why 2.5.1 ???

The versioning scheme is explained in the buildfaq.

Since some Linux distro's are notorious slow in updating (specially debian based ones), and older distro's are often not updated at all, 2.2.4 support in lazarus is still needed for a while.

2.3.1 and 2.4.1 are essentially the same. 2.3.1 can be removed now 2.4.0 is out.  2.4.1 is post 2.4.0 development

[stocki]

...and 2.5.1 ???

[anta40]

...and 2.5.1 ???

the 2.5.1 has some new features, like the for-in loop

i like that

[Vincent Snijders]

I am the process of changing the fpc versions used by the Lazarus snapshots:
Release 2.2.4 -> 2.4.0
Fixes 2.3.1 -> 2.4.1

If everything (all platforms) work ok, I will remove 2.2.4 and 2.3.1 versions.

[masonwheeler]

Very nice, mostly.  Though I was quite disappointed by one of the changes in part 2.2.2 on the wiki.

Old behaviour: The compiler allowed treating properties that directly read and write a field (as opposed to redirecting via a getter/setter) as direct references to this field. This means that you could pass such properties to var and out parameters, that you could take their address, that you could assign values to subscripted properties with non-pointer result types (see example //2 below), and that you could assign values to typecasted properties.
New behaviour: All properties are now treated equal, regardless of whether they directly map to a field or use a getter/setter.

While I can understand wanting to fix some of this, especially for increased Delphi compatibility, taking away the ability to pass properties to a var or out parameter was the wrong thing to do.  Delphi has it wrong and it's not good to blindly follow them when they make mistakes.

Properties are an encapsulation of fields.  They let the programmer treat an object as if it had public fields without the safety and maintenance problems of actually giving it public fields, and by incorporating read and write values separately, which can point to fields or methods, it gives you a lot more fine control than simply using fields.  It's a very nice and very useful abstraction, right up to the point where the abstraction leaks, and that point is var parameters.

If a property is supposed to look like a field, act like a field and quack like a field, then there is no good reason why you should ever be unable to pass a property with both read and write access to a var parameter.  If they both point to the same internal field, then it's a trivial operation.  Otherwise, the compiler should retrieve the read value into a temporary variable on the stack, pass it to the function, and then after the call returns send its result to the write value specified for the property.  I have no idea why Delphi doesn't do it this way, but it's the right way to do it and FPC ought to take the initiative even if Delphi won't.

[eny]

Old behaviour: The compiler allowed treating properties that directly read and write a field (as opposed to redirecting via a getter/setter) as direct references to this field. This means that you could pass such properties to var and out parameters...

Hey, I've learned something today; I didn't know that 

Properties are an encapsulation of fields

I would say they are an encapsulation of data: you can get data from an object in a certain format or you can offer data in a certain format. The keyword is encapsulation: the object/class is responsible for handling the data correctly. And if that data is stored in a field (which is often the case, I agree) or processed and stored in some sort of internal format, is hidden from the user of the class. The only thing that is known is the 'interface', i.e. the defined properties with their names and types. Making assumptions about the internal structure and building code based on that would violate the encapsulation and possibly create future maintenance problems.

But: I'd have to agree that if it worked in the past as you described, it should be regarded as a bug if it doesn't work like that anymore. Backwards compatibility is broken!
(Maybe a new compiler flag could be introduced for backwards compatibility...)

[Jonas Maebe]

If a property is supposed to look like a field, act like a field and quack like a field, then there is no good reason why you should ever be unable to pass a property with both read and write access to a var parameter.  If they both point to the same internal field, then it's a trivial operation.  Otherwise, the compiler should retrieve the read value into a temporary variable on the stack, pass it to the function, and then after the call returns send its result to the write value specified for the property.  I have no idea why Delphi doesn't do it this way

The reason is that such a copy/copy back approach has different behaviour than call-by-reference under certain circumstances, because the change to the parameter is only visible outside the procedure after it returns.

Simple example:

Code: [Select]

type
  tc = class
   private
    fl: longint;
   protected
    procedure setl(value: longint);
    function getl: longint;
  public
    property l: read getl write setl;
    procedure doit(var a: longint);
    procedure helper;
  end;

procedure tc.doit(var a: longint);
  begin
    a:=5;
    helper;
  end;

procedure tc.helper;
  begin
    writeln(l);
  end;

...
var
  c: tc;
begin
  c:=tc.create;
  c.l:=10;
  c.doit(c.l);
end.

(this is a contrived example, but in complex programs similar constructions can easily occur).

In case of call-by-reference (e.g., if the property would directly map to the field), tc.helper will write out 5. In case of copy/copy-back, tc.helper writes out 10 (because the 5 hasn't been copied back to the field yet).

[Jonas Maebe]

But: I'd have to agree that if it worked in the past as you described, it should be regarded as a bug if it doesn't work like that anymore. Backwards compatibility is broken!

The whole point of the User Changes page is to document where backwards compatibility has been broken. Such things happen with every release, but we realise that is annoying, which is why
a) they are all explicitly documented along with an explanation why this happened and how to deal with it
b) the major ones (such as this one) are only incorporated in new major releases (this change was already made in svn trunk before FPC 2.2.4 was released, but it was not included in 2.2.4 because such fixes releases are not supposed to require potentially invasive code changes)

(Maybe a new compiler flag could be introduced for backwards compatibility...)

The compiler is complex enough to maintain as it is. Adding flags to emulate bugs in older versions is simply not doable (and note that older versions also allowed passing properties to var parameters where the "read" specified mapped directly to the field, but the "write" specified mapped to a method).

If someone else wants to create and maintain a fork of FPC 2.2.4 with only those changes from 2.4.0 that do not affect backward compatibility, they are of course free to do so.

[eny]

I understand where the changes are coming from and I appreciate all the hard work.
I really like FPC (I've worked with Turbo Pascal 3.0 many years ago ) and am a big fan of Lazarus.

It's just that all these changes don't help the FPC/Lazarus adaptation process: today it's a change in FPC, tomorrow it's a change in the VTV package, after that it's changes in the Lazarus LCL etc.
Well, maybe that's a fact of (GxL'd software) life we'll have to (learn to) live with 

[Jonas Maebe]

It's just that all these changes don't help the FPC/Lazarus adaptation process: today it's a change in FPC, tomorrow it's a change in the VTV package, after that it's changes in the Lazarus LCL etc.

I understand that, but I really don't see an alternative...

[masonwheeler]

(this is a contrived example, but in complex programs similar constructions can easily occur).

Really?  I don't think I've ever seen something like that happening in real-world code.  A function shouldn't be trying to modify a direct reference to a variable it's receiving as a parameter.  (Or, depending on how you look at it, a user shouldn't go passing something as a parameter to a method that the method already has a direct reference to.)  Where have you seen something like that happen?

[Troodon]

A function shouldn't be trying to modify a direct reference to a variable it's receiving as a parameter.

Why not? I do that all the time (haven't looked at the code,though).