On 29/06/2019 23:43, Sven Barth via fpc-devel wrote:
Am 28.06.2019 um 10:39 schrieb Martin Frb:
What does Delphi do with
property Foo[AIndex: Integer; BIndex: Integer = 0]: Integer read
GetFoo;
Because FPC rejects this one. (And IMHO rightfully so)
Hope this madness can be avoided in
Am 28.06.2019 um 10:39 schrieb Martin Frb:
On 28/06/2019 07:39, Sven Barth via fpc-devel wrote:
Am 27.06.2019 um 21:09 schrieb Martin:
{ TFoo }
TFoo = class
private
function GetFoo(var AIndex: Integer): Integer;
public
property Foo[var AIndex: Integer]: Integer read GetFoo;
This assumption is *not* incorrect. Only on the LLVM based Delphi NewGen and FPC's LLVM backend the assumption is incorrect which can be seen by them having added "volatile" mechanisms. I believe this assumption incorrect because it's not stated in documentation as correct.If FPC somehow
> As an side since you’re talking about optimizations what would it take to
> make the copy/addref record operators be inline? Unless I’m mistaken that’s
> one of the bigger issues that makes custom ref counted objects slower than
> built in compiler types. Just curious...
I believe counter's
George Bakhtadze schrieb am Sa., 29. Juni 2019,
09:32:
>
>
> This assumption is *not* incorrect. Only on the LLVM based Delphi NewGen
> and FPC's LLVM backend the assumption is incorrect which can be seen by
> them having added "volatile" mechanisms.
>
>
> I believe this assumption incorrect
Am 28.06.2019 um 11:24 schrieb George Bakhtadze:
This assumption is *not* incorrect. Only on the LLVM based Delphi
NewGen and FPC's LLVM backend the assumption is incorrect which can
be seen by them having added "volatile" mechanisms.
I believe this assumption incorrect because
Florian Klaempfl schrieb am Sa., 29. Juni 2019,
15:52:
> Am 28.06.2019 um 11:24 schrieb George Bakhtadze:
> > This assumption is *not* incorrect. Only on the LLVM based Delphi
> > NewGen and FPC's LLVM backend the assumption is incorrect which can
> > be seen by them having added
