ICS v8.64 can't compile on Delphi 7

[Kyle_Katarn 1]

ICS v8.64 can't compile on Delphi 7

 

Cause OverbyteIcsUtils:7230 (declaration expected but "INLINE" found)

function IcsPunyIsBasic(const C: WideChar): Boolean; Inline;

 

Inlining is only supported from Delphi 2005 onwards : https://stackoverflow.com/questions/8460037/list-of-delphi-language-features-and-version-in-which-they-were-introduced-depre/8460108#8460108

Edited May 31, 2020 by Kyle_Katarn

[FPiette 385]

Simply remove the inline keyword. This will not affect the function, only the performance.

 

[Angus Robertson 577]

Thanks, will be fixed in SVN later today.  Don't fire up Delphi 7 very often.

 

Angus

 

 

 

[David Heffernan 2353]

I have a case in my test suite that checks compilation for all supported delphi versions of all code that I ship to clients. Pretty easy to set up. 

[Kyle_Katarn 1]

On 5/31/2020 at 8:59 PM, FPiette said:

Simply remove the inline keyword. This will not affect the function, only the performance.

 

Done, works fine

[Kyle_Katarn 1]

(deleted message)

Edited June 2, 2020 by Kyle_Katarn

[Kyle_Katarn 1]

One additional comment, in 

procedure TIcsFileCopy.SetMultiDirList (const Value: string) ;

 

the following section in the var declaration

    I: integer ;
    aitems, afields: TStringList ;

shall be protected by {$IFDEF COMPILER10_UP} as these variable are not used otherwise.

[Kyle_Katarn31 0]

Up ?

[Plainer 0]

Does the inline keyword need to be removed from each *.pas file or is there one location that it can be removed / commented out that will allow D7 to compile ICS864 without errors?

[FPiette 385]

Remove inline everywhere you see it.

 

[Kyle_Katarn 1]

Yes, that's a good short term workaround on my local copy, but we'd need a long term fix in order to maintain D7 compatibility.

[Fr0sT.Brutal 900]

Better to replace them with conditional like {$IFDEF WITH_INLINES} inline; {$ENDIF} - this change could be merged into upstream so you won't have to do it with every update

[Remy Lebeau 1436]

16 minutes ago, Fr0sT.Brutal said:

Better to replace them with conditional like {$IFDEF WITH_INLINES} inline; {$ENDIF}

This is the way Indy does it.  Then the conditional is defined only for D2006+ (and FPC), and only for release builds.

Edited August 6, 2020 by Remy Lebeau

[Kyle_Katarn 1]

8 hours ago, Fr0sT.Brutal said:

Better to replace them with conditional like {$IFDEF WITH_INLINES} inline; {$ENDIF} - this change could be merged into upstream so you won't have to do it with every update

 

That's exactly my point :-)

[A.M. Hoornweg 144]

7 hours ago, Remy Lebeau said:

This is the way Indy does it.  Then the conditional is defined only for D2006+ (and FPC), and only for release builds.

I constantly have to look up in which Delphi version a certain feature was introduced.  And not just me, literally *every* component manufacturer maintains his own *.INC file with $defines to keep track of these things.  Those *.INC files have to be maintained with every new delphi version and they're a royal P.I.T.A.  

 

Wouldn't it be great if Embarcadero (or anyone else, really) published a git repository with a freely usable  *.INC file,  with $defines for all feature changes in every Delphi version? That way everybody could speak a common "language" for detecting features instead of re-inventing the wheel. 

[Angus Robertson 577]

All of the reported Delphi 7 problems are fixed in V8.65 which is not yet released, but can be downloaded from SVN or the overnight zip.   Not aware of any new inline issues. 

 

Currently making a lot of changes to support MacOS64 since DCCOSX64 behaves differently to DCCOSX. 

 

Angus

 

[Kyle_Katarn 1]

4 hours ago, Angus Robertson said:

All of the reported Delphi 7 problems are fixed in V8.65 which is not yet released, but can be downloaded from SVN or the overnight zip.   Not aware of any new inline issues. 

 

Currently making a lot of changes to support MacOS64 since DCCOSX64 behaves differently to DCCOSX. 

 

Angus

 

Very good news thanks !

[Remy Lebeau 1436]

11 hours ago, A.M. Hoornweg said:

Wouldn't it be great if Embarcadero (or anyone else, really) published a git repository with a freely usable  *.INC file,  with $defines for all feature changes in every Delphi version? That way everybody could speak a common "language" for detecting features instead of re-inventing the wheel. 

