Recent

Author Topic: FPC 3.0 changes  (Read 8377 times)

Ocye

  • Hero Member
  • *****
  • Posts: 518
    • Scrabble3D
FPC 3.0 changes
« on: September 02, 2015, 02:15:08 pm »
I'm compiling my program for the first time with 3.0.0rc1. And found a few conspicuity:

*File*UTF8()-functions should be used from LazFileUtils. Most functions keep their names but DeleteDirectory(string, boolean) is changed to RemoveDirUTF8(string) and FileSize() is replaced by FileSizeUTF8(). However, I didn't found a equivalent to CopyFile() and GetAllFilesMask(). Shouldn't it be expected? Or better: I has to be documented.

I have quite a lot of widestring operations implemented, e.g. val(ws[i+1],x,e); or StrToInt(Copy(ws,1,y-1)), both with ws=widestring. Former UTF8 operations such as UTF8Copy() or UTF8Length() were known to be slow. Does it makes sense to carefully go through all string handling now since fpc itself supports UTF8? In other words would I benefit from using strings instead of widestrings?

I get the warning "Local variable $bar of a managed type is not initialized" with a function Foo(var bar:string). Sounds not correct to me, or am I wrong?

Lazarus 1.7 (SVN) FPC 3.0.0

Jonas Maebe

  • Hero Member
  • *****
  • Posts: 659
Re: FPC 3.0 changes
« Reply #1 on: September 02, 2015, 02:21:50 pm »
I get the warning "Local variable $bar of a managed type is not initialized" with a function Foo(var bar:string). Sounds not correct to me, or am I wrong?
It's a hint, not a warning. "var" means "the called routine can read and/or write the variable". The hint refers to the fact that you yourself did not assign a value to the variable before it may be read. This could be a bug in the logic if your program. It is orthogonal to implementation details such as the fact that managed variables need compiler initialisation because otherwise the program will just crash.

It's a hint instead of a warning because it is unlikely to be an actual bug in your program, so you can turn it off separately.

JuhaManninen

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3634
  • I like bugs.
Re: FPC 3.0 changes
« Reply #2 on: September 02, 2015, 03:44:10 pm »
I'm compiling my program for the first time with 3.0.0rc1. And found a few conspicuity:

*File*UTF8()-functions should be used from LazFileUtils. ...

*File*UTF8()-functions were needed in LCL applications also earlier, before FPC 3.0.
LCL has used AnsiString + dedicated UTF8() functions for its Unicode support until now.
If you did not use those functions, your application did not support Unicode.

Good news for you! You can continue using the functions without "UTF8" prefix/suffix by using this :
  http://wiki.freepascal.org/Better_Unicode_Support_in_Lazarus
It changes FPC's default string encoding to UTF-8 and all string- and file-functions work correctly.
We are expecting more issues related to WinAPI W-functions and reading/writing files and streams with different encodings. Please report your findings here or in the "Open issues" section in the wiki page.

This "Better Unicode" solution is still not Delphi compatible but is much closer to it than the current solution with dedicated functions.
« Last Edit: September 02, 2015, 08:08:15 pm by JuhaManninen »

marcov

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 7458
Re: FPC 3.0 changes
« Reply #3 on: September 02, 2015, 04:28:00 pm »
If you don't mess up the default encoding, and store utf8 strings code only  in utf8string, it should also be ok.

Ocye

  • Hero Member
  • *****
  • Posts: 518
    • Scrabble3D
Re: FPC 3.0 changes
« Reply #4 on: September 02, 2015, 04:51:44 pm »
"var" means "the called routine can read and/or write the variable". The hint refers to the fact that you yourself did not assign a value to the variable before it may be read.
I was just surprised. 'Var' parameters are standard in Pascal and these hints spam a little bit. BTW, 'out' doesn't give a hint.

You can continue using the functions without "UTF8" prefix/suffix...
Ah yes, that should work as well. Is it recommended to use the FPC functions rather than the LCL versions (targeting all desktop platforms)? And what's about the missing functions like CopyFile()?
Lazarus 1.7 (SVN) FPC 3.0.0

JuhaManninen

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3634
  • I like bugs.
Re: FPC 3.0 changes
« Reply #5 on: September 02, 2015, 08:20:22 pm »
Ah yes, that should work as well. Is it recommended to use the FPC functions rather than the LCL versions (targeting all desktop platforms)?

Yes. Some LCL UTF-8 functions are called behind the scenes but a user does not need to care about it.

Quote
And what's about the missing functions like CopyFile()?

What do you mean by missing? At least package LazUtils unit FileUtil has it.

garlar27

  • Hero Member
  • *****
  • Posts: 617
Re: FPC 3.0 changes
« Reply #6 on: September 02, 2015, 09:40:26 pm »
Quote
And what's about the missing functions like CopyFile()?

What do you mean by missing? At least package LazUtils unit FileUtil has it.

