El 24/02/2021 a las 21:53, Juha Manninen via lazarus escribió:
Hello,
I am interested in how well your TMask version compares with Delphi's
version.
Does it match the speed or even surpass it?
Not tested because in my code strings are allways UTF8 stored so for
Delphi comparison I must convert them to Unicode before. I'll try to
perform a simple benchmark.
Case-insensitive matching of Unicode can be fixed later with functions
found in LazUTF8.
As this code is not a priority I think its better to make it work with
Lazutf8 functions before the first commit. The problem is the support
for sametext in UnicodeString.
With José's approval the license will be LGPL with a linking exception.
It will be part of the LazUtils package. Author's name will be mentioned
of course.
Is that OK?
Yes, of course. Put the name if it is used for a reference, otherwise
put standard headers.
I will not copy the whole original unit but use the UTF-8 parts + rename
and tweak some things.
In fact I think that the whole unit is needed. It has (info for other
readers) 3 classes TMaskUTF8, TMaskAnsi and TMaskUnicode, maybe
TMaskAnsi can be omitted but UTF8 and Unicode should be present. Many
times TMask is used over zillions of strings, converting Unicode to UTF8
(for UnicodeStrings and WideStrings) is time consuming, much more than
the masking itself in most cases.
I suggest to keep the 3 classes and create a new TMask one which mimic
the behaviour of current TMask, disabling the masking extensions (escape
char, [?],...) which is very simple as you only need to subclass the
Create method, mask compilation happens at first use time, not at
creation time.
This way current code using TMask will behave 99.9% identical, but an
user that needs to mask other strings can use TMaskUnicode, in example,
and activate or deactivate other extensions.
--
--
_______________________________________________
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus
