Book: Delphi Quick Syntax Reference

[John Kouraklis 94]

Hi all,

 

I'd like to share that my new book is almost out. Apress is working hard to put it in the market.

 

We always discuss how we can bring new people to Delphi so I thought it would be a good idea to ease their way in by providing a quick up-to-date guide on the basics of the language. The book covers new features introduced in 10.4

 

Of course, a reference book is always useful to experienced coders as well; we all need a refresher every now and then 🙂

 

I would like to cordially thank Dr. Holger Flick for reviewing the chapters; his experienced view guided me during the writing of the book.

 

 

Regards,

 

John

 

 

 

9781484261118.tif

[John Kouraklis 94]

I can't insert an image in the post now. So here's a link  https://www.amazon.co.uk/Delphi-Quick-Syntax-Reference-Language/dp/1484261119

Edited July 17, 2020 by John Kouraklis

[Guest]

Congratulations, wish you success.

[dummzeuch 1505]

Does it also cover when (which Delphi version) a particular syntax extension was introduced?

[Anders Melander 1783]

3 hours ago, dummzeuch said:

Does it also cover when (which Delphi version) a particular syntax extension was introduced?

I'm curious; Why would you need that information?

[John Kouraklis 94]

4 hours ago, dummzeuch said:

Does it also cover when (which Delphi version) a particular syntax extension was introduced?

Apart from the additions in 10.3 and 10.4 I found very difficult to track down and verify this information and then to present everything in a concise way. And I am not sure a newcomer would really find this useful.

 

Perhaps if you write components and need to cover old versions this would be useful but I feel this is a bit out of the scope of the book.

[dummzeuch 1505]

9 hours ago, Anders Melander said:

I'm curious; Why would you need that information?

Simple Curiosity. Also, sometimes it would be helpful when targeting multiple Delphi versions without having them around to check whether the code compiles.

[dummzeuch 1505]

8 hours ago, John Kouraklis said:

Apart from the additions in 10.3 and 10.4 I found very difficult to track down and verify this information and then to present everything in a concise way. And I am not sure a newcomer would really find this useful.

Just asking. Yes, for a newcomer this wouldn't be of much use unless he takes on a job where he has to use older Delphi versions (employer's requirement). With this information he has a chance to decide whether he really wants to work under these restrictions.

[Fr0sT.Brutal 900]

On 7/17/2020 at 7:26 PM, dummzeuch said:

Does it also cover when (which Delphi version) a particular syntax extension was introduced?

I gathered most valuable ones of them in https://github.com/Fr0sT-Brutal/Delphi_Compilers (intended for library devs that have to support many compiler versions)

Edited July 24, 2020 by Fr0sT.Brutal

[Mahdi Safsafi 225]

1 hour ago, Fr0sT.Brutal said:

I gathered most valuable ones of them in https://github.com/Fr0sT-Brutal/Delphi_Compilers (intended for library devs that have to support many compiler versions)

Why the heck im not aware about this?

Looks good but is it always up to date? I mean the last change made was on 2019.

Please consider maintaining it... We really need such project. 

[Fr0sT.Brutal 900]

2 minutes ago, Mahdi Safsafi said:

Why the heck im not aware about this?

Looks good but is it always up to date? I mean the last change made was on 2019.

Please consider maintaining it... We really need such project. 

It could be not so much up to date but I keep adding stuff from time to time. Luckily not much things change at language level.

Anybody is always welcomed to do pull request or fill an issue; I'll try to update the list to 10.4 in the near future

[Bill Meyer 337]

7 hours ago, Fr0sT.Brutal said:

I gathered most valuable ones of them in https://github.com/Fr0sT-Brutal/Delphi_Compilers (intended for library devs that have to support many compiler versions)

One of the best things I have seen online in a long time.

[Guest]

9 hours ago, Fr0sT.Brutal said:

I gathered most valuable ones of them in https://github.com/Fr0sT-Brutal/Delphi_Compilers (intended for library devs that have to support many compiler versions)

Brilliant!!

[igors 0]

Agree, I wish EMB incorporate it to Delphi.

[Uwe Raabe 2057]

1 hour ago, igors said:

Agree, I wish EMB incorporate it to Delphi.

How would this affect older Delphi versions, which are the relevant targets according to "(intended for library devs that have to support many compiler versions)"?

 

The problem is, that you need to use always the latest version of this file as part of your library, so it is capable to handle all Delphi versions.

 

Even if starting with 10.5 Delphi would provide such a file itself, it will be outdated as soon as 10.6 arrives. So you have to use the newer file even for older Delphi versions, which somehow rules out such a file coming with Delphi itself.

[Anders Melander 1783]

On 7/24/2020 at 10:11 AM, Fr0sT.Brutal said:

I gathered most valuable ones of them in ...

Spotted a copy/paste bug in CompilersDecl.inc :

const
  RAD_Rio     = 32; RAD_10_3 = 33;
  RAD_Tokyo   = 32; RAD_10_2 = 32

 

6 minutes ago, Uwe Raabe said:

Even if starting with 10.5 Delphi would provide such a file itself, it will be outdated as soon as 10.6 arrives.

Of course it can't detect capabilities that were introduced after it was written but if you are using those then you must be already using a newer version of Delphi and thus be aware that you need to update the file.

I guess it depends on how and what you use it for. Contrary to many other similar version include files this one appears to be forward compatible if you use the capability or XXX_UP symbols; For example even though it doesn't explicitly contain defines for Delphi 10.4 it will define the RAD_10_3_UP correctly on Delphi 10.3 and later:

{$IF CompilerVersion >= 33}
  {$DEFINE RAD_10_3_UP}
  {$DEFINE RAD_RIO_UP}
{$IFEND}

Many libraries still use the practice of testing directly against the VERXXX defines, with no fallback, and thus break when a new version of Delphi is released, for no other reason that the shortsightedness of the authors. For example the following is from a well know charting library:

{$IFDEF VER330}  // RAD Studio XE v12.0 Rio (Carnival) 2018 (v 20.0) 32bit / 64bit / OSX / iOS 32-64 FMX / Android & C++ / Linux 64bit
  {$DEFINE D3}
  {$DEFINE D4}
  {$DEFINE D5}
  {$DEFINE D6}
  {$DEFINE D7}
  {$DEFINE D8}
  {$DEFINE D9}
  {$DEFINE D10}
  {$DEFINE D105}
  {$DEFINE D11}
  {$DEFINE D12}
  {$DEFINE D14}
  {$DEFINE D15}
  {$DEFINE D16}
  {$DEFINE D17}
  {$DEFINE D18}
  {$DEFINE D19}
  {$DEFINE D20}
  {$DEFINE D21}
  {$DEFINE D22}
  {$DEFINE D23}
  {$DEFINE D24}
  {$DEFINE D25}
  {$DEFINE D26}
{$ENDIF}

 

[Uwe Raabe 2057]

1 hour ago, Anders Melander said:

For example even though it doesn't explicitly contain defines for Delphi 10.4 it will define the RAD_10_3_UP correctly on Delphi 10.3 and later:

I try to write code that puts the lower Delphi versions under conditions. These are easier to eliminate when support for those older versions is dropped. Therefore you find constructs like {$IF CompilerVersion < 32.0 Tokyo } in my code, or sometimes even if CompilerVersion < 32.0 { Tokyo } then to avoid conditional compilation completely.

Perhaps I am too lazy to update these include files in dozens of projects each time a new Delphi version arrives.

[Fr0sT.Brutal 900]

Yep, I always wondered why so many people use concrete version defines that make the whole code unusable when a new version arrives.

I personally prefer minimizing usage of version defines replacing them with defines that declare the very feature. F.ex., RAD_2010 => GENERICS_OK (non-buggy generics). It's like using logically named identifiers instead of i1, jj3 etc

Edited July 26, 2020 by Fr0sT.Brutal

[igors 0]

On 7/25/2020 at 12:42 PM, Uwe Raabe said:

The problem is, that you need to use always the latest version of this file as part of your library, so it is capable to handle all Delphi versions.

 

Even if starting with 10.5 Delphi would provide such a file itself, it will be outdated as soon as 10.6 arrives. So you have to use the newer file even for older Delphi versions, which somehow rules out such a file coming with Delphi itself.

If it's incorporated into the compiler there's no additional file needed for Delphi itself. it will understand all of these and add something new as time goes. Library author can include this file into the library as a fallback for older versions.

[Bill Meyer 337]

17 hours ago, Fr0sT.Brutal said:

Yep, I always wondered why so many people use concrete version defines that make the whole code unusable when a new version arrives.

I suspect it is because that was the first model anyone created, and others simply grabbed it, following Design Pattern #1: Copy and Paste. At some point it became a matter of intertia.

[Uwe Raabe 2057]

3 minutes ago, igors said:

If it's incorporated into the compiler there's no additional file needed for Delphi itself. it will understand all of these and add something new as time goes. Library author can include this file into the library as a fallback for older versions.

Perhaps I didn't explain it well enough. 

 

In case my code contains a check like:

{$IF CompilerVersion < RAD_Chicago}
{$IFEND}
{$IF CompilerVersion < RAD_Sydney}
{$IFEND}
{$IF CompilerVersion < RAD_Rio}
{$IFEND}

that may perfectly compile with a future Delphi version named Chicago incorporating constants

  RAD_Chicago = 63; // no offence
  ...
  RAD_Sydney = 34;
  RAD_Rio = 33;
  ...

but fails with any compiler available today.

 

So I still need this one file with all these declarations and independent from the compiler. Where would be the benefit of Delphi providing a bunch of different versions of such a file where most of them are probably outdated and thus useless?

Imagine we have each Delphi version in a separate VM, where almost all of these don't have the latest version of this file.

 

Getting all this working will result in way more hassle than having this file maintained in one place, copying that into each project that makes use of it and keeping it up to date with each new Delphi version.

[Fr0sT.Brutal 900]

Well, if compiler supported standardized set of capability checks it would be enough in most cases. But let's face the truth - Emba/Idera's purpose is to make people move to recent versions. They unlikely will support any framework helping to stick to older versions

[igors 0]

19 hours ago, Uwe Raabe said:

In case my code contains a check like:

{$IF CompilerVersion < RAD_Chicago}
{$IFEND}
{$IF CompilerVersion < RAD_Sydney}
{$IFEND}
{$IF CompilerVersion < RAD_Rio}
{$IFEND}

> that may perfectly compile with a future Delphi version named Chicago incorporating constants 

I had somethging else in mind, for Delphi to incorporate features, for example if it supports attributes then ATTRIBUTES would be defined and instead of writing IF CompilerVersion > XX you would say $IF ATTRIBUTES...

So from that point on, you wouldn't this .inc file at all, Delphi would support all these checks.

[Uwe Raabe 2057]

53 minutes ago, igors said:

for example if it supports attributes then ATTRIBUTES would be defined and instead of writing IF CompilerVersion > XX you would say $IF ATTRIBUTES...

You already can do that:

{$IF Declared(TCustomAttribute)}

 

[Guest]

Anyhow, I need that book! Now!