Difference between revisions of "User Changes Trunk"

From Free Pascal wiki
(Language Changes)
m (Added "Remedy" section for FileNameCaseSensitive/FileNameCasePreserving)
Line 11: Line 11:
 
* '''New behaviour''': FileNameCaseSensitive is set to true only on platforms which really treat filenames in case sensitive manner and FileNameCasePreserving constant is added to unit system of all platforms to signalize whether the case in filenames supplied when creating or renaming them is preserved or not. This might possibly break existing user code relying on the previous (sometimes incorrect) value of FileNameCaseSensitive.
 
* '''New behaviour''': FileNameCaseSensitive is set to true only on platforms which really treat filenames in case sensitive manner and FileNameCasePreserving constant is added to unit system of all platforms to signalize whether the case in filenames supplied when creating or renaming them is preserved or not. This might possibly break existing user code relying on the previous (sometimes incorrect) value of FileNameCaseSensitive.
 
* '''Reason''': In reality, there are two distinct types of behaviour. If a platform is case sensitive, searching for file "a" will never result in finding file "A" whereas case insensitive platform will happily return "A" if such a file is found on the disk. If a platform is case preserving, it will store file "a" as "a" on disk whereas case non-preserving platform may convert the filenames to uppercase before storing them on disk (i.e. file "a" is in reality stored as "A"). Case non-preserving platforms are never case sensitive, but case preserving platforms may or may not be case sensitive at the same time.
 
* '''Reason''': In reality, there are two distinct types of behaviour. If a platform is case sensitive, searching for file "a" will never result in finding file "A" whereas case insensitive platform will happily return "A" if such a file is found on the disk. If a platform is case preserving, it will store file "a" as "a" on disk whereas case non-preserving platform may convert the filenames to uppercase before storing them on disk (i.e. file "a" is in reality stored as "A"). Case non-preserving platforms are never case sensitive, but case preserving platforms may or may not be case sensitive at the same time.
 +
* '''Remedy''': Review your existing code using FileNameCaseSensitive, check which of the two properties described above fit the particular purpose in your case and change to FileNameCasePreserving where appropriate.
  
 
==== Several methods of TDataset changes signature (TRecordBuffer) ====
 
==== Several methods of TDataset changes signature (TRecordBuffer) ====

Revision as of 11:19, 19 April 2012

About this page

Below you can find a list of intentional changes since the previous release that can change the behaviour of previously working code, along with why these changes were performed and how you can adapt your code if you are affected by them. The list of new features can be found here.

All systems

Unit changes

FileNameCaseSensitive and FileNameCasePreserving in unit System

  • Old behaviour: There was only one constant (FileNameCaseSensitive) which signalized behaviour of the respective target platform with regard to the case in filenames. This was often set to true also on platforms not really treating filenames in case sensitive manner (e.g. Win32 and Win64).
  • New behaviour: FileNameCaseSensitive is set to true only on platforms which really treat filenames in case sensitive manner and FileNameCasePreserving constant is added to unit system of all platforms to signalize whether the case in filenames supplied when creating or renaming them is preserved or not. This might possibly break existing user code relying on the previous (sometimes incorrect) value of FileNameCaseSensitive.
  • Reason: In reality, there are two distinct types of behaviour. If a platform is case sensitive, searching for file "a" will never result in finding file "A" whereas case insensitive platform will happily return "A" if such a file is found on the disk. If a platform is case preserving, it will store file "a" as "a" on disk whereas case non-preserving platform may convert the filenames to uppercase before storing them on disk (i.e. file "a" is in reality stored as "A"). Case non-preserving platforms are never case sensitive, but case preserving platforms may or may not be case sensitive at the same time.
  • Remedy: Review your existing code using FileNameCaseSensitive, check which of the two properties described above fit the particular purpose in your case and change to FileNameCasePreserving where appropriate.

Several methods of TDataset changes signature (TRecordBuffer)

  • Old behaviour: Several (virtual) methods of TDataset have parameters of type "pchar", which are often called "buffer".
  • New behaviour: The pchar type has been changed to TRecordBuffer. Currently this type is still an alias for p(ansi)char, but in time it will be changed to pbyte for the 2.7.1/2.8.0 branch, which is D2009+ compatible.
  • Reason: Preparation for Delphi 2009+ compatibility and improving of general typing. In Delphi 2009+ (and fully compatible FPC modes in the future) pchar is not pointer to byte anymore. This change will be merged back to 2.6(.2), but with TRecordBuffer=pchar.
  • Remedy: Change the relevant virtual methods to use TRecordBuffer for buffer parameters. Define TRecordBuffer=pansichar to keep older Delphis and FPCs working.

DLLParam changed from Longint into PtrInt

  • Old behaviour: DLLParam was of type Longint even on Win64.
  • New behaviour: DLLParam is now of type PtrInt so also on 64 Bit systems.
  • Reason: Prevent data loss, match the declaration in the Windows headers.
  • Remedy: Change the declaration of the procedures used as dll hook to take a PtrInt parameter instead of Longint.

Language Changes

Anonymous inherited calls

  • Old behaviour: An anonymous inherited call could call through to any method in a parent class that accepted arguments compatible to the parameters of the current method.
  • New behaviour: An anonymous inherited call is guaranteed to always call through to the method in a parent class that was overridden by the current one.
  • Example: See http://svn.freepascal.org/svn/fpc/trunk/tests/tbs/tb0577.pp. In previous FPC versions, the inherited call in tc3.test would call through to tc2.test(b: byte; l: longint = 1234);. Now it calls through to tc.test.
  • Reason: Conform to the FPC documentation, Delphi-compatibility.
  • Remedy: If you wish the compiler to decide which method to call based on the specified parameters, use a fully specified inherited call expression such as inherited test(b).

Overload modifier must be present in the interface

  • Old behaviour: It was possible to declare a function/procedure/method as overload only in the implementation.
  • New behaviour: If an overload directive is used, it must also appear in the interface.
  • Reason: The old mechanism could cause hard to find problems (depending on whether or not the implementation was already parsed, the compiler would treat the routine as if it were declared with/without overload), it could cause unwanted unit recompilations due to interface crc changes, and Delphi compatibility.
  • Remedy: Make sure that the overload modifier is present both in the interface and in the implementation if you use it.

Variant overload preference for string types

  • Old behaviour: Preference for string types was (from better to worse): ShortString, AnsiString, WideString, UnicodeString
  • New behaviour: Preference for string types now (from better to worse): WideString, UnicodeString, AnsiString, ShortString
  • Reason: Unicode characters and codepage information will not lose during the conversion and unicode Delphi compatibility.
  • Remedy: Use explicit conversion (e.g. ShortString(V)) if it is needed to pass variant to routine with paticular string type argument.

See also