Jump to content

pyscripter

Members
  • Content Count

    914
  • Joined

  • Last visited

  • Days Won

    55

Everything posted by pyscripter

  1. One of the improvements in Delphi Rio is the upgrade of PCRE to version 8.42 and more importantly the inclusion of UTF-16 support on Windows. What this means is that Delphi strings are no longer converted to UTF-8 and back when using Regular Expressions. This blog post describes a benchmark of various regular expression options. I wanted to see the impact of the Rio improvements and here are the results. The results below use the test suite of the above mentioned article. Delphi 10.2: Total Time: 12639.00 ms Delphi 10.3: Total Time: 10614.00 ms (about 17% faster) Further improvement can be achieved by using PCRE Study. Fir a bit of extra compile time you have significant execution benefits. You need a class helper to use Study with TRegEx: type TRegExHelper = record helper for TRegEx public procedure Study; end; procedure TRegExHelper.Study; begin with Self do FRegEx.Study; end; You can call study after TRegEx,Create. Here are the results with Study. Delphi 10.2: Total Time: 9863.00 ms Delphi 10.3: Total Time: 7895.00 ms (about 20% faster)
  2. Look at https://gitlab.com/teo-tsirpanis/gold-parser-Lazarus for a version 5 compatible Gold engine. Version 5 grammars are not compatible with versions 1 engines. But IMHO the good old lex/yacc https://github.com/RomanYankovsky/ndyacclex can be more easily integrated with your Delphi projects. No need to rely on third party libraries. One could develop and test the grammar with GOLD I suppose and then translate it to lex/yacc.
  3. pyscripter

    Directions for ARC Memory Management

    Please excuse my ignorance. What is "New.Of"?
  4. pyscripter

    How to make a component available to all platforms

    From the documentation: http://docwiki.embarcadero.com/RADStudio/Tokyo/en/64-bit_Windows_Application_Development. The RAD Studio build system automatically embeds an RC_DATA resource in the Win32 package binary named PLATFORMTARGETS, which is a bitmask of the pidXXX constants in System.Classes.pas and reflects the package project's targeted platforms. The IDE reads this resource when the package is loaded and uses the resource data to decide, for example, whether or not to disable the component(s) in the palette when an unsupported platform is active. Targeting multiple platforms with a component package implies a contract between the component developer and the IDE. The IDE assumes that if a component package project targets multiple platforms and the developer distributes the Win32 run-time package to customers (and all the associated compilable and linkable files), the developer will also distribute all the necessary compilable, linkable, and run-time bits for the other targeted platforms as well. Individual components can use the ComponentPlatformsAttribute class attribute to override the data in PLATFORMTARGETS, using a bitmask of the same constants in the Classes unit. For example: type [ComponentPlatformsAttribute(pidWin32 or pidWin64)] // Only supported on Win32 and Win64 TMyComponent = class(TComponent) private ... end; So to get the components to be usable with other plagorms, all you need to do is before you compile the Design package to add the other platform to it. They won't be used but just being there makes the build system to include the appropriate resource flagging the package as usable for the platforms. I have tested this and it works!
×