Tiburón is the codename for the next version of Delphi for Win32 IDE. The official name will most likely be Delphi 2009. It is due in the first half of 2008.
Main improvements include:
- Delphi Win32 Unicode: The IDE and the VCL.
- Parameterized Types for both managed and native Delphi development.
- Updated and improved VCL.
- A directive that allows to overindex other pointer types like pchar. So one can also do p[x] if p is and pinteger. (like in e.g. native FPC modes)
- Anonymous functions (the ISO function pointer that Borland always refused to implement now finally makes it in as a .NET me-too'ism)
- I've not seen an explicite confirmation that Tiburón contains the .NET parts. The direct question to Nick Hodges seems to indicate that .NET features will be absent.
- Nick Hodges (see links) confirmed the BCB personality.
- language change: exit in a function can now return a value like in FPC:
function DoSomething(aInteger: integer): string; begin if aInteger < 0 then begin Exit(‘Negative’); end; Result := ‘Positive’; end; function DoSomething(aInteger: integer): string; begin if aInteger < 0 then begin Result := ‘Negative’; Exit; end; Result := ‘Positive’; end;
Unicode changes Edit
(distilled from some borland.delphi.non-tech discussions and blog posts:)
- "string" will become a native UTF16 string (like Kylix widestring, Windows widestring remains as COM type).
- 8-bit char code can be _roughly_ fixed by changing all "string" occurances to ansistring
- corner cases not known yet:
- Will strings as buffer use remain working
- auto conversion of assumptions on string literals in extended ansi encodings
- Will c:=s[x]; yield a 32-bit or 16-bit char ?
- Ansistrings are expanded and can be declared with their codepage. UTF-8 is considered a codepage.
- ansistring in different codepages will automatically get converted (over UTF-16). Possibly lossy if the target codepage doesn't support certain input-chars.
- A "rawbytes" ansistring will not autoconvert, and its contents will be copied.
Reading the description of the ansistring modifications, the new functionality looks more like a one way street (process ansi, convert to unicode ASAP) then as a platform to do reliable general purposes string processing. (because a small mistake that is not very visible due to automatic conversions, and you lose data due to the fact that conversions can be lossy).
Of course, this goes for the "mixed codepages all over the place" case. If you generally just use the default ansistring, or the UTF-8 variant, and keep your codepage related code on fringes of your system (input/output files in certain codepages) you are relatively safe from that.
- Delphi and C++Builder Roadmap
- Blog about ansistring modifications
- Anonymous methods
- Delphi 2007 for Win32
- Nick Hodges about personalities in Tiburon
|Win32||Delphi 2 • Delphi 3 • Delphi 4 • Delphi 5 • Delphi 6 • Delphi 7 • Delphi 2007 for Win32|
|Win32 + .NET:||Borland Developer Studio 2005 • Borland Developer Studio 2006 • CodeGear RAD Studio 2007 • CodeGear RAD Studio 2009|
|Other:||Kylix • Delphi for PHP • 3rdRail • Turbo Delphi 2006|
|More info:||Release Dates and Codenames • Compiler Release Dates • Compiler Conditional Defines|