FileCopy is within LCL but not in RTL (AFAIK) which means if you have a proyect that don't use LCL like a library o console apps you can't use it.

Since those functions DO NOT DEPPEND on the LCL, I've made a copy af them to another unit in order to use it without including the whole LCL.

EDIT: By the way, EpicTimer it also depends on the LCL but I don't know if this is really necesary...
« Last Edit: September 02, 2015, 09:42:31 pm by garlar27 »

JuhaManninen

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3634
  • I like bugs.
Re: FPC 3.0 changes
« Reply #7 on: September 02, 2015, 10:45:30 pm »
FileCopy is within LCL but not in RTL (AFAIK) which means if you have a proyect that don't use LCL like a library o console apps you can't use it.

Uhhh ... There is no "FileCopy" function in LCL.
RTL does not have such a function either. I only found "FileCopy" in FPC source file utils/mksymbian/compiler.pas.

Ocye was asking about "CopyFile" function. It is in LazUtils, not in LCL. It can be used in console apps without problems.

Quote
Since those functions DO NOT DEPPEND on the LCL, I've made a copy af them to another unit in order to use it without including the whole LCL.

What do you mean?

mdalacu

  • Full Member
  • ***
  • Posts: 199
    • dmSimpleApps
Re: FPC 3.0 changes
« Reply #8 on: September 03, 2015, 07:52:09 am »
Now, with FPC 3.0 can you start an external program on windows using TProcess and CMD containing utf characters? something like "cmd.exe /c ffmpeg.exe -i ▶ Vunk .mp4"?
Thx.

Jonas Maebe

  • Hero Member
  • *****
  • Posts: 659
Re: FPC 3.0 changes
« Reply #9 on: September 03, 2015, 10:17:33 am »
Now, with FPC 3.0 can you start an external program on windows using TProcess and CMD containing utf characters? something like "cmd.exe /c ffmpeg.exe -i ▶ Vunk .mp4"?
Thx.
The list of routines supporting full unicode in FPC 3.0 can be found at http://wiki.freepascal.org/FPC_Unicode_support#RTL_changes . As you can see, TProcess is not in that list (and neither is sysutils.ExecuteProcess, which is used by TProcess).

mdalacu

  • Full Member
  • ***
  • Posts: 199
    • dmSimpleApps
Re: FPC 3.0 changes
« Reply #10 on: September 03, 2015, 11:22:12 am »
Now, with FPC 3.0 can you start an external program on windows using TProcess and CMD containing utf characters? something like "cmd.exe /c ffmpeg.exe -i ▶ Vunk .mp4"?
Thx.
The list of routines supporting full unicode in FPC 3.0 can be found at http://wiki.freepascal.org/FPC_Unicode_support#RTL_changes . As you can see, TProcess is not in that list (and neither is sysutils.ExecuteProcess, which is used by TProcess).
Bummer....Thanks.

garlar27

  • Hero Member
  • *****
  • Posts: 617
Re: FPC 3.0 changes
« Reply #11 on: September 03, 2015, 02:40:15 pm »
FileCopy is within LCL but not in RTL (AFAIK) which means if you have a proyect that don't use LCL like a library o console apps you can't use it.

Uhhh ... There is no "FileCopy" function in LCL.
RTL does not have such a function either. I only found "FileCopy" in FPC source file utils/mksymbian/compiler.pas.

Ocye was asking about "CopyFile" function. It is in LazUtils, not in LCL. It can be used in console apps without problems.

Quote
Since those functions DO NOT DEPPEND on the LCL, I've made a copy af them to another unit in order to use it without including the whole LCL.

What do you mean?


I should check my proyects but AFAIR the apps I converted to daemon/service, the compiler complained about LazUtils and EpicTimer.
This was a long time ago and never tried too hard to make it work. I will try to post a simple example.

JuhaManninen

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3634
  • I like bugs.
Re: FPC 3.0 changes
« Reply #12 on: September 03, 2015, 04:17:51 pm »
I should check my proyects but AFAIR the apps I converted to daemon/service, the compiler complained about LazUtils and EpicTimer.
This was a long time ago and never tried too hard to make it work. I will try to post a simple example.

If you make a console or daemon program in Lazarus and add LazUtils as a dependency.
No problem.

rtusrghsdfhsfdhsdfhsfdhs

  • Full Member
  • ***
  • Posts: 162
Re: FPC 3.0 changes
« Reply #13 on: September 04, 2015, 04:14:24 pm »
Can LCL handle UTF16?

JuhaManninen

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3634
  • I like bugs.
Re: FPC 3.0 changes
« Reply #14 on: September 04, 2015, 04:44:30 pm »
Can LCL handle UTF16?

No, LCL uses UTF-8 itself.
The plan is to have a Delphi compatible UTF-16 version after FPC libs for it are ready.

The current "better Unicode" UTF-8 hack works quite well. I believe it will be supported as an alternative solution also in future.