FPC 3.0 changes lazarus / 64-FPC development ---------------------------------------------------------------------- Ocye · 2015-09-02 12:15 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? ---------------------------------------------------------------------- Jonas Maebe · 2015-09-02 12:21 Quote from: Ocye on September 02, 2015, 02:15:08 pmI 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 · 2015-09-02 13:44 Quote from: Ocye on September 02, 2015, 02:15:08 pmI'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. ---------------------------------------------------------------------- marcov · 2015-09-02 14:28 If you don't mess up the default encoding, and store utf8 strings code only  in utf8string, it should also be ok. ---------------------------------------------------------------------- Ocye · 2015-09-02 14:51 Quote from: Jonas Maebe on September 02, 2015, 02:21:50 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. Quote from: JuhaManninen on September 02, 2015, 03:44:10 pmYou 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()? ---------------------------------------------------------------------- JuhaManninen · 2015-09-02 18:20 Quote from: Ocye on September 02, 2015, 04:51:44 pmAh 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. QuoteAnd what's about the missing functions like CopyFile()? What do you mean by missing? At least package LazUtils unit FileUtil has it. ---------------------------------------------------------------------- garlar27 · 2015-09-02 19:40 Quote from: JuhaManninen on September 02, 2015, 08:20:22 pmQuoteAnd 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... ---------------------------------------------------------------------- JuhaManninen · 2015-09-02 20:45 Quote from: garlar27 on September 02, 2015, 09:40:26 pmFileCopy 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. QuoteSince 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 · 2015-09-03 05:52 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 · 2015-09-03 08:17 Quote from: mdalacu on September 03, 2015, 07:52:09 amNow, 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 · 2015-09-03 09:22 Quote from: Jonas Maebe on September 03, 2015, 10:17:33 amQuote from: mdalacu on September 03, 2015, 07:52:09 amNow, 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 · 2015-09-03 12:40 Quote from: JuhaManninen on September 02, 2015, 10:45:30 pmQuote from: garlar27 on September 02, 2015, 09:40:26 pmFileCopy 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. QuoteSince 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 · 2015-09-03 14:17 Quote from: garlar27 on September 03, 2015, 02:40:15 pmI 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 · 2015-09-04 14:14 Can LCL handle UTF16? ---------------------------------------------------------------------- JuhaManninen · 2015-09-04 14:44 Quote from: Fiji on September 04, 2015, 04:14:24 pmCan 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.