#1 2020-04-22 11:19:40

Junior/RO
Member
Registered: 2011-05-13
Posts: 207

Using SynDprUses.inc

For years, all my programs .DPR always used this opening uses clause:

uses
  FastMM4, FastCode, FastMove,
  Windows, Forms,

Reading mORMot examples, I found

//   first line of uses clause must be   {$I SynDprUses.inc}
uses
  {$I SynDprUses.inc}
  Forms,

I did a comparision of mORMOt's version of FastMM4 and liked it. I will use the mORMot version.

But, what about FastCode and FastMove units? The optimizations of mORMot code will have better performance that the old FastCode, FastMove units? It's a drop-in replacement?

Offline

#2 2020-04-22 12:58:17

ab
Administrator
From: France
Registered: 2010-06-21
Posts: 14,182
Website

Re: Using SynDprUses.inc

FastMove is already included in SynCommons.pas, and FastCode is not needed, since we use our own optimized versions.
So no need of FastCode/FastMove any more.

Offline

#3 2020-04-23 15:43:16

Junior/RO
Member
Registered: 2011-05-13
Posts: 207

Re: Using SynDprUses.inc

Thank you.

Offline

#4 2020-12-08 11:26:32

mpv
Member
From: Ukraine
Registered: 2012-03-24
Posts: 1,534
Website

Re: Using SynDprUses.inc

I found very interesting behavior of cwstring unit (includes in SynDprUses for Linux builds):

cwstring.pp initialization calls a

setlocale(LC_ALL,'');

This force program to read a locale settings from environment variables (LC_ALL and family). So all libc functions and all C libraries I load in program starts using these locales settings.
Sometimes this is not e behavior I expect.

For example I use a third-party C library what internally uses

sprintf(buffer, "%f", sample->r_value);

to output a decimal values to a buffer.

In case I adds a SynDprUses.inc (adds a cwstring) in a uses section of my program then cwstring initialize a LC_NUMERIC variable to use a comma as a decimal separator (my laptop configured to use Ukrainian locale)  and I got an unexpected numbers in the text file.

So, my questions are:
1) Do we really need a cwstring ? As far as I understand the answer is "No" -  AnsiToUTF8 и UTF8ToAnsi is intercepted on SynCommons, so FPC functions are not used.
2) If we need it, please,  let's add some DEFINE what allows me to disable it in SynDprUses

Offline

#5 2020-12-08 15:42:36

ab
Administrator
From: France
Registered: 2010-06-21
Posts: 14,182
Website

Re: Using SynDprUses.inc

I suppose you are right, and cwstring is not needed directly, unless you use explicitly WideString/UnicodeString variables.
If you use RawUTF8, this unit is not needed.

I will see if I can call directly iconv() with no dependency to this unit. There is some code for Kylix calling the libc, and I guess it could be enough for our purpose.
But I remember that ICU is much faster than iconv(). Even .Net 5 is using ICU on Windows now! https://docs.microsoft.com/en-us/dotnet … zation-icu
So perhaps looking into ICU as alternative for mORMot 2.

I will try to implement the following:
1) set a conditional for cwstring in SynDprUses.inc
2) on FPC/POSIX, use the cwstring API is available (i.e. widestringmanager has been set), otherwise, call directly iconv.
3) eventually, for mORMot2, look into ICU.

Those UTF-16 conversion codes are very unlikely to be called in UTF-8 processing, unless you explicitly use non fixed with charsets (like Chinese or Japan).

Offline

#6 2020-12-08 15:53:52

mpv
Member
From: Ukraine
Registered: 2012-03-24
Posts: 1,534
Website

Re: Using SynDprUses.inc

For a while I apply this fix in all my dpr's - this solves my problems with locales.

{$ifdef MSWINDOWS}
  {$I SynDprUses.inc}
  {$else}
  // prevent to use a cwstring: LC_NUMBERS problem https://synopse.info/forum/viewtopic.php?pid=33631#p33631
  cthreads,
  SynFPCCMemAligned,
  {$endif}  

So we can modify only a mORMot2 code...

Last edited by mpv (2020-12-08 15:54:51)

Offline

#7 2020-12-09 09:25:20

ab
Administrator
From: France
Registered: 2010-06-21
Posts: 14,182
Website

Re: Using SynDprUses.inc

I was a bit sick yesterday, so I didn't go forward on this, sorry.

But what I will do today is implement ICU, also for mORMot 1.18.
Also implement the FPC widestringmanager using ICU instead of iconv.
ICU is much faster and easier to use.

Offline

#8 2020-12-09 14:36:11

ab
Administrator
From: France
Registered: 2010-06-21
Posts: 14,182
Website

Re: Using SynDprUses.inc

Now we use ICU for Unicode process on FPC/POSIX.

And the cwstring is not needed any more, even for the regression tests.

No ICU widestringmanager yet, but I guess it may not be mandatory yet.

Offline

#9 2021-02-01 20:36:33

mpv
Member
From: Ukraine
Registered: 2012-03-24
Posts: 1,534
Website

Re: Using SynDprUses.inc

One remark for Linux - now mORMot/mORMot2 depends on libicu, so if someone creates an rpm/deb packages, the following dependency should be added:
- DEBIAN/control (for Ubuntu 18.04 \ 20.04)

Depends: libicu60 | libicu66

- rpm/SPECS (CentOS, RHEL7 / 8 OEL 7 / 8)

Requires: libicu >= 60

Last edited by mpv (2021-02-01 20:38:16)

Offline

#10 2021-02-01 22:34:59

ab
Administrator
From: France
Registered: 2010-06-21
Posts: 14,182
Website

Re: Using SynDprUses.inc

There is no hard dependency with ICU.
If libicu is installed, it will be used for Ansi/Unicode conversion. Or iconv could be used if cwstring unit is included.
But if you just use UTF-8 it won't be used at all.

Note that there is an Unicode comparison embedded in mORMot 2.

Offline

Board footer

Powered by FluxBB