There are some 3rd-party INC files like that already.  But different vendors have different requirements for different feature use-cases.  I can only speak for myself, but I don't like using monolithic INC files that define lots of things that I'm not actually using.  That is why authors typically use their own INC files to tailor for their particular requirements.

 

What we really need is a compiler-level feature detection system instead.  C++ has had something like that standardized for awhile now:

 

https://en.cppreference.com/w/cpp/feature_test

 

https://en.cppreference.com/w/User:D41D8CD98F/feature_testing_macros

[dummzeuch 1517]

I tend to use jedi.inc, which is pretty comprehensive, but I still had to extend it for various compiler specific problems.

Lately I have switched from using {$ifdef} to {$if declared()  }when it comes to checking if a type or function is already available or has to be implemented in one of my units. But in y not sure I really like that, because it becomes harder to read.

[Fr0sT.Brutal 900]

On 8/7/2020 at 10:04 AM, A.M. Hoornweg said:

I constantly have to look up in which Delphi version a certain feature was introduced.  And not just me, literally *every* component manufacturer maintains his own *.INC file with $defines to keep track of these things.  Those *.INC files have to be maintained with every new delphi version and they're a royal P.I.T.A.  

IDK what things you mean. Backward compatibility is pretty strong in current versions as main changes happened in D2009..XE2. So newer versions require very little changes, especially if you don't use newest features (and you have to avoid them if you care about older versions)

Edited August 8, 2020 by Fr0sT.Brutal

[Angus Robertson 577]

What would be useful is a relatively concise list of RTL changes between releases, perhaps it exists?  Something that says AtomicIncrement and Pos(x,y) appeared in which releases, just two examples I've looked up in old compilers recently for ICS.  And when types appeared or disappeared. 

 

I've been meaning to support native Json in ICS as well as SuperObject, but I think there are two generations in different compilers and needing to check which and when means I've done nothing instead.

 

Angus

[A.M. Hoornweg 144]

4 hours ago, Angus Robertson said:

What would be useful is a relatively concise list of RTL changes between releases, perhaps it exists?  Something that says AtomicIncrement and Pos(x,y) appeared in which releases, just two examples I've looked up in old compilers recently for ICS.  And when types appeared or disappeared. 

 

I've been meaning to support native Json in ICS as well as SuperObject, but I think there are two generations in different compilers and needing to check which and when means I've done nothing instead.

 

Angus

This is the most complete list I could find:

https://stackoverflow.com/questions/8460037/list-of-delphi-language-features-and-version-in-which-they-were-introduced-depre

 

[Angus Robertson 577]

Thanks, covers major changes but not a lot of things that trip up people.  Does have one nasty for me, mentions LongInt and LongWord are 64-bit on iOS64 which means also on MacOS64, changed some LongInts in ICS already but looks like I need to check all OpenSSL and ZLIB exports as well, and other places.

 

Angus

 

[A.M. Hoornweg 144]

14 hours ago, Fr0sT.Brutal said:

IDK what things you mean. Backward compatibility is pretty strong in current versions as main changes happened in D2009..XE2. So newer versions require very little changes, especially if you don't use newest features (and you have to avoid them if you care about older versions)

I maintain some libraries that are used in our company and that have to be compatible with a range of compilers (2007 .. current).  Some of our programs are used on embedded devices with older operating systems hence the need for D2007. We want our products to compile without hints or warnings.

 

Totally apart from the usual string problems (unicode/ansi and codepages), there's the issue of Embarcadero deciding to move RTL functions from one unit to another, of functions being declared "deprecated" and of functions suddenly being declared "inline".  So in order to suppress such warnings, I need to know when Embarcadero decided to pull off such changes.

[Fr0sT.Brutal 900]

11 hours ago, Angus Robertson said:

What would be useful is a relatively concise list of RTL changes between releases, perhaps it exists?  Something that says AtomicIncrement and Pos(x,y) appeared in which releases, just two examples I've looked up in old compilers recently for ICS.  And when types appeared or disappeared. 

 

I've been meaning to support native Json in ICS as well as SuperObject, but I think there are two generations in different compilers and needing to check which and when means I've done nothing instead.

 

Angus

Most of these checks could be performed with IF DECLARED clause. Thanks to it very few features must be defined manually, just some language features or unit relocations. I maintain a repo with defines for main compiler features here so use the provided info freely or make PR's/issues to add something that is missing.

Edited August 9, 2020 by Fr0sT.Brutal