Sending this again to see if it gets through (posts getting blocked again).
> On Feb 26, 2019, at 2:43 PM, Ryan Joseph wrote:
>
> In my implicit generic specialization code I have one place where I get a
> string const node (stringconstn) which the resultdef is arraydef (not
> stringdef like
Maybe https://bugs.freepascal.org/view.php?id=34772
On 27/02/2019 17:24, Bart wrote:
Reported in forum:
http://forum.lazarus.freepascal.org/index.php/topic,44466.msg312583.html#msg312583
{$mode objfpc} //same in mode delphi, did not test others
procedure DoIt(ar: array of const);
begin
try
On Wed, Feb 27, 2019 at 5:24 PM Bart wrote:
Tested with fpc r41352
--
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Reported in forum:
http://forum.lazarus.freepascal.org/index.php/topic,44466.msg312583.html#msg312583
{$mode objfpc} //same in mode delphi, did not test others
procedure DoIt(ar: array of const);
begin
try
exit;
finally
end
end;
begin
DoIt([]);
end.
Am 26.02.2019 um 19:12 schrieb Bart:
> This leaves my initial "itch": input strings are CP_ACP (so can be
> anything), output strings are CP_UTF8 always.
Unless your DefaultSystemCodePage is CP_UTF8 (in which case UTF8Encode is not
needed), the next action on the string will convert away from UTF8
Gareth,
First of all, thanks for working on compiler optimizations. I think it's very
important.
As of benchmark - there is a simple 3D ray tracer benchmark written on several
languages including Pascal.
AFAIR Pascal version almost as fast as Java one and slightly faster than
Javascript.
